A teljesítményhangolás a Spring Bootban jórészt az adatbázis-határról szól: connection pooling, caching és az N+1 lekérdezési probléma kiiktatása. Előbb mérj (Micrometer + Actuator metrikák), aztán támadd a legnagyobb költséget.
A lazy asszociációk parentenként egy lekérdezést indítanak, majd gyerekenkénti hozzáférésenként még egyet:
List<Order> orders = orderRepo.findAll();
(Order o : orders) {
o.getItems().size();
}
Javítsd úgy, hogy egyetlen joinban kéred le az asszociációt:
@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.
A HikariCP az alapértelmezett pool. A nagyobb nem jobb — túl sok connection megvergeli a DB-t. Egy gyakori képlet a cores * 2 közeléből indul:
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); }
Támogasd Redisszel (spring-boot-starter-data-redis) egy példányok között megosztott cache-hez.
A senior interjúk azt tesztelik, hogy diagnosztizálsz-e, mielőtt optimalizálsz. A legerősebb válaszok megnevezik azt az eszközt, amely bizonyítja a szűk keresztmetszetet (kapcsold be a spring.jpa.show-sql-t vagy a datasource-proxyt a lekérdezések számolásához, olvasd a p99 latenciát az Actuatorból), elmagyarázzák, miért árt egy túlméretezett pool, és a cachinget helyességi problémaként kezelik — elavult adat és invalidáció —, nem csupán sebességi kapcsolóként.
IT interjúkérdések gyűjteménye részletes válaszokkal — Juniortól Seniorig.
Adományozás