Was ist Kontinuierliches Benchmarking?

Das kontinuierliche Benchmarking ist eine Praxis in der Softwareentwicklung, bei der Mitglieder eines Teams ihre Arbeit regelmäßig bewerten. In der Regel führt jede Person mindestens täglich ein Benchmark durch - was zu mehreren Benchmarks pro Tag führt. Jedes Benchmark wird von einem automatisierten Build überprüft, um Leistungsregressionen so schnell wie möglich zu erkennen. Viele Teams finden, dass dieser Ansatz zu deutlich reduzierten Leistungseinbrüchen führt und es einem Team ermöglicht, performante Software schneller zu entwickeln.

Inzwischen ist jeder in der Softwarebranche mit Continuous Integration (CI) vertraut. Auf einer grundsätzlichen Ebene geht es bei CI darum, Software-Feature-Regressions zu erkennen und zu verhindern, bevor sie in die Produktion gelangen. Ähnlich verhält es sich mit dem kontinuierlichen Benchmarking (CB): Es geht darum, Software-Leistungsregressionen zu erkennen und zu verhindern, bevor sie in die Produktion gelangen. Aus denselben Gründen, aus denen Unit-Tests in CI für jede Codeänderung durchgeführt werden, sollten Leistungstests in CB für jede Codeänderung durchgeführt werden. Diese Analogie ist so treffend, dass der erste Absatz dieses Abschnitts einfach eine Mad Libs-Version von Martin Fowler’s 2006 Einleitung zu Continuous Integration ist.

🐰 Performance-Bugs sind Fehler!

Benchmarking in CI

Mythos: Benchmarking kann nicht in CI durchgeführt werden

Die meisten Benchmarking-Halterungen verwenden die Systemwanduhr zur Messung von Latenz oder Durchsatz. Das ist sehr hilfreich, denn das sind genau die Metriken, um die wir uns als Entwickler am meisten kümmern. Allerdings sind allgemeine CI-Umgebungen oft laut und inkonsistent, wenn es darum geht, die Wanduhrzeit zu messen. Bei kontinuierlichem Benchmarking fügt diese Volatilität unerwünschtes Rauschen in die Ergebnisse ein.

Es gibt einige Optionen, um damit umzugehen:

• Relatives Benchmarking
• Dedizierte CI-Runner
• Wechsel von Benchmark-Halterungen zu einer, die Anweisungen zählt anstatt der Wandzeit

Oder einfach das Chaos annehmen! Kontinuierliches Benchmarking muss nicht perfekt sein. Ja, die Reduzierung der Volatilität und damit des Rauschens in Ihrer kontinuierlichen Benchmarking-Umgebung ermöglicht es Ihnen, immer feinere Leistungsregressionen zu erkennen. Lassen Sie sich hier jedoch nicht von dem Gedanken leiten, dass Perfektion der Feind des Guten ist!

Sie sehen diese Grafik und denken vielleicht: “Wow, das ist verrückt!” Aber fragen Sie sich: Kann Ihr aktueller Entwicklungsprozess eine Leistungsverschlechterung um das Zwei- oder sogar Zehnfache erkennen, bevor sie Ihre Nutzer beeinflusst? Wahrscheinlich nicht! Das ist verrückt!

Selbst bei all dem Rauschen aus einer CI-Umgebung kann das Nachverfolgen von Wanduhr-Benchmarks immer noch große Vorteile bringen, indem es Leistungsregressionen erkennt, bevor sie Ihre Kunden in der Produktion erreichen. Mit der Zeit können Sie von dort aus weiter aufbauen, wenn Ihr Softwareleistungsmanagement reift. In der Zwischenzeit verwenden Sie einfach Ihre reguläre CI.

Leistung zählt!

Mythos: Man kann 100 ms Latenz nicht bemerken

Es ist üblich zu hören, dass Menschen behaupten, 100 ms Latenzzeit nicht wahrnehmen zu können. Ein Artikel der Nielsen Group über Antwortzeiten wird oft für diese Behauptung zitiert.

0,1 Sekunde ist ungefähr die Grenze, bei der der Nutzer das Gefühl hat, dass das System sofort reagiert, d. h. dass keine besondere Rückmeldung erforderlich ist, außer das Ergebnis anzuzeigen.

• Jakob Nielsen, 1. Januar 1993

Aber das stimmt einfach nicht. Bei einigen Aufgaben können Menschen gerade einmal 2 ms Latenzzeit wahrnehmen. Eine einfache Möglichkeit, dies zu beweisen, ist ein Experiment von Dan Luu: Öffnen Sie Ihre Konsole und führen Sie sleep 0; echo "ping" aus und dann sleep 0,1; echo "pong". Sie haben den Unterschied bemerkt, oder‽

