Optimisation des performances

Une API Spring Boot est presque toujours rapide en développement. La base contient trente lignes, elle tourne sur la même machine, un seul utilisateur appelle un endpoint à la fois. Rien ne peut être lent dans ces conditions, et c'est précisément pour cela que les problèmes de performance ne se découvrent jamais avant la production.

Le décalage vient de trois différences que le poste de développement ne reproduit pas. Le volume : une jointure sans index coûte le même prix sur trente lignes et devient un balayage complet sur trois millions. La latence réseau : une requête SQL passe de 0,1 ms en local à 2 ms vers un serveur distant, et une opération qui en déclenche deux cents passe de vingt millisecondes à quatre secondes. Et la concurrence : ce qui va bien pour un utilisateur peut épuiser un pool de connexions à cinquante.

La tentation, face à une API lente, est d'ajouter du cache. C'est presque toujours prématuré : le cache masque le symptôme, complique l'invalidation, introduit des incohérences, et ne corrige rien. Avant d'optimiser, on mesure ; avant de mettre en cache, on corrige la cause. Dans une API Spring typique, cette cause est trois fois sur quatre le nombre de requêtes SQL exécutées, pas leur durée individuelle.