Was ist Kontinuierliches Benchmarking?

Kontinuierliches Benchmarking ist eine Praxis in der Softwareentwicklung, bei der Mitglieder eines Teams ihre Arbeit häufig messen, 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 stellen fest, dass dieser Ansatz zu deutlich reduzierten Leistungsregressionen 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 grundlegender Ebene geht es bei CI darum, Regressionen von Softwarefunktionen zu erkennen und zu verhindern, bevor sie in die Produktion gelangen. Ebenso geht es beim Kontinuierlichen Benchmarking (CB) 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 ausgeführt werden, sollten Leistungstests in CB für jede Codeänderung ausgeführt werden. Diese Analogie ist tatsächlich so treffend, dass der erste Absatz dieses Abschnitts lediglich eine Mad-Libs-Version von Martin Fowlers Einführung in Continuous Integration aus dem Jahr 2006 ist.

🐰 Performance-Bugs sind Fehler!

Benchmarking in CI

Mythos: Benchmarks lassen sich nicht in CI ausführen

Die meisten Benchmark-Harnische verwenden die System-Wanduhr zur Messung von Latenz oder Durchsatz. Das ist sehr hilfreich, denn das sind genau die Metriken, die uns als Entwickler am meisten interessieren. Allgemeine CI-Umgebungen sind jedoch beim Messen der Wanduhrzeit oft verrauscht und inkonsistent. Beim Kontinuierlichen Benchmarking fügt diese Volatilität unerwünschtes Rauschen in die Ergebnisse ein.

Es gibt einige Möglichkeiten, damit umzugehen:

1. Dedizierte Hardware-Runner
2. Relatives Kontinuierliches Benchmarking
3. Der Wechsel zu einem Benchmark-Harnisch, der Instruktionen anstelle der Wanduhrzeit zählt

Mit Abstand sind dedizierte Hardware-Runner in nahezu jedem Fall die beste Option. Bencher bietet dedizierte Hardware-Runner mit einer Varianz von unter 2 %. Vergleichen Sie das mit GitHub-Action-Runnern, bei denen die Varianz zwischen einzelnen Läufen über 30 % betragen kann. Wenn Sie die Volatilität und damit das Rauschen in Ihrer Umgebung für Kontinuierliches Benchmarking reduzieren, können Sie immer feinere Leistungsregressionen erkennen.

Leistung zählt

Mythos: Man kann 100 ms Latenz nicht wahrnehmen

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

0,1 Sekunden sind ungefähr die Grenze, bei der der Nutzer das Gefühl hat, dass das System unmittelbar 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 bereits 2 ms Latenz wahrnehmen. Ein einfacher Weg, das zu belegen, ist ein Experiment von Dan Luu: Öffnen Sie Ihr Terminal und führen Sie sleep 0; echo "ping" aus und anschließend sleep 0.1; echo "pong". Sie haben den Unterschied bemerkt, oder‽

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

Leistung zählt! Performance ist ein Feature!

• Jede 100 ms schneller → 1 % mehr Conversions (Mobify, verdient +380.000 $/Jahr)
• 50 % schneller → 12 % mehr Umsatz (AutoAnything)
• 20 % schneller → 10 % mehr Conversions (Furniture Village)
• 40 % schneller → 15 % mehr Anmeldungen (Pinterest)
• 850 ms schneller → 7 % mehr Conversions (COOK)
• Jede 1 Sekunde langsamer → 10 % weniger Nutzer (BBC)

Mit dem Ende des Mooreschen Gesetzes müssen Arbeitslasten, die parallel laufen können, parallelisiert werden. Die meisten Arbeitslasten müssen jedoch seriell ausgeführt werden, und einfach mehr Rechenleistung auf das Problem zu werfen, wird schnell zu einer unlösbaren und teuren Lösung.

Kontinuierliches Benchmarking ist ein entscheidender Baustein für die Entwicklung und Pflege leistungsfähiger moderner Software angesichts dieses Wandels.

Werkzeuge für Kontinuierliches Benchmarking

Bevor wir Bencher entwickelt haben, haben wir nach einem Werkzeug gesucht, das Folgendes leisten konnte:

• Benchmarks sowohl lokal als auch in CI auf exakt derselben dedizierten Hardware ausführen
• Benchmarks sprachübergreifend verfolgen
• Nahtlose Aufnahme der Standardausgaben sprachspezifischer Benchmark-Harnische
• Erweiterbar für benutzerdefinierte Benchmark-Harnisch-Ausgaben
• Open Source und selbst hostbar
• Mit mehreren CI-Hosts funktionieren
• Benutzer-Authentifizierung und -Autorisierung

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

Kontinuierliches Benchmarking außerhalb von CI

CI ist als abschließende Kontrolle gedacht, nicht als der einzige Ort, an dem Tests durchgeführt werden. Bencher ist das erste Werkzeug für Kontinuierliches Benchmarking, mit dem Sie Ihre Benchmarks sowohl lokal als auch in CI auf exakt derselben dedizierten Hardware ausführen können. Damit können Entwickler und Agenten ihre laufende lokale Arbeit mit jedem beliebigen Punkt der Leistungshistorie ihres Projekts vergleichen.

