Qu’est-ce que l’benchmarking Continu?
Le Benchmarking Continu est une pratique de développement logiciel où les membres d’une équipe évaluent leur travail fréquemment, en général, chaque personne fait cela au moins une fois par jour - ce qui conduit à plusieurs benchmarks par jour. Chaque benchmark est vérifié par une construction automatisée pour détecter les régressions de performances le plus rapidement possible. De nombreuses équipes trouvent que cette approche conduit à des régressions de performances nettement réduites et permet à une équipe de développer des logiciels performants plus rapidement.
À présent, tout le monde dans l’industrie du logiciel est au courant de l’intégration continue (CI). Au niveau fondamental, la CI consiste à détecter et à prévenir les régressions de fonctionnalités logicielles avant qu’elles n’arrivent en production. De la même manière, le benchmarking continu (CB) consiste à détecter et à prévenir les régressions de performance logicielle avant qu’elles n’arrivent en production. Pour les mêmes raisons que les tests unitaires sont exécutés en CI pour chaque changement de code, des tests de performance devraient être exécutés en CB pour chaque changement de code. Cette analogie est si pertinente en fait, que le premier paragraphe de cette section n’est qu’une version Mad Libs de l’introduction de Martin Fowler à l’intégration continue en 2006.
🐰 Les bugs de performance sont des bugs !
Benchmarking en CI
Mythe : Vous ne pouvez pas exécuter de benchmarks en CI
La plupart des harnais de benchmarking utilisent l’horloge murale du système pour mesurer la latence ou le débit. Ceci est très utile, car ce sont précisément ces paramètres qui nous concernent le plus en tant que développeurs. Cependant, les environnements de CI à usage général sont souvent bruyants et inconsistants lors de la mesure du temps d’horloge murale. Lors du benchmarking continu, cette volatilité ajoute un bruit indésirable dans les résultats.
Il existe plusieurs options pour gérer cela :
- Benchmarking relatif
- Des exécutants de CI dédiés
- Changer de harnais de benchmarking pour l’un qui compte les instructions par opposition au temps d’horloge murale
Ou simplement embrasser le chaos ! Le benchmarking continu n’a pas besoin d’être parfait. Oui, réduire la volatilité et donc le bruit dans votre environnement de benchmarking continu vous permettra de détecter des régressions de performance de plus en plus fines. Cependant, ne laissez pas la perfection être l’ennemie du bien ici !
Vous pourriez regarder ce graphique et penser, “Waouh, c’est fou !” Mais demandez-vous, votre processus de développement actuel peut-il détecter une régression de performance de deux ou même dix fois avant qu’elle n’affecte vos utilisateurs ? Probablement pas ! Maintenant, ça, c’est fou !
Même avec tout le bruit d’un environnement de CI, le suivi des benchmarks d’horloge murale peut encore rapporter de grands bénéfices en détectant les régressions de performance avant qu’elles n’atteignent vos clients en production. Avec le temps, à mesure que la gestion des performances de votre logiciel mûrit, vous pourrez vous améliorer à partir de là. En attendant, utilisez simplement votre CI habituelle.
La Performance Compte
Mythe : Vous ne pouvez pas remarquer 100ms de latence
Il est courant d’entendre des gens affirmer que les humains ne peuvent percevoir 100ms de latence. Un article du groupe Nielsen sur les temps de réponse est souvent cité pour cette affirmation.
0,1 seconde est à peu près la limite pour faire en sorte que l’utilisateur ait l’impression que le système réagit instantanément, ce qui signifie qu’aucun retour spécial n’est nécessaire excepté pour afficher le résultat.
- Jakob Nielsen, 1 Jan 1993
Mais ce n’est tout simplement pas vrai.
Sur certaines tâches, les gens peuvent percevoir aussi peu que 2ms de latence.
Un moyen facile de le prouver est une expérience de Dan Luu: ouvrez votre terminal et exécutez sleep 0; echo "ping" puis exécutez sleep 0.1; echo "pong". Vous avez remarqué la différence, n’est-ce pas‽
Un autre point commun de confusion est la distinction entre la perception de la latence et les temps de réaction humains. Même s’il faut environ 200ms pour répondre à un stimulus visuel, cela est indépendant de la perception de l’événement lui-même. Par analogie, vous pouvez remarquer que votre train a deux minutes de retard (latence perçue) même si le trajet en train dure deux heures (temps de réaction).
La performance compte ! La performance est une caractéristique !
- Chaque 100ms plus rapide → 1% de conversions en plus (Mobify, gagnant +380 000$/an)
- 50% plus rapide → 12% de ventes en plus (AutoAnything)
- 20% plus rapide → 10% de conversions en plus (Furniture Village)
- 40% plus rapide → 15% de plus d’inscriptions (Pinterest)
- 850ms plus rapide → 7% de conversions en plus (COOK)
- Chaque seconde plus lent → 10% d’utilisateurs en moins (BBC)
Avec la fin de la loi de Moore, les charges de travail qui peuvent s’exécuter en parallèle devront être parallélisées. Cependant, la plupart des charges de travail doivent s’exécuter en série, et le fait de simplement jeter plus de calcul sur le problème devient rapidement une solution intractable et coûteuse.
Le Benchmarking Continu est un élément clé pour développer et maintenir des logiciels modernes performants face à ce changement.
Outils de Benchmarking Continu
Avant de créer Bencher, nous avons cherché un outil qui pourrait :
- Suivre les benchmarks à travers plusieurs langages
- Intégrer sans problème la sortie des harnais de benchmarking standard des langages
- Extensible pour une sortie de harnais de benchmarking personnalisé
- Open source et capable d’auto-hébergement
- Fonctionner avec plusieurs hôtes de CI
- Authentification et autorisation des utilisateurs
Malheureusement, rien qui remplissait tous ces critères n’existait. Voir art antérieur pour une liste complète des outils de benchmarking existants dont nous nous sommes inspirés.
Benchmarking Continu dans les Grandes Technologies
Des outils comme Bencher ont été développés en interne chez Microsoft, Facebook (maintenant Meta), Apple, Amazon, Netflix, et Google parmi d’innombrables autres. En tant que titans de l’industrie, ils comprennent l’importance de surveiller la performance pendant le développement et d’intégrer ces informations dans le processus de développement grâce au CB. Nous avons construit Bencher pour apporter le benchmarking continu du secret des grandes technologies à la communauté open source. Pour des liens vers des articles liés au benchmarking continu en provenance de grandes technologies, voir art antérieur.
Bencher: Benchmarking Continu
Bencher est une suite d’outils de benchmarking continu. Avez-vous déjà eu une régression de performance qui a impacté vos utilisateurs ? Bencher aurait pu empêcher cela de se produire. Bencher vous permet de détecter et de prévenir les régressions de performance avant qu’elles n’arrivent en production.
- Exécuter: Exécutez vos benchmarks localement ou en CI en utilisant vos outils de benchmarking préférés. La CLI
bencherenveloppe simplement votre harnais de benchmarking existant et stocke ses résultats. - Suivre: Suivez les résultats de vos benchmarks au fil du temps. Surveillez, interrogez et graphiquez les résultats à l’aide de la console web Bencher en fonction de la branche source, du banc d’essai et de la mesure.
- Détecter: Détectez les régressions de performances en CI. Bencher utilise des analyses de pointe et personnalisables pour détecter les régressions de performances avant qu’elles n’arrivent en production.
Pour les mêmes raisons que les tests unitaires sont exécutés en CI pour prévenir les régressions de fonctionnalités, les benchmarks devraient être exécutés en CI avec Bencher pour prévenir les régressions de performance. Les bugs de performance sont des bugs !
Commencez à détecter les régressions de performances en CI — essayez Bencher Cloud gratuitement.
Le Benchmarking Continu vs Comparaison de Benchmark Locale
Il existe plusieurs bancs d’essai qui vous permettent de comparer les résultats localement. La comparaison locale est excellente pour itérer rapidement lors de l’optimisation des performances. Cependant, elle ne doit pas être utilisée pour détecter les régressions de performances de manière continue. Tout comme le fait de pouvoir exécuter des tests unitaires localement n’élimine pas le besoin d’intégration continue (CI), le fait de pouvoir exécuter et comparer des benchmarks localement n’élimine pas le besoin de benchmarking continu (CB).
Bencher offre plusieurs caractéristiques que les outils de comparaison de benchmarking locaux ne peuvent pas offrir :
- Comparaison du même benchmark entre différents bancs d’essai
- Comparaison de benchmarks à travers différents langages et bancs d’essai
- Collaboration et partage des résultats de benchmark
- Exécution des benchmarks sur des bancs d’essai dédiés pour minimiser le bruit
- Fini les copier-coller
Le Benchmarking Continu vs Gestion de Performance des Applications (APM)
La Gestion de la Performance des Applications (APM) est un outil essentiel pour les services logiciels modernes. Cependant, l’APM est conçu pour être utilisé en production. Lorsqu’une régression de performance est détectée, elle a déjà un impact sur vos clients.
La plupart des défauts finissent par coûter plus cher que ce qu’il aurait coûté pour les prévenir. Les défauts sont coûteux lorsqu’ils se produisent, à la fois les coûts directs de correction des défauts et les coûts indirects en raison des relations endommagées, des pertes d’affaires et du temps de développement perdu.
— Kent Beck, Extreme Programming Explained
Bencher offre plusieurs caractéristiques que les outils APM ne peuvent pas offrir :
- Détection et prévention des régressions de performance avant qu’elles n’atteignent la production
- Changements de performances et impacts inclus dans la révision du code
- Pas de surcharge dans les environnements de production
- Efficace pour les déploiements sur site
- Pas de modifications du code source de production
Le Benchmarking Continu vs Observabilité
Une rose, quel que soit son nom, sentirait aussi bon. Voir Le Benchmarking Continu vs Gestion de Performance des Applications ci-dessus.
Le Benchmarking Continu vs Intégration Continue (CI)
Le Benchmarking Continu (CB) est complémentaire à l’Intégration Continue (CI). Pour les mêmes raisons que les tests unitaires sont exécutés dans CI pour chaque modification de code, les tests de performance doivent être exécutés dans CB pour chaque modification de code.
Alors que les tests unitaires et d’acceptation sont largement acceptés comme pratiques de développement standard, cette tendance ne s’est pas poursuivie dans le domaine des tests de performance. Actuellement, les outils communs poussent les testeurs à créer du code à jeter et une mentalité de clic-et-script. Traiter les tests de performance en tant que citoyen de première classe permet la création de meilleurs tests qui couvrent plus de fonctionnalités, conduisant à un meilleur outillage pour créer et exécuter des tests de performance, résultant en une suite de tests qui est maintenable et qui peut être testée elle-même.
Le Benchmarking Continu vs Test Continu de Charge
Pour comprendre la différence entre le Benchmarking Continu et le Test Continu de Charge, vous devez comprendre la différence entre le benchmarking et le test de charge.
| Type de Test | Portée du Test | Utilisateurs de Test |
|---|---|---|
| Benchmarking | Fonction - Service | Un - Plusieurs |
| Test de Charge | Service | Plusieurs |
Le benchmarking peut tester la performance d’un logiciel à partir du niveau fonction (micro-benchmarks) jusqu’au niveau service (macro-benchmarks). Les benchmarks sont excellents pour tester la performance d’une partie spécifique de votre code de manière isolée. Le test de charge ne teste la performance des logiciels qu’au niveau du service et simule plusieurs utilisateurs concurrents. Les tests de charge sont excellents pour tester la performance de l’ensemble du service sous une charge spécifique.
🍦 Imaginez que nous voulions suivre la performance d’un camion de crème glacée. Le benchmarking pourrait être utilisé pour mesurer combien de temps il faut pour servir une boule de glace (micro-benchmark), et le benchmarking pourrait également être utilisé pour mesurer combien de temps il faut à un seul client pour commander, obtenir sa glace, et payer (macro-benchmark). Le test de charge pourrait être utilisé pour voir comment le camion de glace sert 100 clients par une chaude journée d’été.