Wie man Benchmarks in CI mit Bencher verfolgt


Die meisten Benchmark-Ergebnisse sind verg├Ąnglich. Sie verschwinden, sobald Ihr Terminal das Scrollback-Limit erreicht. Einige Benchmark-Harnesses erm├Âglichen es Ihnen, Ergebnisse zu speichern, aber die meisten tun dies nur lokal. Bencher erm├Âglicht es Ihnen, Ihre Benchmarks sowohl von lokalen als auch von CI-Durchl├Ąufen zu verfolgen und die Ergebnisse zu vergleichen, w├Ąhrend Sie weiterhin Ihren bevorzugten Benchmark-Harness verwenden.

Es gibt zwei beliebte Methoden, um Benchmark-Ergebnisse beim Continuous Benchmarking, d.h. Benchmarking in CI, zu vergleichen:

  • Statistisches Continuous Benchmarking
    1. Verfolgen Sie Benchmark-Ergebnisse ├╝ber die Zeit, um eine Basislinie zu erstellen.
    2. Verwenden Sie diese Basislinie zusammen mit Statistischen Schwellenwerten, um eine statistische Grenze zu erstellen.
    3. Vergleichen Sie die neuen Ergebnisse mit dieser statistischen Grenze, um Leistungsregressionen zu erkennen.
  • Relatives Continuous Benchmarking
    1. F├╝hren Sie die Benchmarks f├╝r den aktuellen Basiscode aus.
    2. Verwenden Sie Prozentuale Schwellenwerte, um eine Grenze f├╝r den Basiscode zu erstellen.
    3. Wechseln Sie zur neuen Version des Codes.
    4. F├╝hren Sie die Benchmarks f├╝r die neue Version des Codes aus.
    5. Vergleichen Sie die Ergebnisse der neuen Version des Codes mit den Ergebnissen des Basiscode, um Leistungsregressionen zu erkennen.

Statistisches kontinuierliches Benchmarking

Ankn├╝pfend an die Schnellstart- und Docker Self-Hosted-Tutorials, lassen Sie uns statistisches kontinuierliches Benchmarking zu unserem Save Walter White-Projekt hinzuf├╝gen.

­čÉ░ Stellen Sie sicher, dass Sie ein API-Token erstellt und als BENCHER_API_TOKEN-Umgebungsvariable gesetzt haben, bevor Sie fortfahren!

Zuerst m├╝ssen wir ein neues Testbed erstellen, um unsere CI-Runner zu repr├Ąsentieren, passenderweise ci-runner genannt.

bencher testbed create \
--name ci-runner \
save-walter-white-1234abcd
  1. Verwenden Sie das bencher testbed create CLI-Unterkommando. Siehe die testbed create-Dokumentation f├╝r weitere Details. (Bsp.: bencher testbed create)
  2. Setzen Sie die --name-Option auf den gew├╝nschten Testbed-Namen. (Bsp.: --name ci-runner)
  3. Geben Sie das Projektargument als den Save Walter White Projekt-Slug an. (Bsp.: save-walter-white-1234abcd)

Als N├Ąchstes m├╝ssen wir einen neuen Schwellenwert f├╝r unser ci-runner Testbed erstellen:

bencher threshold create \
--branch main \
--testbed ci-runner \
--measure Latency \
--test t-test \
--upper-boundary 0.95 \
save-walter-white-1234abcd
  1. Verwenden Sie das bencher threshold create CLI-Unterkommando. Siehe die threshold create-Dokumentation f├╝r weitere Details. (Bsp.: bencher threshold create)
  2. Setzen Sie die --branch-Option auf den Standard main Branch. (Bsp.: --branch main)
  3. Setzen Sie die --branch-Option auf das neue ci-runner Testbed. (Bsp.: --testbed ci-runner)
  4. Setzen Sie die --measure-Option auf das integrierte Latency-Ma├č, das durch bencher mock generiert wird. Siehe die Definition von Ma├č f├╝r Details. (Bsp.: --measure Latency)
  5. Setzen Sie die --test-Option auf einen t-test Schwellenwert. Siehe Schwellenwerte & Alarme f├╝r einen vollst├Ąndigen ├ťberblick. (Bsp.: --test t-test)
  6. Setzen Sie die --upper-boundary-Option auf eine obere Grenze von 0.95. Siehe Schwellenwerte & Alarme f├╝r einen vollst├Ąndigen ├ťberblick. (Bsp.: --upper-boundary 0.95)
  7. Geben Sie das Projektargument als den Save Walter White Projekt-Slug an. (Bsp.: save-walter-white-1234abcd)