Ein weitere häufige Verwechslung ist der Unterschied zwischen der Wahrnehmung von Latenz und menschlichen Reaktionszeiten. Obwohl es etwa 200 ms dauert, auf einen visuellen Reiz zu reagieren, ist das unabhängig von der Wahrnehmung des Ereignisses selbst. Analog dazu können Sie bemerken, dass Ihr Zug zwei Minuten zu spät ist (wahrgenommene Latenz), obwohl die Zugfahrt zwei Stunden dauert (Reaktionszeit).

Die Leistung zählt! Leistung ist ein Feature!

• Jede 100 ms schneller → 1% mehr Konvertierungen (Mobify, Einnahmen +380.000$/Jahr)
• 50% schneller → 12% mehr Verkäufe (AutoAnything)
• 20% schneller → 10% mehr Konvertierungen (Furniture Village)
• 40% schneller → 15% mehr Anmeldungen (Pinterest)
• 850 ms schneller → 7% mehr Konvertierungen (COOK)
• Jede 1 sekunde langsamer → 10% weniger Nutzer (BBC)

Mit dem Ende des Moore’schen Gesetzes müssen Arbeitslasten, die parallel laufen können, parallelisiert werden. Allerdings müssen die meisten Arbeitslasten in Serie ausgeführt werden, und einfach mehr Rechnerleistung auf das Problem zu werfen, wird schnell eine unlösbare und teure Lösung.

Kontinuierliches Benchmarking ist ein Schlüsselelement zur Entwicklung und Pflege leistungsfähiger moderner Software angesichts dieser Veränderung.

Kontinuierliche Benchmarking-Tools

Bevor wir Bencher erstellt haben, haben wir nach einem Tool gesucht, das:

• Benchmarks in mehreren Sprachen verfolgen kann
• Sprachstandard-Benchmark-Ausgaben nahtlos integrieren kann
• Erweiterbar für benutzerdefinierten Benchmark-Ausgaben
• Open Source und fähig zur Selbst-Hosting
• Zusammenarbeit mit mehreren CI-Hosts
• Benutzerauthentifizierung und -autorisierung

Leider existierte nichts, das alle diese Kriterien erfüllte. Siehe bestehende Lösungen für eine umfassende Liste der bestehenden Benchmarking-Tools, von denen wir uns inspirieren ließen.

Kontinuierliches Benchmarking in Big Tech

Tools wie Bencher wurden intern bei Microsoft, Facebook (jetzt Meta), Apple, Amazon, Netflix und Google unter unzähligen anderen entwickelt. Als Giganten der Branche verstehen sie die Bedeutung der Leistungsmessung während der Entwicklung und integrieren diese Erkenntnisse in den Entwicklungsprozess durch CB. Wir haben Bencher entwickelt, um kontinuierliches Benchmarking aus dem Hinterzimmer der Big Tech in die Open-Source-Community zu bringen. Für Links zu Posts, die sich auf kontinuierliches Benchmarking in Big Tech beziehen, siehe bestehende Lösungen.

Bencher: Kontinuierliches Benchmarking

Bencher ist eine Suite von kontinuierlichen Benchmarking-Tools. Hatten Sie jemals eine Performance Regression, die Ihre Nutzer beeinflusste? Bencher hätte das verhindern können. Bencher ermöglicht es Ihnen, Leistungsregressionen vorher zu erkennen und zu verhindern, bevor sie in die Produktion gelangen.

• Ausführen: Führen Sie Ihre Benchmarks lokal oder in CI mit Ihren bevorzugten Benchmarking-Tools aus. Das bencher CLI umfasst einfach Ihr vorhandenes Benchmark-Harness und speichert die Ergebnisse.
• Verfolgen: Verfolgen Sie die Ergebnisse Ihrer Benchmarks im Laufe der Zeit. Überwachen, abfragen und grafisch darstellen der Ergebnisse mit der Bencher Web Konsole auf Basis des Quellzweigs, Testbetts und Maßnahme.
• Auffangen: Fangen Sie Leistungsregressionen in CI ab. Bencher verwendet modernste, anpassbare Analysen, um Leistungsregressionen zu erkennen, bevor sie in die Produktion gelangen.

Aus denselben Gründen, warum Unit Tests in CI laufen, um Feature Regressionen zu verhindern, sollten Benchmarks in CI mit Bencher ausgeführt werden, um Leistungsregressionen zu verhindern. Performance-Bugs sind Fehler!

Beginnen Sie damit, Leistungsregressionen in CI aufzufangen - probieren Sie Bencher Cloud kostenlos aus.

Kontinuierliches Benchmarking vs. Lokaler Benchmark-Vergleich

