Comment Suivre les Benchmarks dans l'Intégration Continue avec Bencher

La plupart des résultats de benchmarks sont éphémères. Ils disparaissent dès que votre terminal atteint sa limite de défilement. Certains outils de benchmark permettent de mettre en cache les résultats, mais la plupart ne le font que localement. Bencher vous permet de suivre vos benchmarks à la fois locaux et depuis les CI et de comparer les résultats, tout en utilisant votre outil de benchmark favori.

Il existe deux manières populaires de comparer les résultats de benchmarks lors du Benchmarking Continu, c’est-à-dire le benchmarking en CI :

• Benchmarking Continu Statistique
  1. Suivre les résultats des benchmarks dans le temps pour créer une base de référence
  2. Utiliser cette base de référence avec des Seuils Statistiques pour créer une limite statistique
  3. Comparer les nouveaux résultats à cette limite statistique pour détecter les régressions de performances
• Benchmarking Continu Relatif
  1. Exécuter les benchmarks pour le code de base actuel
  2. Utiliser des Seuils en Pourcentage pour créer une limite pour le code de base
  3. Passer à la nouvelle version du code
  4. Exécuter les benchmarks pour la nouvelle version du code
  5. Comparer les résultats de la nouvelle version du code à ceux du code de base pour détecter les régressions de performances

Benchmarking Continu en Mode Statistique

Continuons là où nous nous étions arrêtés dans les tutoriels Quick Start et Docker Self-Hosted, ajoutons le Benchmarking Continu en Mode Statistique Continuous Benchmarking à notre projet Save Walter White.

🐰 Assurez-vous d’avoir créé un jeton API et de l’avoir défini comme variable d’environnement BENCHER_API_TOKEN avant de continuer !

Tout d’abord, nous devons créer un nouveau Testbed pour représenter nos runners CI, nommé à juste titre ci-runner.

bencher testbed create \
--name ci-runner \
save-walter-white-1234abcd

1. Utilisez la sous-commande CLI bencher testbed create. Voir la documentation de testbed create pour plus de détails. (ex: bencher testbed create)
2. Définissez l’option --name sur le nom de Testbed souhaité. (ex: --name ci-runner)
3. Spécifiez l’argument du projet comme le slug du projet Save Walter White. (ex: save-walter-white-1234abcd)

Ensuite, nous devons créer un nouveau Threshold pour notre Testbed ci-runner :

bencher threshold create \
--branch main \
--testbed ci-runner \
--measure Latency \
--test t-test \
--upper-boundary 0.95 \
save-walter-white-1234abcd

1. Utilisez la sous-commande CLI bencher threshold create. Voir la documentation de threshold create pour plus de détails. (ex: bencher threshold create)
2. Définissez l’option --branch sur la branche par défaut main. (ex: --branch main)
3. Définissez l’option --testbed sur le nouveau Testbed ci-runner. (ex: --testbed ci-runner)
4. Définissez l’option --measure sur la mesure intégrée Latency générée par bencher mock. Voir la définition de la Mesure pour plus de détails. (ex: --measure Latency)
5. Définissez l’option --test sur un seuil de t-test. Voir les Seuils & Alertes pour une vue d’ensemble complète. (ex: --test t-test)
6. Définissez l’option --upper-boundary sur une limite supérieure de 0.95. Voir les Seuils & Alertes pour une vue d’ensemble complète. (ex: --upper-boundary 0.95)
7. Spécifiez l’argument du projet comme le slug du projet Save Walter White. (ex: save-walter-white-1234abcd)

Nous sommes maintenant prêts à exécuter nos benchmarks en CI. Puisque chaque environnement CI est un peu différent, l’exemple suivant est censé être plus illustratif que pratique. Pour des exemples plus spécifiques, consultez Benchmarking Continu avec GitHub Actions et Benchmarking Continu avec GitLab CI/CD.

Nous devons créer et maintenir un point de référence historique pour notre branche main en benchmarkant chaque changement en CI :

bencher run \
--project save-walter-white-1234abcd \
--branch main \
--testbed ci-runner \
--adapter json \
--err \
bencher mock

1. Utilisez la sous-commande CLI bencher run pour exécuter les benchmarks de votre branche feature-branch. Voir la sous-commande CLI bencher run pour une vue d’ensemble complète. (ex: bencher run)
2. Définissez l’option --project sur le slug du projet. Voir la documentation de --project pour plus de détails. (ex: --project save-walter-white-1234abcd)
3. Définissez l’option --branch sur le nom de la branche par défaut. Voir la sélection de la branche pour une vue d’ensemble complète. (ex: --branch main)
4. Définissez l’option --testbed sur le nom du Testbed. Voir la documentation de --tested pour plus de détails. (ex: --testbed ci-runner)
5. Définissez l’option --adapter sur l’adaptateur de banc d’essai souhaité. Voir les adaptateurs de banc d’essai pour une vue d’ensemble complète. (ex: --adapter json)
6. Définissez le drapeau --err pour échouer à la commande si une alerte est générée. Voir les Seuils & Alertes pour une vue d’ensemble complète. (ex: --err)
7. Spécifiez les arguments de la commande de benchmark. Voir la commande de benchmark pour une vue d’ensemble complète. (ex: bencher mock)

