veilletech.frCe qui a failli être publié
Une équipe s'apprêtait à publier une analyse de performance affirmant que trois requêtes étaient devenues 2 à 4 fois plus lentes.
Les trois chiffres étaient faux.
Le protocole était pourtant sérieux
C'est ce qui rend le cas instructif. Les précautions habituelles avaient été prises : une requête d'un jeu de tests reconnu, un seul commit, un seul jeu de données, une seule station de travail à 16 cœurs.
Deux mesures espacées de quatre heures. Le matin, une médiane de 2 822 ms. Le soir, un chiffre nettement différent — sans qu'une ligne de code ait changé entre les deux.
Le même binaire, sur la même machine, exécutant la même requête, donnait des résultats différents selon l'heure de la journée.
Pourquoi c'est un piège général
Fixer la version, fixer les données, fixer la machine : on a le sentiment d'avoir isolé la variable. Et une variable non contrôlée reste pourtant dans le décor — température du processeur, fréquence dynamique, charge résiduelle du système, état thermique après plusieurs heures d'usage.
Aucune de ces précautions n'était inutile. Elles étaient simplement insuffisantes, et rien ne le signalait : les mesures étaient cohérentes entre elles à un moment donné, ce qui donne une fausse impression de fiabilité.
Ce qu'il faut en tirer
La leçon dépasse largement les bases de données. Avant de publier un écart de performance :
- mesurer plusieurs fois, à des moments différents
- vérifier que l'écart survit à la répétition
- se méfier d'un résultat stable sur une seule session
Sans cela, vous mesurez l'état de votre machine, pas la performance de votre code.
À retenir
Une équipe a évité de publier trois chiffres faux parce qu'elle a refait la mesure. C'est le seul contrôle qui aurait pu attraper l'erreur — et c'est précisément celui qu'on saute quand le résultat va dans le sens attendu.
Source : dev.to