"Mec, j'en ai marre, j'ai hâte de faire un test là". Mon nouveau collègue finissait son onboarding de 2 semaines et il en pouvait plus.
Sauf qu'un test de charge mal pensé, ça peut être des jours de mise en place, des milliers d'euros d'infrastructure éphémère, de l'anonymisation pas prête, de la coordination complexe… Et au bout : des résultats qui vont directement à la poubelle si ton modèle de charge n'est pas réaliste.
Tu provoques des anomalies que ton propre test a fabriquées. Tu pourchasses des défauts fantômes. Tu crames ta crédibilité pour rien.
Tout ça parce que dans "test de performance", le mot qu'on entend en premier, c'est "test". On fonce comme un chien vers sa balle.
Mon collègue et moi on bossait sur un e-commerce qui plafonnait à 100 requêtes par seconde. Pas de symptôme de surcharge, pas d'alerte volumétrique.
Le mal était structurel.
30 articles dans le panier → 45 secondes. Quarante - cinq - secondes. Avec trois pelés et un tondu.
Pour diagnostiquer ça, il te faut un profiler et une conversation.
On a ouvert Blackfire, on a envoyé notre plus habile DM "t'aurais 5 minutes ?" et on a appelé deux devs en charge du paiement. On a parlé cache et SQL. Puis dépendances et planning de résolution.
La production nous avait déjà tout spoilé. Gratuitement. Un test de charge aurait noyé ce signal dans du bruit.
La prochaine fois que ton équipe perf te demande du budget pour un test de charge, demande-lui d'abord ce que l'observabilité en prod raconte déjà.
Publié à l'origine sur LinkedIn.
Voir le post sur LinkedIn →