Akordimi i performancës në Spring Boot ka të bëjë kryesisht me kufirin e databazës: connection pooling, caching, dhe vrasjen e problemit N+1. Mat fillimisht (metrikat Micrometer + Actuator), pastaj sulmo koston më të madhe.
Asociacionet lazy lëshojnë një query për çdo parent, pastaj një tjetër për çdo akses te child-i:
List<Order> orders = orderRepo.findAll();
(Order o : orders) {
o.getItems().size();
}
Rregulloje duke marrë asociacionin në një join të vetëm:
@Query("SELECT o FROM Order o JOIN FETCH o.items") // një query, items ngarkohen eager
List<Order> findAllWithItems();
// Ose @EntityGraph(attributePaths = "items") mbi metodën e repository-t.
HikariCP është pool-i default. Më i madh nuk është më i mirë — shumë lidhje e mbingarkojnë DB-në. Një formulë e zakonshme fillon rreth cores * 2:
spring:
datasource:
hikari:
maximum-pool-size: 10 # përputhu me kapacitetin e DB-së, jo me numrin e thread-eve
connection-timeout: 3000 # dështo shpejt në vend që të grumbullohen kërkesat
@Cacheable(value = "products", key = "#id") // shërbe nga cache pas ngarkimit të parë
public Product findById(Long id) { return repo.findById(id).orElseThrow(); }
@CacheEvict(value = "products", key = "#p.id") // invalido në shkrim
public Product update(Product p) { return repo.save(p); }
Mbështete me Redis (spring-boot-starter-data-redis) për një cache të ndarë nëpër instanca.
Intervistat senior testojnë nëse diagnostikoni para se të optimizoni. Përgjigjet më të forta emërtojnë mjetin që provon bottleneck-un (aktivizo spring.jpa.show-sql ose datasource-proxy për të numëruar query-t, lexo latencën p99 nga Actuator), shpjegojnë pse një pool i mbipërmasuar dëmton, dhe e trajtojnë caching-un si një problem korrektësie — të dhëna të vjetruara dhe invalidim — jo thjesht një çelës shpejtësie.
Një bibliotekë pyetjesh intervistash IT me përgjigje të detajuara — nga Junior te Senior.
Dhuro