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
- Verfolgen Sie Benchmark-Ergebnisse über die Zeit, um eine Basislinie zu erstellen.
- Verwenden Sie diese Basislinie zusammen mit Statistischen Schwellenwerten, um eine statistische Grenze zu erstellen.
- Vergleichen Sie die neuen Ergebnisse mit dieser statistischen Grenze, um Leistungsregressionen zu erkennen.
- Relatives Continuous Benchmarking
- Führen Sie die Benchmarks für den aktuellen Basiscode aus.
- Verwenden Sie Prozentuale Schwellenwerte, um eine Grenze für den Basiscode zu erstellen.
- Wechseln Sie zur neuen Version des Codes.
- Führen Sie die Benchmarks für die neue Version des Codes aus.
- Vergleichen Sie die Ergebnisse der neuen Version des Codes mit den Ergebnissen des Basiscode, um Leistungsregressionen zu erkennen.
Statistische kontinuierliche Leistungsbewertung
Um da weiterzumachen, wo wir im
Schnellstart und Docker Selbstgehostet Tutorials aufgehört haben,
fügen wir Statistische Kontinuierliche Leistungsbewertung zu unserem Save Walter White
Projekt hinzu.
🐰 Stellen Sie sicher, dass Sie einen API-Token erstellt und diesen als Umgebungsvariable
BENCHER_API_TOKEN
gesetzt haben bevor Sie fortfahren!
Zuerst müssen wir eine neue Testumgebung erstellen, um unsere CI-Runners zu repräsentieren, passend ci-runner
genannt.
bencher testbed create \--name ci-runner \save-walter-white-1234abcd
- Verwenden Sie den CLI-Subbefehl
bencher testbed create
. Weitere Details finden Sie in dentestbed create
Dokumenten. (z.B.:bencher testbed create
) - Setzen Sie die Option
--name
auf den gewünschten Namen der Testumgebung. (z.B.:--name ci-runner
) - Geben Sie das Projektargument als
Save Walter White
Projektslug an. (z.B.:save-walter-white-1234abcd
)
Als Nächstes müssen wir eine neue Schwelle für unsere ci-runner
Testumgebung erstellen:
bencher threshold create \--branch main \--testbed ci-runner \--measure Latency \--test t-test \--upper-boundary 0.95 \save-walter-white-1234abcd
- Verwenden Sie den CLI-Subbefehl
bencher threshold create
. Weitere Details finden Sie in denthreshold create
Dokumenten. (z.B.:bencher threshold create
) - Setzen Sie die Option
--branch
auf den Standard-Branchmain
. (z.B.:--branch main
) - Setzen Sie die Option
--testbed
auf die neueci-runner
Testumgebung. (z.B.:--testbed ci-runner
) - Setzen Sie die Option
--measure
auf das integrierteLatency
Measure, das vonbencher mock
erstellt wird. Weitere Details finden Sie in der Definition von Measure. (z.B.:--measure Latency
) - Setzen Sie die Option
--test
auf einent-test
Threshold. Eine vollständige Übersicht finden Sie unter Schwellen & Warnungen. (z.B.:--test t-test
) - Setzen Sie die Option
--upper-boundary
auf eine obere Grenze von0.95
. Eine vollständige Übersicht finden Sie unter Schwellen & Warnungen. (z.B.:--upper-boundary 0.95
) - Geben Sie das Projektargument als
Save Walter White
Projektslug an. (z.B.:save-walter-white-1234abcd
)
Jetzt sind wir bereit, unsere Benchmarks in der CI auszuführen. Da jede CI-Umgebung etwas anders ist, ist das folgende Beispiel eher illustrativ als praktisch gedacht. Für spezifischere Beispiele siehe Kontinuierliche Leistungsbewertung in GitHub Actions und Kontinuierliche Leistungsbewertung in GitLab CI/CD.
Wir müssen eine historische Basislinie für unseren main
Branch erstellen und pflegen, indem wir jede Änderung in der CI benchmarken:
bencher run \--project save-walter-white-1234abcd \--branch main \--testbed ci-runner \--adapter json \--err \bencher mock
- Verwenden Sie den
bencher run
CLI-Subbefehl, um Ihre Benchmarks desfeature-branch
Branches auszuführen. Eine vollständige Übersicht finden Sie in dembencher run
CLI-Subbefehl. (z.B.:bencher run
) - Setzen Sie die Option
--project
auf den Projektslug. Weitere Details finden Sie in den--project
Dokumenten. (z.B.:--project save-walter-white-1234abcd
) - Setzen Sie die Option
--branch
auf den Standard-Branch-Namen. Eine vollständige Übersicht finden Sie unter Branch-Auswahl. (z.B.:--branch main
) - Setzen Sie die Option
--testbed
auf den Namen der Testumgebung. Weitere Details finden Sie in den--tested
Dokumenten. (z.B.:--testbed ci-runner
) - Setzen Sie die Option
--adapter
auf den gewünschten Benchmark-Harness-Adapter. Eine vollständige Übersicht finden Sie unter Benchmark-Harness-Adapter. (z.B.:--adapter json
) - Setzen Sie die Option
--err
auftrue
, um den Befehl zu beenden, wenn eine Warnung generiert wird. Eine vollständige Übersicht finden Sie unter Schwellen & Warnungen. (z.B.:--err
) - Geben Sie die Benchmark-Befehlsargumente an.
Eine vollständige Übersicht finden Sie unter Benchmark-Befehl.
(z.B.:
bencher mock
)
Zuletzt sind wir bereit, Leistungsregressionen in der CI zu erkennen.
So würden wir die Leistung eines neuen Feature-Branchs namens feature-branch
in der CI verfolgen:
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
- Verwenden Sie den
bencher run
CLI-Subbefehl, um Ihre Benchmarks desfeature-branch
Branches auszuführen. Eine vollständige Übersicht finden Sie in dembencher run
CLI-Subbefehl. (z.B.:bencher run
) - Setzen Sie die Option
--project
auf den Projektslug. Weitere Details finden Sie in den--project
Dokumenten. (z.B.:--project save-walter-white-1234abcd
) - Setzen Sie die Option
--branch
auf den Feature-Branch-Namen. Eine vollständige Übersicht finden Sie unter Branch-Auswahl. (z.B.:--branch feature-branch
) - Setzen Sie die Option
--branch-start-point
auf den Startpunkt des Feature-Branches. Eine vollständige Übersicht finden Sie unter Branch-Auswahl. (z.B.:--branch-start-point main
) - Setzen Sie die Option
--branch-start-point-hash
auf dengit
Hash des Startpunkts des Feature-Branches. Eine vollständige Übersicht finden Sie unter Branch-Auswahl. (z.B.:--branch-start-point-hash 32ae...dd8b
) - Setzen Sie die Flagge
--branch-reset
, um den Branch immer auf den Startpunkt zurückzusetzen. Dies verhindert ein Abdriften der Benchmark-Daten. Eine vollständige Übersicht finden Sie unter Branch-Auswahl. (z.B.:--branch-reset
) - Setzen Sie die Option
--testbed
auf den Namen der Testumgebung. Weitere Details finden Sie in den--tested
Dokumenten. (z.B.:--testbed ci-runner
) - Setzen Sie die Option
--adapter
auf den gewünschten Benchmark-Harness-Adapter. Eine vollständige Übersicht finden Sie unter Benchmark-Harness-Adapter. (z.B.:--adapter json
) - Setzen Sie die Option
--err
auftrue
, um den Befehl zu beenden, wenn eine Warnung generiert wird. Eine vollständige Übersicht finden Sie unter Schwellen & Warnungen. (z.B.:--err
) - Geben Sie die Benchmark-Befehlsargumente an.
Eine vollständige Übersicht finden Sie unter Benchmark-Befehl.
(z.B.:
bencher mock
)
Beim ersten Mal, wenn dieser Befehl in der CI ausgeführt wird,
wird der feature-branch
Branch erstellt, da er noch nicht existiert.
Der neue feature-branch
wird die main
Branch
mit dem Hash 32aea434d751648726097ed3ac760b57107edd8b
als Startpunkt verwenden.
Das bedeutet, dass feature-branch
eine Kopie aller Daten und Schwellen
vom main
Branch haben wird, um die Ergebnisse von bencher mock
zu vergleichen,
für die erste und alle nachfolgenden Durchlä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
- Verwenden Sie das
bencher testbed create
CLI-Unterkommando. Siehe dietestbed create
Dokumentation für mehr Details. (Bsp.:bencher testbed create
) - Setzen Sie die
--name
Option auf den gewünschten Testumgebungs-Namen. (Bsp.:--name ci-runner
) - 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
- Verwenden Sie das
bencher run
CLI-Unterkommando um Ihre Benchmarks desmain
-Branches auszuführen. Siehe dasbencher run
CLI-Unterkommando für einen vollständigen Überblick. (Bsp.:bencher run
) - Setzen Sie die
--project
Option auf den Projekt-Slug. Siehe die--project
Dokumentation für mehr Details. (Bsp.:--project save-walter-white-1234abcd
) - Setzen Sie die
--branch
Option auf den Namen des Feature-Branches. Siehe Branch-Auswahl für einen vollständigen Überblick. (Bsp.:--branch feature-branch
) - Setzen Sie das
--branch-reset
Flag. Siehe Branch-Auswahl für einen vollständigen Überblick. (Bsp.:--branch-reset
) - Setzen Sie die
--testbed
Option auf den Namen der Testumgebung. Siehe die--tested
Dokumentation für mehr Details. (Bsp.:--testbed ci-runner
) - 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
) - 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
- Verwenden Sie das
bencher threshold create
CLI-Unterkommando. Siehe diethreshold create
Dokumentation für mehr Details. (Bsp.:bencher threshold create
) - Setzen Sie die
--branch
Option auf den neuenfeature-branch
Branch. (Bsp.:--branch feature-branch
) - Setzen Sie die
--branch
Option auf dieci-runner
Testumgebung. (Bsp.:--testbed ci-runner
) - Setzen Sie die
--measure
Option auf das integrierteLatency
Maß, das vonbencher mock
generiert wird. Siehe die Definition von Maß für Details. (Bsp.:--measure Latency
) - Setzen Sie die
--test
Option auf einenProzentsatz
-Schwellenwert. Siehe Schwellenwerte & Alarme für einen vollständigen Überblick. (Bsp.:--test t-test
) - Setzen Sie die
--upper-boundary
Option auf eine obere Grenze von0.25
(d. h.25%
). Siehe Schwellenwerte & Alarme für einen vollständigen Überblick. (Bsp.:--upper-boundary 0.25
) - 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
- Verwenden Sie das
bencher run
CLI-Unterkommando um Ihre Benchmarks desfeature-branch
auszuführen. Siehe dasbencher run
CLI-Unterkommando für einen vollständigen Überblick. (Bsp.:bencher run
) - Setzen Sie die
--project
Option auf den Projekt-Slug. Siehe die--project
Dokumentation für mehr Details. (Bsp.:--project save-walter-white-1234abcd
) - Setzen Sie die
--branch
Option auf den Namen des Feature-Branches. Siehe Branch-Auswahl für einen vollständigen Überblick. (Bsp.:--branch feature-branch
) - Setzen Sie die
--testbed
Option auf den Namen der Testumgebung. Siehe die--tested
Dokumentation für mehr Details. (Bsp.:--testbed ci-runner
) - 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
) - 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
) - 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! 🎉