Nun sind wir bereit, unsere Benchmarks in CI auszuf├╝hren. Da jede CI-Umgebung ein wenig anders ist, ist das folgende Beispiel eher illustrativ als praktisch gemeint. F├╝r spezifischere Beispiele siehe Kontinuierliches Benchmarking in GitHub Actions und Kontinuierliches Benchmarking in GitLab CI/CD.

Wir müssen eine historische Basislinie für unseren main Branch erstellen, indem wir jede Änderung in CI benchmarken:

bencher run \
--project save-walter-white-1234abcd \
--branch main \
--testbed ci-runner \
--adapter json \
--err \
bencher mock
  1. Verwenden Sie das bencher run CLI-Unterkommando um Ihre Benchmarks des feature-branch Branches auszuf├╝hren. Siehe das bencher run CLI-Unterkommando f├╝r einen vollst├Ąndigen ├ťberblick. (Bsp.: bencher run)
  2. Setzen Sie die --project-Option auf den Projekt-Slug. Siehe die --project-Dokumentation f├╝r weitere Details. (Bsp.: --project save-walter-white-1234abcd)
  3. Setzen Sie die --branch-Option auf den Standardbranch-Namen. Siehe Branch-Auswahl f├╝r einen vollst├Ąndigen ├ťberblick. (Bsp.: --branch main)
  4. Setzen Sie die --testbed-Option auf den Testbed-Namen. Siehe die --tested-Dokumentation f├╝r weitere Details. (Bsp.: --testbed ci-runner)
  5. Setzen Sie die --adapter-Option auf den gew├╝nschten Benchmark-Harness-Adapter. Siehe Benchmark-Harness-Adapter f├╝r einen vollst├Ąndigen ├ťberblick. (Bsp.: --adapter json)
  6. Setzen Sie das --err-Flag, um den Befehl fehlschlagen zu lassen, wenn ein Alarm ausgel├Âst wird. Siehe Schwellenwerte & Alarme f├╝r einen vollst├Ąndigen ├ťberblick. (Bsp.: --err)
  7. Geben Sie die Benchmark-Kommandoargumente an. Siehe Benchmark-Kommando f├╝r einen vollst├Ąndigen ├ťberblick. (Bsp.: bencher mock)

Schlie├člich sind wir bereit, Leistungsregressionen in CI zu erkennen. So w├╝rden wir die Leistung eines neuen Feature-Branches, benannt feature-branch, in CI verfolgen:

bencher run \
--project save-walter-white-1234abcd \
--branch feature-branch \
--branch-start-point main \
--branch-start-point-hash 32aea434d751648726097ed3ac760b57107edd8b \
--testbed ci-runner \
--adapter json \
--err \
bencher mock
  1. Verwenden Sie das bencher run CLI-Unterkommando um Ihre Benchmarks des feature-branch Branches auszuf├╝hren. Siehe das bencher run CLI-Unterkommando f├╝r einen vollst├Ąndigen ├ťberblick. (Bsp.: bencher run)
  2. Setzen Sie die --project-Option auf den Projekt-Slug. Siehe die --project-Dokumentation f├╝r weitere Details. (Bsp.: --project save-walter-white-1234abcd)
  3. Setzen Sie die --branch-Option auf den Namen des Feature-Branches. Siehe Branch-Auswahl f├╝r einen vollst├Ąndigen ├ťberblick. (Bsp.: --branch feature-branch)
  4. Setzen Sie die --branch-start-point-Option auf den Startpunkt des Feature-Branches. Siehe Branch-Auswahl f├╝r einen vollst├Ąndigen ├ťberblick. (Bsp.: --branch-start-point main)
  5. Setzen Sie die --branch-start-point-hash-Option auf den git-Hash des Startpunkts des Feature-Branches. Siehe Branch-Auswahl f├╝r einen vollst├Ąndigen ├ťberblick. (Bsp.: --branch-start-point-hash 32ae...dd8b)
  6. Setzen Sie die --testbed-Option auf den Testbed-Namen. Siehe die --tested-Dokumentation f├╝r weitere Details. (Bsp.: --testbed ci-runner)
  7. Setzen Sie die --adapter-Option auf den gew├╝nschten Benchmark-Harness-Adapter. Siehe Benchmark-Harness-Adapter f├╝r einen vollst├Ąndigen ├ťberblick. (Bsp.: --adapter json)
  8. Setzen Sie das --err-Flag, um den Befehl fehlschlagen zu lassen, wenn ein Alarm ausgel├Âst wird. Siehe Schwellenwerte & Alarme f├╝r einen vollst├Ąndigen ├ťberblick. (Bsp.: --err)
  9. Geben Sie die Benchmark-Kommandoargumente an. Siehe Benchmark-Kommando f├╝r einen vollst├Ąndigen ├ťberblick. (Bsp.: bencher mock)