Wenn Bencher auf lokaler Hardware läuft, erlaubt Ihnen die dedizierte Hardware von Bencher, parallel weiterzuarbeiten. Sie müssen nicht alles andere auf Ihrem System anhalten, einen alten Branch auschecken und einen Vergleich ausführen.

Wenn Bencher in einer Cloud-Umgebung läuft, erlaubt Ihnen die dedizierte Hardware von Bencher, den Ergebnissen zu vertrauen. Keine Sorge mehr wegen lauter Nachbarn, Throttling oder spontaner Hostwechsel mitten im Lauf.

Kontinuierliches Benchmarking in Big Tech

Werkzeuge wie Bencher wurden intern bei Microsoft, Facebook (jetzt Meta), Apple, Amazon, Netflix und Google sowie unzähligen anderen entwickelt. Als Giganten der Branche verstehen sie die Bedeutung der Leistungsüberwachung während der Entwicklung und die Integration dieser Erkenntnisse in den Entwicklungsprozess durch Kontinuierliches Benchmarking. Wir haben Bencher entwickelt, um Kontinuierliches Benchmarking hinter den Mauern von Big Tech hervorzuholen und der Open-Source-Community zugänglich zu machen. Links zu Beiträgen von Big Tech zum Thema Kontinuierliches Benchmarking finden Sie unter bestehende Lösungen.

Bencher: Kontinuierliches Benchmarking

Bencher ist eine Suite von Tools für kontinuierliches Benchmarking. Hatten Sie jemals eine Performance Regression, die Ihre Nutzer beeinflusste? Bencher hätte das verhindern können. Bencher ermöglicht es Ihnen, Leistungsregressionen zu erkennen und zu verhindern, bevor sie gemergt werden.

• Ausführen: Führen Sie Ihre Benchmarks lokal oder in CI mit exakt denselben Bare-Metal-Runnern und Ihren bevorzugten Benchmarking-Tools aus. Das bencher CLI orchestriert die Ausführung Ihrer Benchmarks auf Bare Metal 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 lokal oder in CI mit exakt derselben Bare-Metal-Hardware ab. Bencher verwendet modernste, anpassbare Analysen, um Leistungsregressionen zu erkennen, bevor sie gemergt werden.

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

Beginnen Sie damit, Leistungsregressionen 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. Lokale Vergleiche sind ideal für schnelle Iterationen beim Tuning der Leistung. Man sollte sich jedoch nicht darauf verlassen, um Leistungsregressionen fortlaufend aufzuspüren. Genauso wie die Möglichkeit, Unit-Tests lokal auszuführen, die Notwendigkeit für CI nicht überflüssig macht, macht die Möglichkeit, Benchmarks lokal auszuführen und zu vergleichen, die Notwendigkeit für Kontinuierliches Benchmarking nicht überflüssig.

Es gibt mehrere Funktionen, die Bencher bietet und die lokale Benchmark-Vergleichswerkzeuge 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 Testumgebungen, um Rauschen zu minimieren
• Kein Copy-and-Paste mehr

Kontinuierliches Benchmarking vs. Anwendungsleistungsmanagement (APM)

Anwendungsleistungsmanagement (APM) ist ein unverzichtbares Werkzeug für moderne Software-Dienste. APM ist jedoch für den Einsatz in der Produktion konzipiert. Wenn eine Leistungsregression erkannt wird, hat sie bereits Auswirkungen auf Ihre Kunden.

Die meisten Defekte kosten am Ende mehr, als es gekostet hätte, sie zu verhindern. Defekte sind teuer, wenn sie auftreten, sowohl durch die direkten Kosten der Fehlerbehebung als auch durch die indirekten Kosten aufgrund beschädigter Beziehungen, verlorener Geschäfte und verlorener Entwicklungszeit.

— Kent Beck, Extreme Programming Explained

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

• Leistungsregressionen erkennen, bevor sie zusammengeführt werden
• Leistungsänderungen und -auswirkungen werden in den Code-Review einbezogen
• Kein Overhead in Produktionsumgebungen
• Wirksam für On-Prem-Bereitstellungen
• Keine Änderungen am Produktions-Quellcode

Kontinuierliches Benchmarking vs. Beobachtbarkeit

Eine Rose würde unter jedem anderen Namen genauso süß duften. 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 ausgeführt werden, sollten Leistungstests in CB für jede Codeänderung ausgeführt werden.

Während Unit- und Akzeptanztests weithin als Standardentwicklungspraktiken anerkannt sind, hat sich dieser Trend nicht in den Bereich der Leistungstests fortgesetzt. Derzeit drängt die gängige Werkzeugwelt Tester dazu, Wegwerfcode zu erstellen und in eine Klick-und-Skript-Mentalität zu verfallen. Wenn man Leistungstests als gleichrangig behandelt, ermöglicht dies die Erstellung besserer Tests, die mehr Funktionalität abdecken, was zu besseren Werkzeugen zum Erstellen und Ausführen von Leistungstests führt und eine Testsuite zur Folge hat, 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 isoliert zu testen. Lasttests prüfen die Leistung von Software ausschließlich 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 Eiswagens verfolgen. Benchmarking könnte verwendet werden, um zu messen, wie lange es dauert, eine Eiskugel in eine Waffel zu füllen (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 ➡