Es gibt mehrere Benchmark-Harnische, mit denen Sie Ergebnisse lokal vergleichen können. Lokaler Vergleich ist ideal für schnelle Iterationen bei der Leistungsoptimierung. Er sollte jedoch nicht als ständige Kontrolle zur Erkennung von Leistungsregressionen verlassen werden. Genau so wie die Möglichkeit, Unit-Tests lokal zu laufen, die Notwendigkeit für CI nicht überflüssig macht, macht die Möglichkeit, Benchmarks lokal zu laufen und zu vergleichen, die Notwendigkeit für CB nicht überflüssig.

Es gibt mehrere Funktionen, die Bencher bietet, die lokale Benchmark-Vergleichstools nicht können:

• Vergleich desselben Benchmarks zwischen verschiedenen Testumgebungen
• Vergleich von Benchmarks über Sprachen und Harnische hinweg
• Zusammenarbeit und Teilen von Benchmark-Ergebnissen
• Ausführen von Benchmarks auf dedizierten Testbetten zur Minimierung von Störungen
• Kein weiteres Kopieren und Einfügen

Kontinuierliches Benchmarking vs. Anwendungsleistungsmanagement (APM)

Das Anwendungsleistungsmanagement (APM) ist ein wichtiges Werkzeug für moderne Software-Dienstleistungen. Allerdings ist APM dafür ausgelegt, in der Produktion eingesetzt zu werden. Bis eine Leistungsregression erkannt ist, hat sie bereits Auswirkungen auf Ihre Kunden.

Die meisten Fehler enden damit, dass sie mehr kosten als ihre Verhinderung gekostet hätte. Fehler sind teuer, wenn sie auftreten, sowohl die direkten Kosten der Fehlerbehebung als auch die indirekten Kosten durch beschädigte Beziehungen, verlorenes Geschäft und verlorene Entwicklungszeit.

— Kent Beck, Extreme Programming Explained

Es gibt mehrere Funktionen, die Bencher bietet, die APM-Tools nicht können:

• Erkennen und Verhindern von Leistungsregressionen vor ihrem Auftreten in der Produktion
• Leistungsänderungen und -auswirkungen im Code-Review inbegriffen
• Keine Overheadkosten in Produktionsumgebungen
• Effektiv für On-Prem-Bereitstellungen
• Keine Änderungen am Produktionsquellcode

Kontinuierliches Benchmarking vs. Beobachtbarkeit

Eine Rose mit einem anderen Namen würde genauso süß riechen. Siehe Kontinuierliches Benchmarking vs. Anwendungsleistungsmanagement oben.

Kontinuierliches Benchmarking vs. Kontinuierliche Integration (CI)

Kontinuierliches Benchmarking (CB) ergänzt die Kontinuierliche Integration (CI). Aus den gleichen Gründen, aus denen Unit-Tests in CI für jede Code-Änderung durchgeführt werden, sollten Leistungstests in CB für jede Code-Änderung durchgeführt werden.

Während Unit- und Akzeptanztests weitgehend als Standardentwicklungspraktiken anerkannt sind, hat sich dieser Trend nicht in den Bereich der Leistungstests fortgesetzt. Derzeit führt die gängige Tooling-Lösung Tester dazu, Wegwerfcode zu erstellen und eine Klick-und-Skript-Mentalität zu entwickeln. Die Behandlung von Leistungstests als wichtige Komponente ermöglicht die Erstellung besserer Tests, die mehr Funktionalitäten abdecken, was zu besseren Tools zur Erstellung und Durchführung von Leistungstests führt, was wiederum zu einem Test-Suite führt, die wartbar ist und selbst getestet werden kann.

— Thoughworks Technology Radar, 22. Mai 2013

Kontinuierliches Benchmarking vs. Kontinuierliches Lasttesting

Um den Unterschied zwischen Kontinuierlichem Benchmarking und Kontinuierlichem Lasttesting zu verstehen, müssen Sie den Unterschied zwischen Benchmarking und Lasttesting verstehen.

Benchmarking kann die Leistung von Software von der Funktionsebene (Mikro-Benchmarks) bis hin zur Dienstebene (Makro-Benchmarks) testen. Benchmarks sind ideal, um die Leistung eines bestimmten Teils Ihres Codes auf isolierte Weise zu testen. Lasttests testen nur die Leistung von Software auf der Dienstebene und simulieren mehrere gleichzeitige Benutzer. Lasttests sind ideal, um die Leistung des gesamten Dienstes unter einer bestimmten Last zu testen.

🍦 Stellen Sie sich vor, wir wollten die Leistung eines Eiswagen verfolgen. Benchmarking könnte verwendet werden, um zu messen, wie lange es dauert, eine Eistüte zu portionieren (Mikro-Benchmark), und Benchmarking könnte auch verwendet werden, um zu messen, wie lange es dauert, bis ein einzelner Kunde bestellt, sein Eis erhält und bezahlt (Makro-Benchmark). Lasttests könnten verwendet werden, um zu sehen, wie gut der Eiswagen 100 Kunden an einem heißen Sommertag bedient.

Weitermachen: Schnellstart ➡