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 les métriques qui nous importent 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 :
- Exécutants sur Machine Dédiée
- Benchmarking Continu Relatif
- Passer à un harnais de benchmarking qui compte les instructions plutôt que le temps d’horloge murale
De loin, les Exécutants sur Machine Dédiée sont la meilleure option dans presque tous les cas. Bencher propose des Exécutants sur Machine Dédiée avec moins de 2% de variance. Comparez cela aux exécutants de GitHub Action, qui peuvent présenter plus de 30% de variance entre les exécutions. Réduire la volatilité et donc le bruit dans votre environnement de Benchmarking Continu vous permettra de détecter des régressions de performance toujours plus fines.
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 Nielsen Group sur les temps de réponse est souvent cité pour étayer 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 fonctionnalité !
- 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 puissance de calcul sur le problème devient rapidement une solution intraitable 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 :
- Exécuter les benchmarks sur exactement le même matériel physique dédié, aussi bien en local qu’en CI
- Suivre les benchmarks à travers plusieurs langages
- Intégrer sans problème la sortie des harnais de benchmarking standard des langages
- Être extensible pour une sortie de harnais de benchmarking personnalisée
- Open source et capable d’auto-hébergement
- Fonctionner avec plusieurs hôtes de CI
- Authentification et autorisation des utilisateurs
Malheureusement, rien qui remplisse tous ces critères n’existait. Voir l’art antérieur pour une liste complète des outils de benchmarking existants dont nous nous sommes inspirés.
Benchmarking Continu en dehors de la CI
La CI est censée être une vérification finale, et non le seul endroit où les tests sont effectués. Bencher est le premier outil de Benchmarking Continu à vous permettre d’exécuter vos benchmarks sur exactement le même matériel physique dédié, aussi bien en local qu’en CI. Cela permet aux développeurs et aux agents de comparer leur travail local en cours avec n’importe quel point de l’historique de performance de leur projet.
Lorsqu’il s’exécute sur du matériel local, Bencher sur Machine Dédiée vous permet de continuer à effectuer plusieurs tâches à la fois. Plus besoin de tout arrêter sur votre système, de récupérer une ancienne branche et d’exécuter une comparaison.
Lorsqu’il s’exécute dans un environnement cloud, Bencher sur Machine Dédiée vous permet de faire confiance aux résultats. Pas d’inquiétude à avoir concernant les voisins bruyants, la limitation de ressources ou les changements d’hôte en cours de route.
Le Benchmarking Continu dans les Grandes Entreprises Technologiques
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 Benchmarking Continu. Nous avons construit Bencher pour apporter le Benchmarking Continu à la communauté open source, hors des murs des grandes entreprises technologiques. Pour des liens vers des articles liés au Benchmarking Continu provenant des grandes entreprises technologiques, voir l’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 ne soient fusionnées.
- Exécuter: Exécutez vos benchmarks localement ou en CI en utilisant exactement les mêmes runners bare metal et vos outils de benchmarking préférés. La CLI
bencherorchestre l’exécution de vos benchmarks sur bare metal 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 localement ou en CI en utilisant exactement le même matériel bare metal. Bencher utilise des analyses de pointe et personnalisables pour détecter les régressions de performances avant qu’elles ne soient fusionnées.
Pour les mêmes raisons que les tests unitaires sont exécutés pour prévenir les régressions de fonctionnalités, les benchmarks devraient être exécutés 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 — essayez Bencher Cloud gratuitement.
Le Benchmarking Continu vs Comparaison de Benchmarks Locale
Il existe plusieurs harnais de benchmarking 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 performance de manière continue. Tout comme le fait de pouvoir exécuter des tests unitaires localement n’élimine pas le besoin de CI, le fait de pouvoir exécuter et comparer des benchmarks localement n’élimine pas le besoin de Benchmarking Continu.
Bencher offre plusieurs fonctionnalités que les outils de comparaison de benchmarks locaux ne peuvent pas offrir :
- Comparaison du même benchmark entre différents bancs d’essai
- Comparaison de benchmarks à travers différents langages et harnais
- 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 la 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é de les prévenir. Les défauts sont coûteux lorsqu’ils se produisent, à la fois par les coûts directs de correction et par les coûts indirects dus aux relations endommagées, aux pertes d’affaires et au temps de développement perdu.
— Kent Beck, Extreme Programming Explained
Bencher offre plusieurs fonctionnalités que les outils APM ne peuvent pas offrir :
- Détecter les régressions de performance avant qu’elles ne soient fusionnées
- Inclure les changements et impacts sur la performance dans la revue de code
- Pas de surcharge dans les environnements de production
- Efficace pour les déploiements sur site
- Aucune modification du code source de production
Le Benchmarking Continu vs Observabilité
Une rose, quel que soit son nom, sentirait tout aussi bon. Voir Le Benchmarking Continu vs Gestion de la 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 en CI pour chaque changement de code, les tests de performance devraient être exécutés en CB pour chaque changement de code.
Alors que les tests unitaires et d’acceptation sont largement adoptés comme pratiques de développement standard, cette tendance ne s’est pas poursuivie dans le domaine des tests de performance. Actuellement, les outils courants poussent les testeurs à créer du code jetable et une mentalité de clic-et-script. Traiter les tests de performance comme un 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, aboutissant à une suite de tests qui est maintenable et qui peut elle-même être testée.
Le Benchmarking Continu vs Tests de Charge Continus
Afin de comprendre la différence entre le Benchmarking Continu et les Tests de Charge Continus, vous devez comprendre la différence entre le benchmarking et les tests de charge.
| Type de Test | Portée du Test | Utilisateurs du Test |
|---|---|---|
| Benchmarking | Fonction - Service | Un - Plusieurs |
| Test de Charge | Service | Plusieurs |
Le benchmarking peut tester la performance d’un logiciel, 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. Les tests de charge ne testent la performance des logiciels qu’au niveau du service et simulent plusieurs utilisateurs simultanés. 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). Les tests de charge pourraient être utilisés pour voir comment le camion de glace sert 100 clients par une chaude journée d’été.