Comment optimiser les performances d'une application Spring Boot : pools, caching, N+1 ?

Question

IT Interview Practice · Accepted Answer

L'optimisation des performances dans Spring Boot concerne surtout la frontière avec la base de données : connection pooling, caching et élimination du problème de requête N+1. Mesurez d'abord (métriques Micrometer + Actuator), puis attaquez le coût le plus élevé. ## Le problème N+1 — le tueur numéro un de JPA Les associations lazy émettent une requête par parent, puis une *de plus* par accès à un enfant : ```java List orders = orderRepo.findAll(); // 1 requête for (Order o : orders) { o.getItems().size(); // N requêtes supplémentaires — une PAR order (le « N+1 ») } ``` Corrigez-le en récupérant l'association en une seule jointure : ```java @Query("SELECT o FROM Order o JOIN FETCH o.items") // une requête, items chargés d'emblée List findAllWithItems(); // Ou @EntityGraph(attributePaths = "items") sur la méthode du repository. ``` ## Dimensionnement du connection pool HikariCP est le pool par défaut. Plus grand n'est **pas** meilleur — trop de connexions font peiner la DB. Une formule courante démarre autour de `cores * 2` : ```yaml spring: datasource: hikari: maximum-pool-size: 10 # ajustez à la capacité de la DB, pas au nombre de threads connection-timeout: 3000 # échouer rapidement plutôt que d'empiler les requêtes ``` ## Mettre en cache les lectures fréquentes ```java @Cacheable(value = "products", key = "#id") // sert depuis le cache après le premier chargement public Product findById(Long id) { return repo.findById(id).orElseThrow(); } @CacheEvict(value = "products", key = "#p.id") // invalide à l'écriture public Product update(Product p) { return repo.save(p); } ``` Adossez-le à Redis (`spring-boot-starter-data-redis`) pour un cache partagé entre instances. ## Pourquoi c'est important Les entretiens seniors testent si vous diagnostiquez avant d'optimiser. Les meilleures réponses nomment l'outil qui *prouve* le goulet d'étranglement (activer `spring.jpa.show-sql` ou datasource-proxy pour compter les requêtes, lire la latence p99 depuis Actuator), expliquent *pourquoi* un pool surdimensionné nuit, et traitent le caching comme un problème de justesse — données périmées et invalidation — pas seulement comme un bouton de vitesse.

Le problème N+1 — le tueur numéro un de JPA

Dimensionnement du connection pool

Mettre en cache les lectures fréquentes

Pourquoi c'est important

Questions connexes