Suorituskyvyn virittäminen Spring Bootissa koskee enimmäkseen tietokantarajapintaa: connection poolingia, cachingia ja N+1-kyselyongelman tappamista. Mittaa ensin (Micrometer + Actuator-metriikat), hyökkää sitten suurimman kustannuksen kimppuun.
Laiskat assosiaatiot tekevät yhden kyselyn per parent, sitten yhden lisää per lapsen käyttö:
List<Order> orders = orderRepo.findAll();
(Order o : orders) {
o.getItems().size();
}
Korjaa se hakemalla assosiaatio yhdessä joinissa:
@Query("SELECT o FROM Order o JOIN FETCH o.items") // one query, items eagerly loaded
List<Order> findAllWithItems();
// Or @EntityGraph(attributePaths = "items") on the repository method.
HikariCP on oletuspooli. Suurempi ei ole parempi — liian monta yhteyttä ruuhkauttaa DB:n. Yleinen kaava aloittaa lähellä cores * 2:
spring:
datasource:
hikari:
maximum-pool-size: 10 # match DB capacity, not thread count
connection-timeout: 3000 # fail fast instead of piling up requests
@Cacheable(value = "products", key = "#id") // serve from cache after first load
public Product findById(Long id) { return repo.findById(id).orElseThrow(); }
@CacheEvict(value = "products", key = "#p.id") // invalidate on write
public Product update(Product p) { return repo.save(p); }
Tue sitä Redisillä (spring-boot-starter-data-redis) jaettua cachea varten instanssien välillä.
Senior-haastattelut testaavat, diagnosoitko ennen kuin optimoit. Vahvimmat vastaukset nimeävät työkalun, joka todistaa pullonkaulan (ota käyttöön spring.jpa.show-sql tai datasource-proxy laskeaksesi kyselyt, lue p99-latenssi Actuatorista), selittävät miksi ylimitoitettu pooli haittaa, ja kohtelevat cachingia oikeellisuusongelmana — vanhentunut data ja invalidointi — ei vain nopeusnuppina.
Kirjasto IT-haastattelukysymyksiä yksityiskohtaisine vastauksineen — Juniorista Senioriin.
Lahjoita