Performance logicielle : les étapes essentielles pour commencer à optimiser

Lorsqu'une application ralentit, l'instinct de la plupart des équipes est de commencer à bricoler. Changez une bibliothèque, ajoutez un cache, mettez à niveau une machine plus grosse. C’est une mauvaise réaction, et elle coûte cher, car elle s’attaque aux symptômes avant de comprendre la maladie.

La performance a une méthode. Il existe un bon ordre d'étapes, et cela commence bien avant que vous touchiez une ligne de code. Cet article s'adresse à ceux qui comprennent déjà qu'ils doivent optimiser et veulent savoir par où commencer de manière disciplinée, sans perdre des semaines au mauvais endroit.

Je ne vais pas traiter cela comme une liste d'astuces. Les astuces résolvent des cas spécifiques et vieillissent rapidement. La méthode résout tous les cas et se maintient.

Étape 0 : Définir ce que signifie « rapide »

Tout d’abord, répondez : qu’est-ce qui est acceptable ? « Le système est lent » n'est pas un problème pouvant donner lieu à une action. "La page de référencement doit répondre en moins d'une seconde pour 95% des demandes".

Sans objectif, on ne sait jamais quand s'arrêter. L'optimisation sans objectif est un gouffre sans fond, vous pouvez toujours la rendre plus rapide et cela coûte toujours plus d'efforts pour gagner moins. Définir des délais de réponse acceptables, idéalement par percentile, transforme une sensation diffuse en critère objectif.

Cette étape semble bureaucratique, mais c'est ce qui différencie un effort d'optimisation d'une chasse sans fin. Et il s'agit autant d'une conversation sur le produit et l'entreprise que d'une question d'ingénierie : ce qui est « assez rapide » dépend de ce que l'utilisateur essaie de faire.

Étape 1 : mesurer avant de remuer

La règle la plus importante de toute cette discipline : on n’optimise pas ce que l’on ne mesure pas. Sans instrumentation, tout changement n’est qu’une supposition, et les suppositions arrivent par hasard.

Instrumentez l'application avec des métriques, des journaux structurés et, idéalement, un traçage distribué. L’objectif est de répondre à une question simple : où est passé le temps ? La réponse surprend presque toujours. Le goulot d’étranglement se situe rarement là où l’intuition le révèle.

Un schéma récurrent : l'équipe jure que le problème vient du langage ou du framework, des instruments, et découvre que 80 % du temps se passe dans une seule requête de base de données. Sans mesure, cette équipe aurait réécrit toute l’application et le problème serait toujours là.

L’outil compte moins que l’habitude. Il peut s'agir d'une solution complète d'observabilité ou d'un journal bien placé. Ce qui ne peut pas manquer, ce sont les données.

Étape 2 : Attaquez d'abord le plus gros goulot d'étranglement

Avec les données en main, la priorisation devient évidente. Il existe une règle empirique puissante : la plupart des ralentissements ont tendance à provenir d’une minorité de causes. Attaquez d'abord le plus gros.

Résistez à la tentation de faire dix micro-optimisations qui ne font pas grand-chose. Trouvez l’élément qui représente à lui seul le plus de temps et résolvez-le. Le gain résultant de l’élimination du principal goulet d’étranglement est généralement supérieur à celui de toutes les autres améliorations combinées.

Après avoir trouvé le plus grand, mesurez à nouveau. Le goulot d'étranglement s'est déplacé. La deuxième plus grande cible est désormais la nouvelle cible. La performance est un processus itératif de mesure, de correction et de remédiation, et non un effort unique.

Étape 3 : commencez par la base de données

Dans la plupart des applications métier, c'est dans les opérations bancaires que l'on perd le plus de temps. C'est pourquoi il mérite une attention prioritaire. Trois contrôles résolvent une grande partie des problèmes :

