Ladění výkonu ve Spring Bootu se z velké části týká hranice databáze: connection poolingu, cachování a zabití problému N+1 dotazů. Nejprve měřte (metriky Micrometer + Actuator), pak zaútočte na největší náklad.
Líné asociace vydají jeden dotaz na rodiče a poté jeden další na každý přístup k potomkovi:
List<Order> orders = orderRepo.findAll();
(Order o : orders) {
o.getItems().size();
}
Opravte to načtením asociace jediným joinem:
@Query("SELECT o FROM Order o JOIN FETCH o.items") // jeden dotaz, items eagerně načteny
List<Order> findAllWithItems();
// Nebo @EntityGraph(attributePaths = "items") na metodě repository.
HikariCP je výchozí pool. Větší není lepší — příliš mnoho spojení mlátí DB. Běžný vzorec začíná poblíž cores * 2:
spring:
datasource:
hikari:
maximum-pool-size: 10 # přizpůsob kapacitě DB, ne počtu vláken
connection-timeout: 3000 # selži rychle místo hromadění požadavků
@Cacheable(value = "products", key = "#id") // po prvním načtení obsluhuj z cache
public Product findById(Long id) { return repo.findById(id).orElseThrow(); }
@CacheEvict(value = "products", key = "#p.id") // invaliduj při zápisu
public Product update(Product p) { return repo.save(p); }
Podepřete to Redisem (spring-boot-starter-data-redis) pro sdílenou cache napříč instancemi.
Senior pohovory testují, zda diagnostikujete dřív, než optimalizujete. Nejsilnější odpovědi jmenují nástroj, který úzké místo dokáže (zapněte spring.jpa.show-sql nebo datasource-proxy pro počítání dotazů, čtěte p99 latenci z Actuatoru), vysvětlí proč předimenzovaný pool škodí a berou cachování jako problém správnosti — zastaralá data a invalidace — ne jen jako regulátor rychlosti.
Knihovna IT otázek k pohovoru s podrobnými odpověďmi — od Junior po Senior.
Přispět