Reglarea performanței în Spring Boot ține în principal de granița cu baza de date: connection pooling, caching și eliminarea problemei de interogare N+1. Măsoară mai întâi (metrici Micrometer + Actuator), apoi atacă cel mai mare cost.
Asocierile lazy emit o interogare per parent, apoi încă una la fiecare accesare a copilului:
List<Order> orders = orderRepo.findAll();
(Order o : orders) {
o.getItems().size();
}
Rezolvă aducând asocierea într-un singur join:
@Query("SELECT o FROM Order o JOIN FETCH o.items") // o interogare, items încărcate eager
List<Order> findAllWithItems();
// Sau @EntityGraph(attributePaths = "items") pe metoda de repository.
HikariCP este pool-ul implicit. Mai mare nu înseamnă mai bine — prea multe conexiuni suprasolicită baza de date. O formulă comună pornește aproape de cores * 2:
spring:
datasource:
hikari:
maximum-pool-size: 10 # potrivește capacitatea DB, nu numărul de thread-uri
connection-timeout: 3000 # eșuează rapid în loc să acumulezi cereri
@Cacheable(value = "products", key = "#id") // servește din cache după prima încărcare
public Product findById(Long id) { return repo.findById(id).orElseThrow(); }
@CacheEvict(value = "products", key = "#p.id") // invalidează la scriere
public Product update(Product p) { return repo.save(p); }
Susține-l cu Redis (spring-boot-starter-data-redis) pentru un cache partajat între instanțe.
Interviurile pentru seniori testează dacă diagnostichezi înainte să optimizezi. Cele mai puternice răspunsuri numesc unealta care dovedește bottleneck-ul (activează spring.jpa.show-sql sau datasource-proxy ca să numeri interogările, citește latența p99 din Actuator), explică de ce un pool supradimensionat dăunează și tratează caching-ul ca pe o problemă de corectitudine — date învechite și invalidare — nu doar ca pe un buton de viteză.
O bibliotecă de întrebări de interviu IT cu răspunsuri detaliate — de la Junior la Senior.
Donează