Was ist Benchmark Testing?

Was ist Benchmark Testing?

Benchmark Testing misst die Performance eines Systems gegen einen definierten Standard, damit das Ergebnis vergleichbar ist. Dieser Standard kann ein früherer Build sein, ein Konkurrenzprodukt, ein veröffentlichter Branchen-Benchmark oder eine intern vereinbarte Baseline. Der Wert liegt im Vergleich: Eine Zahl allein sagt wenig, neben einer Referenz zeigt sie, ob die Performance besser, schlechter oder gleich geblieben ist. So wird aus "die App fühlt sich schnell an" die Aussage "dieser Build schafft bei gleicher Latenz mehr Durchsatz als der letzte", und danach kann Technik, Produkt und Management handeln.

Ein Benchmark ist von Natur aus wiederholbar. Jedes Mal gelten dieselbe Hardware, derselbe Datensatz, derselbe Workload-Mix, dieselbe Aufwärmphase und dasselbe Messfenster. Ein Lauf, der sich nicht reproduzieren lässt, ist kein Benchmark, sondern eine einzelne Beobachtung. Bekannte öffentliche Benchmarks legen ihre Methodik bis ins letzte Konfigurationsdetail fest, damit verschiedene Teams vergleichbare Zahlen erzeugen.

Zweck und Einsatz

Sie führen einen Benchmark aus, wenn Sie eine belastbare, vergleichbare Zahl brauchen statt einer Einzelmessung. Typische Anlässe:

• Vor und nach einem Refactoring: denselben Workload vor und nach dem Umbau messen, um Rückschritte bei Durchsatz oder Latenz auszuschließen.
• Runtime- oder Abhängigkeits-Updates: eine neue Version von Laufzeit, JVM, Datenbank oder Framework kann die Performance in beide Richtungen verschieben. Herstellerangaben passen selten zu Ihrem Workload, also messen Sie selbst.
• Technologieauswahl: beim Vergleich von Datenbanken, Caches oder Message-Brokern lieber einen Benchmark mit Ihrem eigenen Workload bauen, statt einem Herstellervergleich zu glauben.
• Gates in der CI: ein schlanker Benchmark pro Pull Request fängt Performance-Regressionen vor dem Merge ab.
• Kapazitäts- und Kostenplanung: mit einer verlässlichen Performance-Baseline dimensionieren Sie die Infrastruktur und schätzen Kosten bei wachsendem Traffic, siehe Kapazitätstest.
• Positionierung gegenüber Wettbewerbern: erst eine veröffentlichte, reproduzierbare Methodik macht ein "schneller als" glaubwürdig.

Was Benchmark und Baseline sind

Eine Baseline ist der Referenzpunkt, gegen den Sie messen. Meist ist es der aktuelle Produktions-Build oder das zuletzt akzeptierte Release, unter kontrollierten Bedingungen erfasst und mit vollem Kontext gespeichert. Ein Benchmark ist der standardisierte Test, der ein vergleichbares Ergebnis liefert. In der Praxis legen Sie die Baseline einmal fest, führen den Benchmark wiederholt aus und vergleichen jedes Ergebnis mit ihr. Wird ein neuer Build zum akzeptierten Standard, wird er zur neuen Baseline. Ohne Baseline ist ein Benchmark-Ergebnis nur eine Zahl ohne Vergleich. Eine kurze Anleitung gibt es in How to establish a performance baseline (auf Englisch).

Wichtige Metriken

Ein Benchmark ist nur so nützlich wie die Metriken, die er erfasst. Der Kern:

• Durchsatz: Anfragen oder Transaktionen pro Sekunde, die das System dauerhaft schafft. Oft die Schlagzeilenzahl des Benchmarks.
• Antwortzeit und Latenz: wie lange eine Anfrage dauert, als Perzentile statt als Durchschnitt. Der Durchschnitt versteckt den langsamen Rand.
• Latenz-Perzentile (p50, p95, p99): p50 ist die typische Erfahrung, p95 und p99 beschreiben den langsamen Rand, den echte Nutzer unter Last spüren.
• Fehlerrate: der Anteil fehlgeschlagener oder abgelaufener Anfragen. Ein hoher Durchsatz ist wertlos, wenn die Fehler mitsteigen.
• Ressourcenauslastung: CPU, Speicher, Disk und Netzwerk des getesteten Systems. Sie zeigt, wie viel Reserve bleibt und wo der Engpass sitzt.

Erfassen Sie Durchsatz und Latenz immer gemeinsam. Ein Durchsatz, der bei steigender Fehlerrate oder explodierender Latenz gemessen wurde, ist kein gültiger Vergleichspunkt.

Benchmark vs. Last-, Stress- und Performance-Test