Index manquants. Requêtes qui parcourent la table entière car un index manque sur la colonne filtrée. C’est l’erreur la plus courante et la moins chère à corriger.
Le problème N+1. Lorsque le code effectue une requête pour la liste puis une requête supplémentaire pour chaque élément de la liste. Cent éléments ont fait l’objet de cent une requêtes. Il est résolu en chargeant les données associées en même temps.
Requêtes qui apportent trop de données. Rechercher dans la table entière pour utiliser trois colonnes est un gaspillage de base de données, de réseau et de mémoire.

Ces trois correctifs transforment à eux seuls la perception de la vitesse pour de nombreux systèmes. Et aucun d’entre eux ne nécessite de changer de technologie.

Étape 4 : utilisez le cache à bon escient

Le cache est l’optimisation la plus séduisante et la plus dangereuse. Il offre des gains immédiats et introduit toute une classe de nouveaux bugs : les données obsolètes.

La règle d’or : ne boucler que ce qui peut être un peu vieux sans causer de dégâts. Et définissez toujours explicitement comment le cache sera invalidé. Un cache sans stratégie d’invalidation n’est pas une optimisation, c’est une bombe à retardement.

Pour les données sensibles, les soldes, l’état des commandes, les informations qui changent et dont l’exactitude compte, réfléchissez-y à deux fois. Dans les systèmes qui traitent de l’argent ou des décisions des citoyens, l’exactitude des données l’emporte sur la rapidité. Afficher un mauvais numéro plus rapidement n’aide personne.

Il convient également de rappeler que le cache existe en plusieurs couches : dans le navigateur de l'utilisateur, dans une couche intermédiaire, sur le serveur, dans la banque. Chacun résout un problème différent et a son propre coût d’invalidation. L'erreur du débutant est d'empiler les caches sans comprendre lequel répond à quoi, et ensuite, lorsqu'une donnée tourne mal, personne ne sait dans quelle couche elle est coincée. Cartographier consciemment l'endroit où le cache fonctionne fait partie de sa bonne utilisation.

Étape 5 : pensez ensuite à l'infrastructure

La mise à niveau d’une machine plus grande ou l’ajout de plus d’instances est souvent la première étape franchie par les équipes. Ce devrait être l'un des derniers.

Faire évoluer l’infrastructure sans d’abord corriger les codes et les goulots d’étranglement bancaires revient à investir de l’argent dans le problème. Vous payez plus pour faire le même travail inefficace, mais en parallèle. Le coût augmente et l’inefficacité est toujours là, désormais plus coûteuse.

Lorsque l'optimisation du code a déjà été effectuée et que la véritable limite est la capacité, alors l'infrastructure entre en jeu. Et la bonne façon est presque toujours d'évoluer horizontalement, d'ajouter des instances, ce qui nécessite que l'application soit sans état. Il s’agit d’une décision architecturale qui mérite d’être prise tôt, car sa réparation ultérieure est laborieuse.

L'erreur qui invalide toutes les étapes

Il existe un défaut culturel qui sabote tout scénario : optimiser par l’intuition et célébrer sans mesurer le résultat. L’équipe change quelque chose, sent que c’est devenu plus rapide et passe à autre chose. Sans mesure après le changement, vous ne savez pas si la situation s'est améliorée, pire ou si rien ne s'est passé.

Chaque optimisation nécessite un avant et un après mesurables. Sinon, vous déplacez simplement le code et le tordez.

La réflexion honnête : la plupart des problèmes de performances ne nécessitent pas de génies ou d'outils coûteux. Cela demande de la discipline. Mesurez, priorisez, corrigez le plus gros goulot d’étranglement, corrigez-le. Les équipes qui suivent cet ordre résolvent en quelques jours ce que les équipes qui devinent ne peuvent résoudre en quelques mois.

Une bonne performance est moins une question de talent que de processus. Ceux qui internalisent ces mesures arrêtent d’éteindre les incendies et commencent à les prévenir.

Si votre équipe continue de résoudre les lenteurs dans le noir, le problème n’est peut-être pas technique, mais méthodologique. Il existe d'autres articles sur le blog sur la qualité, l'observabilité et l'évolutivité qui complètent cette feuille de route. Si vous souhaitez échanger des idées sur la manière de structurer cela dans votre organisation, cela vaut la peine d'en parler.