Uglaševanje zmogljivosti v Spring Boot je večinoma o meji baze podatkov: connection pooling, predpomnjenje in ubijanje problema N+1. Najprej meri (metrike Micrometer + Actuator), nato napadi največji strošek.
Lazy asociacije sprožijo eno poizvedbo na nadrejeni element, nato eno dodatno na vsak dostop do otroka:
List<Order> orders = orderRepo.findAll();
(Order o : orders) {
o.getItems().size();
}
Popravi ga tako, da asociacijo pridobiš v enem samem joinu:
@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 je privzeti pool. Večji ni boljši — preveč povezav zaduši bazo. Pogosta formula se začne blizu 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); }
Podpri ga z Redis (spring-boot-starter-data-redis) za deljeni predpomnilnik med instancami.
Senior razgovori preverjajo, ali diagnosticiraš, preden optimiziraš. Najmočnejši odgovori poimenujejo orodje, ki dokaže ozko grlo (omogoči spring.jpa.show-sql ali datasource-proxy za štetje poizvedb, preberi p99 zakasnitve iz Actuatorja), pojasnijo, zakaj prevelik pool škoduje, in obravnavajo predpomnjenje kot problem pravilnosti — zastareli podatki in invalidacija — ne le kot gumb za hitrost.
Knjižnica IT vprašanj za razgovore s podrobnimi odgovori — od začetnika do izkušenega.
Doniraj