Dostrajanie wydajności w Spring Boot to głównie kwestia granicy z bazą danych: pula połączeń, cachowanie i eliminacja problemu zapytań N+1. Najpierw mierz (metryki Micrometer + Actuator), a potem atakuj największy koszt.
Leniwe asocjacje wysyłają jedno zapytanie na rodzica, a potem jedno dodatkowe na każdy dostęp do dziecka:
List<Order> orders = orderRepo.findAll();
(Order o : orders) {
o.getItems().size();
}
Napraw to, pobierając asocjację jednym joinem:
@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 to domyślna pula. Większa nie znaczy lepsza — zbyt wiele połączeń dławi bazę. Częsta formuła startuje w okolicach 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); }
Oprzyj to o Redis (spring-boot-starter-data-redis) dla współdzielonego cache między instancjami.
Rozmowy na poziomie senior sprawdzają, czy diagnozujesz przed optymalizacją. Najmocniejsze odpowiedzi nazywają narzędzie, które dowodzi wąskiego gardła (włącz spring.jpa.show-sql lub datasource-proxy, by policzyć zapytania, odczytaj latencję p99 z Actuatora), wyjaśniają, dlaczego przewymiarowana pula szkodzi, i traktują cachowanie jako problem poprawności — nieaktualne dane i inwalidacja — a nie tylko pokrętło prędkości.
Biblioteka pytań rekrutacyjnych IT ze szczegółowymi odpowiedziami — od Juniora do Seniora.
Wesprzyj