Diese Disziplinen überlappen sich, beantworten aber unterschiedliche Fragen. Benchmark Testing fragt: "Wie schneidet das gegenüber einer Referenz ab?" Der Lasttest fragt: "Was passiert bei erwarteter Nutzerzahl?" Der Stresstest fragt: "Wo bricht es?" Performance-Test ist der Oberbegriff für alle.

Kurz: Ein Lasttest liefert eine Kurve, ein Stresstest findet ein Limit, und ein Benchmark liefert eine einzelne vergleichbare Zahl, die Sie von Release zu Release verfolgen.

So führen Sie einen Benchmark aus

Ein verlässlicher Benchmark entsteht, indem Sie alles kontrollieren, was nicht gemessen werden soll:

1. Baseline festlegen: entscheiden, womit Sie vergleichen, und sie unter denselben Bedingungen erfassen wie jeden künftigen Lauf.
2. Umgebung fixieren: gleicher Instanztyp, gleiche Region, gleiches Netzwerk, gleicher Datensatz. Zahlen aus verschiedenen Umgebungen sind nicht vergleichbar.
3. Workload-Mix fixieren: dasselbe Verhältnis von Lese- zu Schreibzugriffen, dieselbe Parameterverteilung, derselbe Authentifizierungsablauf.
4. Aufwärmen, dann messen: JIT-Laufzeiten und kalte Caches sind bei den ersten Anfragen langsam. Verwerfen Sie die Aufwärmphase und messen Sie nur das stabile Plateau.
5. Für Sicherheit wiederholen: ein einzelner Lauf kann verrauscht sein. Mehrere Läufe machen und den Median mit Streuung angeben, nicht den Glückstreffer.
6. Alles festhalten: Durchsatz, Latenz-Perzentile, Fehlerrate, Ressourcenverbrauch sowie Build-Kennung und Konfiguration speichern, damit jeder den Lauf nachstellen kann.

Branchen- vs. interne Benchmarks

Branchen-Benchmarks sind standardisierte, veröffentlichte Tests, mit denen sich unabhängige Teams auf einer gemeinsamen Skala vergleichen. Sie sind für Herstellervergleiche nützlich, bilden aber selten Ihren konkreten Workload ab. Interne Benchmarks basieren auf Ihren eigenen Traffic-Mustern und zählen im Alltag mehr, weil sie messen, was Ihre Nutzer tatsächlich tun. Nutzen Sie Branchen-Benchmarks als Plausibilitätsprüfung für eine Technologieentscheidung und interne Benchmarks, um Regressionen zu finden und zu optimieren. Den Branchen-Benchmark eines Herstellers wie ein Versprechen für Ihren Workload zu behandeln, ist der häufigste Weg, wie Benchmarking in die Irre führt.

APIs und Web-Apps benchmarken

Bei einer API benchmarken Sie jeden wichtigen Endpunkt einzeln mit realistischer Nutzlast und Authentifizierung und verfolgen Durchsatz und Latenz-Perzentile pro Endpunkt. Eine Änderung an einer gemeinsamen Abfrage oder einem Datenbankindex kann einen Endpunkt verschieben und andere unberührt lassen, sodass eine Gesamtzahl eine echte Regression verbirgt.

Bei einer Web-App benchmarken Sie sowohl die Serverseite (Durchsatz und Latenz bei Parallelität) als auch das Erlebnis im Browser (wie schnell Seiten nutzbar werden). Beides hängt zusammen, ist aber verschieden: Ein schnelles Backend kann trotzdem eine langsame Seite liefern, und eine Seite kann schnell wirken, während das Backend fast am Limit ist. Benchmarken Sie beides getrennt, damit Sie wissen, welche Seite sich bewegt hat.

Ergebnisse interpretieren und über die Zeit verfolgen

Ein Benchmark-Ergebnis zählt nur im Kontext. Vergleichen Sie mit der Baseline, nicht mit einem aus der Luft gegriffenen Absolutwert. Kleine Abweichungen von Lauf zu Lauf sind normal, legen Sie also vorher fest, ab welcher Änderung eine echte Regression vorliegt und nicht nur Rauschen. Der eigentliche Nutzen entsteht, wenn Sie jeden Lauf speichern und den Trend darstellen: Ein langsamer Drift über mehrere Releases ist in einem einzelnen Vergleich unsichtbar, im Diagramm aber offensichtlich, und ein plötzlicher Sprung zeigt direkt auf den verursachenden Commit. Kombinieren Sie Benchmarking mit Regressionstests und machen Sie Releases von beiden abhängig, damit eine Performance-Regression wie ein funktionaler Fehler abgefangen wird.