Enfin, nous sommes prêts à détecter les régressions de performance en CI. Voici comment nous suivrions la performance d’une nouvelle branche de fonctionnalités, nommée feature-branch, en CI :

bencher run \
--project save-walter-white-1234abcd \
--branch feature-branch \
--branch-start-point main \
--branch-start-point-hash 32aea434d751648726097ed3ac760b57107edd8b \
--branch-reset \
--testbed ci-runner \
--adapter json \
--err \
bencher mock

1. Utilisez la sous-commande CLI bencher run pour exécuter les benchmarks de votre branche feature-branch. Voir la sous-commande CLI bencher run pour une vue d’ensemble complète. (ex: bencher run)
2. Définissez l’option --project sur le slug du projet. Voir la documentation de --project pour plus de détails. (ex: --project save-walter-white-1234abcd)
3. Définissez l’option --branch sur le nom de la branche de fonctionnalité. Voir la sélection de la branche pour une vue d’ensemble complète. (ex: --branch feature-branch)
4. Définissez l’option --branch-start-point sur le point de départ de la branche de fonctionnalité. Voir la sélection de la branche pour une vue d’ensemble complète. (ex: --branch-start-point main)
5. Définissez l’option --branch-start-point-hash sur le hash git du point de départ de la branche de fonctionnalité. Voir la sélection de la branche pour une vue d’ensemble complète. (ex: --branch-start-point-hash 32ae...dd8b)
6. Définissez le drapeau --branch-reset pour toujours réinitialiser la branche au point de départ. Cela empêchera la dérive des données de benchmark. Voir la sélection de la branche pour une vue d’ensemble complète. (ex: --branch-reset)
7. Définissez l’option --testbed sur le nom du Testbed. Voir la documentation de --tested pour plus de détails. (ex: --testbed ci-runner)
8. Définissez l’option --adapter sur l’adaptateur de banc d’essai souhaité. Voir les adaptateurs de banc d’essai pour une vue d’ensemble complète. (ex: --adapter json)
9. Définissez le drapeau --err pour échouer à la commande si une alerte est générée. Voir les Seuils & Alertes pour une vue d’ensemble complète. (ex: --err)
10. Spécifiez les arguments de la commande de benchmark. Voir la commande de benchmark pour une vue d’ensemble complète. (ex: bencher mock)

La première fois que cette commande est exécutée en CI, elle créera la branche feature-branch car elle n’existe pas encore. La nouvelle branche feature-branch utilisera la branche main au hash 32aea434d751648726097ed3ac760b57107edd8b comme point de départ. Cela signifie que feature-branch aura une copie de toutes les données et Seuils de la branche main pour comparer les résultats de bencher mock contre, pour la première et toutes les exécutions suivantes.

Benchmarking Continu Relatif

Poursuivant là où nous nous étions arrêtés dans les tutoriels Démarrage Rapide et Auto-hébergement Docker, ajoutons le Benchmarking Continu Relatif à notre projet Save Walter White.

🐰 Assurez-vous d’avoir créé un jeton API et de l’avoir configuré comme la variable d’environnement BENCHER_API_TOKEN avant de continuer !

Tout d’abord, nous devons créer un nouveau Testbed pour représenter nos exécutants CI, judicieusement nommé ci-runner.

bencher testbed create \
--name ci-runner \
save-walter-white-1234abcd

1. Utilisez la sous-commande CLI bencher testbed create. Consultez la doc testbed create pour plus de détails. (ex: bencher testbed create)
2. Définissez l’option --name au nom de Testbed souhaité. (ex: --name ci-runner)
3. Spécifiez l’argument projet comme le slug du projet Save Walter White. (ex: save-walter-white-1234abcd)

Le Benchmarking Continu Relatif exécute une comparaison côte à côte de deux versions de votre code. Cela peut être utile lorsqu’on traite avec des environnements CI/CD bruyants, où les ressources disponibles peuvent être très variables entre les exécutions. Dans cet exemple, nous comparerons les résultats de l’exécution sur la branche main aux résultats de l’exécution sur une branche de fonctionnalité nommée feature-branch. Comme chaque environnement CI est un peu différent, l’exemple suivant est plus illustratif que pratique. Pour des exemples plus spécifiques, voir Benchmarking Continu dans GitHub Actions et Benchmarking Continu dans GitLab CI/CD.

Tout d’abord, nous devons passer à la branche main avec git dans CI:

