Spring Boot našumo derinimas daugiausia susijęs su duomenų bazės riba: connection pooling, caching ir N+1 užklausų problemos naikinimas. Pirmiausia matuokite (Micrometer + Actuator metrikos), tada pulkite didžiausią kaštą.
Tingios (lazy) asociacijos siunčia po vieną užklausą kiekvienam tėvui, o tada dar po vieną kiekvienam vaiko kreipiniui:
List<Order> orders = orderRepo.findAll();
(Order o : orders) {
o.getItems().size();
}
Ištaisykite tai, parsiųsdami asociaciją vienu join:
@Query("SELECT o FROM Order o JOIN FETCH o.items") // viena užklausa, items užkrauti iš karto
List<Order> findAllWithItems();
// Arba @EntityGraph(attributePaths = "items") ant repozitorijaus metodo.
HikariCP yra numatytasis pool. Didesnis nėra geriau — per daug jungčių smaugia DB. Dažna formulė prasideda apie cores * 2:
spring:
datasource:
hikari:
maximum-pool-size: 10 # derinkite prie DB pajėgumo, ne gijų skaičiaus
connection-timeout: 3000 # greitai lūžti, o ne kaupti kreipinius
@Cacheable(value = "products", key = "#id") // aptarnauti iš cache po pirmo krovimo
public Product findById(Long id) { return repo.findById(id).orElseThrow(); }
@CacheEvict(value = "products", key = "#p.id") // anuliuoti rašant
public Product update(Product p) { return repo.save(p); }
Paremkite jį Redis (spring-boot-starter-data-redis) bendram cache tarp instancijų.
Senior interviu tikrina, ar diagnozuojate prieš optimizuodami. Stipriausi atsakymai įvardija įrankį, kuris įrodo kliūtį (įjunkite spring.jpa.show-sql ar datasource-proxy užklausoms suskaičiuoti, skaitykite p99 latency iš Actuator), paaiškina, kodėl per didelis pool kenkia, ir traktuoja kešavimą kaip teisingumo problemą — pasenę duomenys ir anuliavimas (invalidation) — o ne vien greičio rankenėlę.
IT pokalbių klausimų biblioteka su išsamiais atsakymais — nuo Junior iki Senior.
Paaukoti