Um einen Benchmark in LoadFocus zu verfolgen, führen Sie ihn als Cloud-Lasttest aus, speichern einen guten Lauf als Baseline und stellen mit dem Baseline-Vergleich jeden späteren Lauf daneben. Kombinieren Sie das mit Regressionstests, damit ein langsamerer Build vor dem Release auffällt, und lesen Sie die Ergebnisse als Perzentile statt Durchschnittswerte (Artikel auf Englisch).

Häufige Fallstricke

• Verrauschte Umgebungen: geteilte CI-Runner, Hintergrundprozesse und ein ausgelastetes Netzwerk erzeugen Streuung, die das Signal überdeckt. Isolieren Sie das getestete System.
• Unfaire Vergleiche: zwei Dinge gleichzeitig ändern oder über verschiedene Hardware oder Datensätze vergleichen macht das Ergebnis wertlos.
• Aufwärmphase überspringen: Kaltstart-Anfragen im Ergebnis unterschätzen die echte Performance und erhöhen das Rauschen.
• Durchschnitt statt Perzentile: ein guter Durchschnitt kann einen schlechten Rand verbergen, den Nutzer täglich spüren.
• Ein Lauf und fertig: eine einzelne Messung hat keine Aussagesicherheit und kann reines Glück sein.
• Unrealistische Workloads: ein Benchmark, der einen trivialen Endpunkt bombardiert, sagt nichts über die Produktion.

Best Practices

• Veröffentlichen Sie Ihre Methodik, damit jeder den Lauf anhand einer Beschreibung nachstellen kann.
• Ändern Sie nur eine Variable auf einmal und halten Sie alles andere fest.
• Berichten Sie den Durchsatz immer zusammen mit Latenz-Perzentilen und Fehlerrate.
• Automatisieren Sie einen schlanken Benchmark in der CI, damit Regressionen früh und günstig auffallen.
• Speichern Sie Ergebnisse mit Build-Kennung und Konfiguration und verfolgen Sie den Trend, nicht nur den letzten Wert.
• Benchmarken Sie unter Bedingungen nahe an Ihren Nutzern, mit realistischer Geografie und Netzwerk, wenn das Nutzererlebnis zählt.

Häufige Fragen zu Benchmark Testing

Ist Benchmark Testing dasselbe wie Lasttest?

Nein. Benchmark Testing vergleicht ein System unter identischen, kontrollierten Bedingungen mit einer festen Referenz und liefert eine vergleichbare Zahl. Ein Lasttest steigert die Last bis zur erwarteten Nachfrage, um zu sehen, wie sich das System verhält und wo es langsamer wird. Beide ergänzen sich: Der Lasttest findet die Kapazität, der Benchmark verfolgt die Veränderung über die Zeit.

Was macht einen Benchmark gültig?

Wiederholbarkeit. Wenn jemand anderes Ihren Benchmark nicht erneut ausführen und ein vergleichbares Ergebnis bekommen kann, ist es eine Einzelbeobachtung. Ein gültiger Benchmark fixiert Umgebung, Datensatz und Workload-Mix, verwirft die Aufwärmphase, misst den stabilen Zustand und ist so gut dokumentiert, dass er sich nachstellen lässt.

Welche Metriken sollte ein Benchmark erfassen?

Mindestens Durchsatz, Antwortzeit-Perzentile wie p50, p95 und p99, Fehlerrate und Ressourcenauslastung. Durchsatz und Latenz müssen zusammen gelesen werden, denn ein hoher Durchsatz ist keine echte Verbesserung, wenn dafür Fehlerrate oder Latenz am Rand gestiegen sind.

Warum Perzentile statt durchschnittlicher Antwortzeit?

Ein Durchschnitt mischt schnelle und langsame Anfragen zu einer Zahl und versteckt den langsamen Rand. Perzentile zeigen die Verteilung: p50 ist die typische Erfahrung, p95 und p99 beschreiben die schlechtesten Anfragen, die echte Nutzer bemerken, und dort zeigt sich eine Regression oft zuerst.

Wie oft sollte ich Benchmarks ausführen?

Führen Sie laufend einen schlanken Benchmark aus, am besten bei jedem Pull Request oder Release-Kandidaten, damit Regressionen früh auffallen. Einen umfassenderen Benchmark fahren Sie vor großen Änderungen wie Refactorings, Runtime-Updates oder Technologiewechseln und immer dann, wenn Sie für Kapazitätsplanung oder Vergleiche eine belastbare Zahl brauchen.

Kann ich dem veröffentlichten Benchmark eines Herstellers trauen?

Sehen Sie ihn als Ausgangspunkt, nicht als Versprechen. Hersteller-Benchmarks laufen meist auf Workloads und Konfigurationen, die ihr Produkt begünstigen. Nur ein Benchmark mit Ihrem eigenen Workload in Ihrer eigenen Umgebung zeigt Ihre Realität, deshalb zählen interne Benchmarks bei technischen Entscheidungen mehr.