git checkout main

Puis nous devons exécuter nos benchmarks sur la branche main dans CI:

bencher run \
--project save-walter-white-1234abcd \
--branch feature-branch \
--branch-reset \
--testbed ci-runner \
--adapter json \
bencher mock

1. Utilisez la sous-commande CLI bencher run pour exécuter vos benchmarks de la branche main. Consultez la sous-commande CLI bencher run pour un aperçu complet. (ex: bencher run)
2. Définissez l’option --project au slug du projet. Consultez la doc --project pour plus de détails. (ex: --project save-walter-white-1234abcd)
3. Définissez l’option --branch au nom de la branche de fonctionnalité. Consultez la sélection de branche pour un aperçu complet. (ex: --branch feature-branch)
4. Définissez le drapeau --branch-reset. Consultez la sélection de branche pour un aperçu complet. (ex: --branch-reset)
5. Définissez l’option --testbed au nom du Testbed. Consultez la doc --tested pour plus de détails. (ex: --testbed ci-runner)
6. Définissez l’option --adapter à l’adaptateur de harnais de benchmark souhaité. Consultez les adaptateurs de harnais de benchmark pour un aperçu complet. (ex: --adapter json)
7. Spécifiez les arguments de la commande de benchmark. Consultez la commande de benchmark pour un aperçu complet. (ex: bencher mock)

La première fois que cette commande est exécutée dans CI, elle créera la branche feature-branch puisqu’elle n’existe pas encore. La nouvelle feature-branch n’aura pas de point de départ, de données existantes, ou de Seuils. Lors des exécutions ultérieures, l’ancienne version de feature-branch sera renommée et une nouvelle feature-branch sera créée sans point de départ, de données existantes, ou de Seuils.

Ensuite, nous devons créer un nouveau Seuil dans CI pour notre nouvelle branche feature-branch:

bencher threshold create \
--branch feature-branch \
--testbed ci-runner \
--measure Latency \
--test percentage \
--upper-boundary 0.25 \
save-walter-white-1234abcd

1. Utilisez la sous-commande CLI bencher threshold create. Consultez la doc threshold create pour plus de détails. (ex: bencher threshold create)
2. Définissez l’option --branch à la nouvelle branche feature-branch. (ex: --branch feature-branch)
3. Définissez l’option --testbed au Testbed ci-runner. (ex: --testbed ci-runner)
4. Définissez l’option --measure à la mesure Latency intégrée qui est générée par bencher mock. Consultez la définition de Measure pour les détails. (ex: --measure Latency)
5. Définissez l’option --test à un seuil de percentage. Consultez Seuils & Alertes pour un aperçu complet. (ex: --test t-test)
6. Définissez l’option --upper-boundary à une Limite Supérieure de 0.25 (soit 25%). Consultez Seuils & Alertes pour un aperçu complet. (ex: --upper-boundary 0.25)
7. Spécifiez l’argument projet comme le slug du projet Save Walter White. (ex: save-walter-white-1234abcd)

Ensuite, nous devons passer à la branche feature-branch avec git dans CI:

git checkout feature-branch

Enfin, nous sommes prêts à exécuter nos benchmarks feature-branch dans CI:

bencher run \
--project save-walter-white-1234abcd \
--branch feature-branch \
--testbed ci-runner \
--adapter json \
--err \
bencher mock

1. Utilisez la sous-commande CLI bencher run pour exécuter vos benchmarks de la branche feature-branch. Consultez la sous-commande CLI bencher run pour un aperçu complet. (ex: bencher run)
2. Définissez l’option --project au slug du projet. Consultez la doc --project pour plus de détails. (ex: --project save-walter-white-1234abcd)
3. Définissez l’option --branch au nom de la branche de fonctionnalité. Consultez la sélection de branche pour un aperçu complet. (ex: --branch feature-branch)
4. Définissez l’option --testbed au nom du Testbed. Consultez la doc --tested pour plus de détails. (ex: --testbed ci-runner)
5. Définissez l’option --adapter à l’adaptateur de harnais de benchmark souhaité. Consultez les adaptateurs de harnais de benchmark pour un aperçu complet. (ex: --adapter json)
6. Définissez le drapeau --err pour échouer la commande si une Alerte est générée. Consultez Seuils & Alertes pour un aperçu complet. (ex: --err)
7. Spécifiez les arguments de la commande de benchmark. Consultez la commande de benchmark pour un aperçu complet. (ex: bencher mock)

Chaque fois que cette commande est exécutée dans CI, elle compare les résultats de feature-branch uniquement aux résultats les plus récents de main.

🐰 Félicitations ! Vous avez appris comment suivre les benchmarks dans l’Intégration Continue avec Bencher ! 🎉

Ajouter Bencher à GitHub Actions ➡

Ajouter Bencher à GitLab CI/CD ➡