Optimisation des performances

Depuis la première leçon, un même défaut revient : une liste chargée en une requête, puis une requête par élément pour compléter les données manquantes. Cinquante commandes affichées, cent une requêtes émises. Le code Java est irréprochable, les annotations sont celles de la documentation, les tests passent. Et la page met huit secondes à s'afficher en production.

Ce chapitre est le dénouement. Il commence par le diagnostic, parce qu'on ne peut pas corriger ce qu'on ne mesure pas, et parce que l'intuition se trompe systématiquement sur ce point : la requête coûteuse n'est presque jamais celle qu'on soupçonne. Il présente ensuite les trois outils qui résolvent le N+1 — JOIN FETCH, @EntityGraph, @BatchSize — avec le critère qui permet de choisir entre eux, car ils ne sont pas interchangeables et chacun a une limite dure.

Vient ensuite le cas que JOIN FETCH ne sait pas traiter : la pagination sur une collection chargée. C'est un piège spécifique, silencieux, qui fait charger toute la table en mémoire pendant qu'un avertissement discret défile dans les journaux.