Das erste Mal, wenn dieser Befehl in CI ausgef├╝hrt wird, wird der feature-branch Branch erstellt, da er noch nicht existiert. Der neue feature-branch wird den main Branch am Hash 32aea434d751648726097ed3ac760b57107edd8b als seinen Ausgangspunkt verwenden. Das bedeutet, dass feature-branch eine Kopie aller Daten und Schwellenwerte vom main Branch haben wird, um die Ergebnisse von bencher mock dagegen zu vergleichen, f├╝r den ersten und alle nachfolgenden L├Ąufe.

Relatives kontinuierliches Benchmarking

Ankn├╝pfend an die Tutorials Schnellstart und Docker Self-Hosted f├╝gen wir unserem Save Walter White-Projekt relatives kontinuierliches Benchmarking hinzu.

­čÉ░ Stellen Sie sicher, dass Sie einen API-Token erstellt haben und diesen als BENCHER_API_TOKEN Umgebungsvariable gesetzt haben, bevor Sie fortfahren!

Zuerst m├╝ssen wir eine neue Testumgebung erstellen, um unsere CI-Runner darzustellen, treffend benannt ci-runner.

bencher testbed create \
--name ci-runner \
save-walter-white-1234abcd
  1. Verwenden Sie das bencher testbed create CLI-Unterkommando. Siehe die testbed create Dokumentation f├╝r mehr Details. (Bsp.: bencher testbed create)
  2. Setzen Sie die --name Option auf den gew├╝nschten Testumgebungs-Namen. (Bsp.: --name ci-runner)
  3. Geben Sie das Projektargument als Save Walter White-Projekt-Slug an. (Bsp.: save-walter-white-1234abcd)

Relatives kontinuierliches Benchmarking f├╝hrt einen Seite-an-Seite Vergleich zweier Versionen Ihres Codes durch. Dies kann n├╝tzlich sein, wenn man es mit lauten CI/CD-Umgebungen zu tun hat, wo die verf├╝gbaren Ressourcen zwischen den L├Ąufen stark variieren k├Ânnen. In diesem Beispiel vergleichen wir die Ergebnisse vom Laufen auf dem main-Branch mit Ergebnissen vom Laufen auf einem Feature-Branch namens feature-branch. Da jede CI-Umgebung ein wenig anders ist, ist das folgende Beispiel eher illustrativ als praktisch gedacht. F├╝r spezifischere Beispiele siehe Kontinuierliches Benchmarking in GitHub Actions und Kontinuierliches Benchmarking in GitLab CI/CD.

Zuerst m├╝ssen wir den main-Branch mit git in CI auschecken:

git checkout main

Dann m├╝ssen wir unsere Benchmarks auf dem main-Branch in CI ausf├╝hren:

bencher run \
--project save-walter-white-1234abcd \
--branch feature-branch \
--branch-reset \
--testbed ci-runner \
--adapter json \
bencher mock
  1. Verwenden Sie das bencher run CLI-Unterkommando um Ihre Benchmarks des main-Branches auszuf├╝hren. Siehe das bencher run CLI-Unterkommando f├╝r einen vollst├Ąndigen ├ťberblick. (Bsp.: bencher run)
  2. Setzen Sie die --project Option auf den Projekt-Slug. Siehe die --project Dokumentation f├╝r mehr Details. (Bsp.: --project save-walter-white-1234abcd)
  3. Setzen Sie die --branch Option auf den Namen des Feature-Branches. Siehe Branch-Auswahl f├╝r einen vollst├Ąndigen ├ťberblick. (Bsp.: --branch feature-branch)
  4. Setzen Sie das --branch-reset Flag. Siehe Branch-Auswahl f├╝r einen vollst├Ąndigen ├ťberblick. (Bsp.: --branch-reset)
  5. Setzen Sie die --testbed Option auf den Namen der Testumgebung. Siehe die --tested Dokumentation f├╝r mehr Details. (Bsp.: --testbed ci-runner)
  6. Setzen Sie die --adapter Option auf den gew├╝nschten Benchmark-Harness-Adapter. Siehe Benchmark-Harness-Adapter f├╝r einen vollst├Ąndigen ├ťberblick. (Bsp.: --adapter json)
  7. Geben Sie die Benchmark-Befehlsargumente an. Siehe Benchmark-Befehl f├╝r einen vollst├Ąndigen ├ťberblick. (Bsp.: bencher mock)

Das erste Mal, wenn dieser Befehl in CI ausgef├╝hrt wird, wird der feature-branch Branch erstellt, da er noch nicht existiert. Der neue feature-branch wird keinen Startpunkt, vorhandene Daten oder Schwellenwerte haben. Bei sp├Ąteren L├Ąufen wird die alte Version des feature-branch umbenannt und ein neuer feature-branch wird erstellt ohne Startpunkt, vorhandene Daten oder Schwellenwerte.

