Performance-tuning in Spring Boot gaat vooral over de databasegrens: connection pooling, caching, en het uitroeien van het N+1-queryprobleem. Meet eerst (Micrometer + Actuator-metrics), en pak dan de grootste kostenpost aan.
Lazy associations vuren één query per parent af, en dan nog één per toegang tot een child:
List<Order> orders = orderRepo.findAll();
(Order o : orders) {
o.getItems().size();
}
Los het op door de associatie in één enkele join op te halen:
@Query("SELECT o FROM Order o JOIN FETCH o.items") // één query, items eager geladen
List<Order> findAllWithItems();
// Of @EntityGraph(attributePaths = "items") op de repository-methode.
HikariCP is de default pool. Groter is niet beter — te veel connecties belasten de DB overmatig. Een gangbare formule begint rond cores * 2:
spring:
datasource:
hikari:
maximum-pool-size: 10 # match de DB-capaciteit, niet het aantal threads
connection-timeout: 3000 # faal snel in plaats van requests op te stapelen
@Cacheable(value = "products", key = "#id") // serveer uit cache na de eerste load
public Product findById(Long id) { return repo.findById(id).orElseThrow(); }
@CacheEvict(value = "products", key = "#p.id") // invalideer bij een write
public Product update(Product p) { return repo.save(p); }
Onderbouw het met Redis (spring-boot-starter-data-redis) voor een gedeelde cache over instances heen.
Senior-interviews testen of je diagnosticeert voordat je optimaliseert. De sterkste antwoorden noemen de tool die de bottleneck bewijst (zet spring.jpa.show-sql of datasource-proxy aan om queries te tellen, lees de p99-latency uit Actuator), leggen uit waarom een te grote pool schaadt, en behandelen caching als een correctheidsprobleem — verouderde data en invalidatie — niet slechts als een snelheidsknop.
Een bibliotheek met IT-sollicitatievragen met gedetailleerde antwoorden — van Junior tot Senior.
Doneren