Ytelsestuning i Spring Boot handler mest om databasegrensen: connection pooling, caching og å drepe N+1-spørringsproblemet. Mål først (Micrometer + Actuator-metrikker), angrip deretter den største kostnaden.
Late assosiasjoner sender én spørring per parent, deretter én til per tilgang til et barn:
List<Order> orders = orderRepo.findAll(); // 1 spørring
(Order o : orders) {
o.getItems().size();
}
Fiks det ved å hente assosiasjonen i én enkelt join:
@Query("SELECT o FROM Order o JOIN FETCH o.items") // én spørring, items lastet ivrig
List<Order> findAllWithItems();
// Eller @EntityGraph(attributePaths = "items") på repository-metoden.
HikariCP er standard-poolen. Større er ikke bedre — for mange tilkoblinger overbelaster databasen. En vanlig formel starter nær cores * 2:
spring:
datasource:
hikari:
maximum-pool-size: 10 # match DB-kapasitet, ikke trådantall
connection-timeout: 3000 # feil raskt i stedet for å hope opp forespørsler
@Cacheable(value = "products", key = "#id") // server fra cache etter første lasting
public Product findById(Long id) { return repo.findById(id).orElseThrow(); }
@CacheEvict(value = "products", key = "#p.id") // invalider ved skriving
public Product update(Product p) { return repo.save(p); }
Støtt det med Redis (spring-boot-starter-data-redis) for en delt cache på tvers av instanser.
Senior-intervjuer tester om du diagnostiserer før du optimaliserer. De sterkeste svarene navngir verktøyet som beviser flaskehalsen (aktiver spring.jpa.show-sql eller datasource-proxy for å telle spørringer, les p99-latens fra Actuator), forklarer hvorfor en overdimensjonert pool skader, og behandler caching som et korrekthetsproblem — utdaterte data og invalidering — ikke bare en fartsknott.
Et bibliotek av IT-intervjuspørsmål med detaljerte svar — fra Junior til Senior.
Doner