Als N├Ąchstes m├╝ssen wir einen neuen Schwellenwert in CI f├╝r unseren neuen feature-branch Branch erstellen:

bencher threshold create \
--branch feature-branch \
--testbed ci-runner \
--measure Latency \
--test percentage \
--upper-boundary 0.25 \
save-walter-white-1234abcd
  1. Verwenden Sie das bencher threshold create CLI-Unterkommando. Siehe die threshold create Dokumentation f├╝r mehr Details. (Bsp.: bencher threshold create)
  2. Setzen Sie die --branch Option auf den neuen feature-branch Branch. (Bsp.: --branch feature-branch)
  3. Setzen Sie die --branch Option auf die ci-runner Testumgebung. (Bsp.: --testbed ci-runner)
  4. Setzen Sie die --measure Option auf das integrierte Latency Ma├č, das von bencher mock generiert wird. Siehe die Definition von Ma├č f├╝r Details. (Bsp.: --measure Latency)
  5. Setzen Sie die --test Option auf einen Prozentsatz-Schwellenwert. Siehe Schwellenwerte & Alarme f├╝r einen vollst├Ąndigen ├ťberblick. (Bsp.: --test t-test)
  6. Setzen Sie die --upper-boundary Option auf eine obere Grenze von 0.25 (d. h. 25%). Siehe Schwellenwerte & Alarme f├╝r einen vollst├Ąndigen ├ťberblick. (Bsp.: --upper-boundary 0.25)
  7. Geben Sie das Projektargument als den Save Walter White-Projekt-Slug an. (Bsp.: save-walter-white-1234abcd)

Dann m├╝ssen wir den feature-branch Branch mit git in CI auschecken:

git checkout feature-branch

Schlie├člich sind wir bereit, unsere Benchmarks des feature-branch in CI auszuf├╝hren:

bencher run \
--project save-walter-white-1234abcd \
--branch feature-branch \
--testbed ci-runner \
--adapter json \
--err \
bencher mock
  1. Verwenden Sie das bencher run CLI-Unterkommando um Ihre Benchmarks des feature-branch auszuf├╝hren. Siehe das bencher run CLI-Unterkommando f├╝r einen vollst├Ąndigen ├ťberblick. (Bsp.: bencher run)
  2. Setzen Sie die --project Option auf den Projekt-Slug. Siehe die --project Dokumentation f├╝r mehr Details. (Bsp.: --project save-walter-white-1234abcd)
  3. Setzen Sie die --branch Option auf den Namen des Feature-Branches. Siehe Branch-Auswahl f├╝r einen vollst├Ąndigen ├ťberblick. (Bsp.: --branch feature-branch)
  4. Setzen Sie die --testbed Option auf den Namen der Testumgebung. Siehe die --tested Dokumentation f├╝r mehr Details. (Bsp.: --testbed ci-runner)
  5. Setzen Sie die --adapter Option auf den gew├╝nschten Benchmark-Harness-Adapter. Siehe Benchmark-Harness-Adapter f├╝r einen vollst├Ąndigen ├ťberblick. (Bsp.: --adapter json)
  6. Setzen Sie das --err Flag, um den Befehl fehlschlagen zu lassen, wenn ein Alarm ausgel├Âst wird. Siehe Schwellenwerte & Alarme f├╝r einen vollst├Ąndigen ├ťberblick. (Bsp.: --err)
  7. Geben Sie die Benchmark-Befehlsargumente an. Siehe Benchmark-Befehl f├╝r einen vollst├Ąndigen ├ťberblick. (Bsp.: bencher mock)

Jedes Mal, wenn dieser Befehl in CI ausgef├╝hrt wird, wird das Ergebnis des feature-branch nur mit den neuesten Ergebnissen des main verglichen.



­čÉ░ Gl├╝ckwunsch! Sie haben gelernt, wie man Benchmarks in CI mit Bencher verfolgt! ­čÄë


Bencher zu GitHub Actions hinzuf├╝gen Ô×í

Bencher zu GitLab CI/CD hinzuf├╝gen Ô×í

­čĄľ Dieses Dokument wurde automatisch von OpenAI GPT-4 generiert. Es ist m├Âglicherweise nicht korrekt und kann Fehler enthalten. Wenn Sie Fehler finden, ├Âffnen Sie bitte ein Problem auf GitHub.


Published: Fri, October 27, 2023 at 8:40:00 AM UTC | Last Updated: Mon, April 1, 2024 at 7:00:00 AM UTC