Comment utiliser Bencher pour suivre les Benchmarks


La façon la plus simple de suivre vos benchmarks est la sous-commande CLI bencher run. Consultez l’aperçu du benchmarking pour une explication plus approfondie. Voici un exemple d’une sous-commande CLI bencher run pour suivre les benchmarks sur une branche de fonctionnalitĂ© judicieusement nommĂ©e branche-fonctionnalitĂ© :

bencher run \
--project sauver-walter-white \
--token eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJhdWQiOiJjbGllbnQiLCJleHAiOjE2NzQwNjA3NTAsImlhdCI6MTY3MTQ2ODc1MCwiaXNzIjoiYmVuY2hlci5kZXYiLCJzdWIiOiJzYXVsQGJldHRlcmNhbGxzYXVsLmNvbSIsIm9yZyI6bnVsbH0.CABcvWlPobAHs7wsdR6wX5p0R2jaCd7RmpsnMp5pwEc \
--adapter json \
--if-branch branche-fonctionnalité \
--else-if-branch main \
--else-branch \
--testbed phoenix \
--err \
"bencher mock"`
  1. Le projet doit dĂ©jĂ  exister. DĂ©finissez le drapeau --project ou la variable d’environnement BENCHER_PROJECT sur le slug du projet ou l’UUID. (ex: --project sauver-walter-white)
  2. Le token API doit dĂ©jĂ  exister. DĂ©finissez le drapeau --token ou la variable d’environnement BENCHER_API_TOKEN sur le token API. (ex: --token ...)
  3. Optionnel : DĂ©finissez le drapeau --adapter ou la variable d’environnement BENCHER_ADAPTER sur le nom de l’adaptateur dĂ©sirĂ©. Si cela n’est pas dĂ©fini, alors l’adaptateur magic sera utilisĂ©. Consultez les adaptateurs de harnais de benchmark pour un aperçu complet. (ex: --adapter json)
  4. Il y a plusieurs options pour définir la branche du projet. Consultez la sélection de branche pour un aperçu complet.
    1. Utilisez la branche actuelle si elle existe déjà. (ex: --if-branch branche-fonctionnalité)
    2. Créez un clone des données de la branche cible si elle existe déjà. (ex: --else-if-branch main)
    3. Sinon, créez une nouvelle branche avec le nom fourni à --if-branch, qui serait branche-fonctionnalité. (ex: --else-branch)
  5. Optionnel : DĂ©finissez le drapeau --testbed ou la variable d’environnement BENCHER_TESTBED sur le slug du Testbed ou l’UUID. Le Testbed doit dĂ©jĂ  exister. Si cela n’est pas dĂ©fini, alors le Testbed par dĂ©faut localhost sera utilisĂ©. (ex: --testbed phoenix)
  6. DĂ©finissez la commande pour Ă©chouer si une alerte est gĂ©nĂ©rĂ©e. Pour qu’une alerte soit gĂ©nĂ©rĂ©e, un Seuil doit dĂ©jĂ  exister. (ex: --err)
  7. Exécutez vos benchmarks et générez un Rapport à partir des résultats. (ex: "bencher mock")

Benchmarking Relatif

Le benchmarking relatif effectue une comparaison cĂŽte Ă  cĂŽte de deux commits. Cela peut ĂȘtre utile lorsqu’on traite des environnements CI/CD bruyants, oĂč la ressource disponible peut ĂȘtre trĂšs variable entre les exĂ©cutions. Voici un exemple d’une sous-commande CLI bencher run pour effectuer un benchmarking relatif sur une branche de fonctionnalitĂ© judicieusement nommĂ©e branche-fonctionnalitĂ© :

git checkout branche-fonctionnalité

export BRANCHE_FONCTIONNALITÉ=branche-fonctionnalitĂ©-$(git rev-parse --short HEAD)

git checkout main

bencher run \
--if-branch "$BRANCHE_FONCTIONNALITÉ" \
--else-branch \
--iter 3 \
"bencher mock"

git checkout branche-fonctionnalité

bencher threshold create \
--metric-kind latency \
--branch "$BRANCHE_FONCTIONNALITÉ" \
--testbed localhost \
--test t \
--right-side 0.95

bencher run \
--if-branch "$BRANCHE_FONCTIONNALITÉ" \
--iter 3 \
--fold min \
--err \
"bencher mock"
  1. Passez à la branche de fonctionnalité. (ex: branche-fonctionnalité)
  2. CrĂ©ez une variable d’environnement qui est le nom de la branche de fonctionnalitĂ© concatĂ©nĂ© avec l’ID de commit git court. C’est important ! Cela garantit qu’une nouvelle branche est crĂ©Ă©e Ă  chaque exĂ©cution.
  3. Passez Ă  la branche cible. (ex: main)
  4. Exécutez bencher run pour la branche cible :
    1. La branche donnĂ©e n’existera pas encore. (ex: --if-branch "$BRANCHE_FONCTIONNALITÉ")
    2. Alors elle sera créée. (ex: --else-branch)
    3. Exécutez les benchmarks trois fois. (ex: --iter 3)
  5. Passez à la branche de fonctionnalité. (ex: branche-fonctionnalité)
  6. Créez un Seuil pour la branche de fonctionnalité :
    1. Le type de métrique pour les benchmarks est la Latence. (ex: --metric-kind latency)
    2. La branche est la branche de fonctionnalitĂ© avec l’ID de commit git ajoutĂ©. (ex: --branch "$BRANCHE_FONCTIONNALITÉ")
    3. Le Testbed est en cours d’exĂ©cution localement. (ex: --testbed localhost)
    4. Il y a moins de 30 métriques, utilisez un test t de Student. (ex: --test t)
    5. Définissez une limite supérieure de 95.0% car une latence plus grande indique une régression de performance. (ex: --right-side 0.95)
  7. Exécutez bencher run pour la branche de fonctionnalité :
    1. La branche existera puisqu’elle vient d’ĂȘtre crĂ©Ă©e. (ex: --if-branch "$BRANCHE_FONCTIONNALITÉ")
    2. Exécutez les tests trois fois. (ex: --iter 3)
    3. Pliez les trois MĂ©triques en la valeur minimale. (ex: --fold min)
    4. Définissez la commande pour échouer si une alerte est générée par le Seuil. (ex: --err)


🐰 FĂ©licitations ! Vous avez appris comment utiliser Bencher pour suivre les benchmarks ! 🎉


Ajouter Bencher à GitHub Actions ➡

Ajouter Bencher à GitLab CI/CD ➡

đŸ€– Ce document a Ă©tĂ© automatiquement gĂ©nĂ©rĂ© par OpenAI GPT-4. Il peut ne pas ĂȘtre prĂ©cis et peut contenir des erreurs. Si vous trouvez des erreurs, veuillez ouvrir une issue sur GitHub.