Was ist Breakpoint Testing?

Was ist Breakpoint Testing?

Breakpoint Testing ist ein Performance-Test, der die Last auf ein System in kontrollierten Schritten immer weiter erhöht, bis es versagt, damit Sie seine Grenze kennen. Das Ergebnis ist eine Zahl, mit der Sie planen können: die Last, bei der Antwortzeit, Fehlerrate oder Durchsatz die von Ihnen definierte Fehlergrenze überschreiten. Man spricht auch von Kapazitäts-, Point-Load- oder Limit-Tests. (Zu CSS-Breakpoints im Responsive Design siehe Mobile-First-Design.)

So läuft ein Breakpoint-Test ab

1. Zuerst das Versagen definieren. Zum Beispiel p95-Antwortzeit über einem festen Wert, Fehlerrate über einem festen Prozentsatz oder ein Durchsatz, der nicht mehr wächst. Ohne diese Definition erkennen Sie die Grenze nicht.
2. Schrittweise steigern. Plötzliche Sprünge machen es schwer zu erkennen, wann und warum das System versagt.
3. Durch die Degradation hindurch weitermachen. Anders als die meisten Testarten stoppt ein Breakpoint-Test nicht, wenn das System langsam wird, sondern erst bei Ihrer Fehlerbedingung.
4. Per Schwellenwert oder von Hand stoppen. In k6 kann ein Threshold mit abortOnFail den Lauf automatisch beenden.
5. Den Engpass finden. CPU, Speicher, ein Datenbank-Connection-Pool oder ein Thread-Pool: Das müssen Sie skalieren oder beheben.

Beispiel

Illustrative Zahlen, kein Benchmark. Eine API hält bei 100 virtuellen Nutzern ein stabiles p95. Sie fügen jede Minute 50 Nutzer hinzu. Bei etwa 400 Nutzern steigt p95 schneller als die Last, bei 550 Nutzern liegt die Fehlerrate über 1 %. Der Breakpoint liegt bei rund 550 Nutzern, und der Knick bei etwa 400 ist die vorsichtigere Planungszahl. Beheben Sie den Engpass, wiederholen Sie dieselbe Rampe und prüfen Sie, ob sich beide Werte verschoben haben.

Breakpoint-Test im Vergleich zu Stress-, Kapazitäts- und Spike-Test

• Der Kapazitätstest sucht die höchste Last, die Ihre Ziele noch erfüllt. Der Breakpoint-Test sucht, wo sie nicht mehr erfüllt werden. Manche Quellen verwenden beide Begriffe für dasselbe.
• Ein Stresstest geht über die erwartete Spitze hinaus, um zu sehen, wie das System ausfällt und sich erholt. Ein Breakpoint-Test misst, wo es ausfällt. Siehe Load Testing vs. Stress Testing (englisch).
• Der Spike-Test legt einen plötzlichen Sprung an. Ein Breakpoint-Test steigt gleichmäßig. Beide bauen auf dem Lasttest auf.

Häufige Fehler

• Autoscaling eingeschaltet lassen. Grafanas k6-Leitfaden warnt, dass elastische Umgebungen weiterwachsen können, bis das Ausgabenlimit Ihres Kontos erreicht ist. Schalten Sie die Elastizität der getesteten Komponenten ab, sonst messen Sie Ihr Budget.
• Zu schnell steigern, was den Knickpunkt verdeckt.
• Keine Fehlerdefinition, sodass der Lauf einfach endet, wenn jemand die Lust verliert.
• Ein überlasteter Lastgenerator. Geht dem Rechner, der die Last erzeugt, zuerst die CPU aus, messen Sie den Generator und nicht das System.
• Ein System testen, das Ihnen nicht gehört oder für das Sie keine Erlaubnis haben. Ein Breakpoint-Test soll etwas zum Brechen bringen: Nutzen Sie eine Staging-Kopie oder ein abgestimmtes Zeitfenster, nie ein geteiltes oder produktives System ohne Freigabe.
• Nur einmal laufen lassen. Wiederholen Sie den Test nach jeder Optimierung, um zu sehen, ob sich die Grenze verschoben hat.

Breakpoint-Tests mit LoadFocus

In JMeter fügt das Plugin Stepping Thread Group Nutzer portionsweise in festen Abständen hinzu. In k6 leistet ein Ramping-Szenario mit mehreren Stufen dasselbe. LoadFocus führt vorhandene JMeter-Skripte und k6-JavaScript-Skripte aus bis zu 25 Cloud-Regionen aus, in bezahlten Tarifen mit bis zu 20.000 gleichzeitigen virtuellen Nutzern pro Test (der kostenlose Tarif ist auf 10 begrenzt, für eine echte Grenzsuche brauchen Sie also einen bezahlten Tarif). Als Schwellenwerte lassen sich maximale P95- und P99-Antwortzeit, maximale Fehlerrate und minimaler Durchsatz setzen, und die Ergebnisse zeigen Fehler und Antwortcodes über der Zahl der virtuellen Nutzer. Aus dieser Kurve lesen Sie den Breakpoint ab. Starten Sie beim LoadFocus-Lasttest. Zur Rampe selbst siehe JMeter Ramp-up-Zeit (englisch).

Häufige Fragen: Breakpoint Testing

Ist Breakpoint Testing dasselbe wie Stresstest?

Sie überschneiden sich. Der Stresstest fragt, wie sich das System jenseits seiner Grenzen verhält und erholt. Breakpoint Testing fragt, wo genau die Grenze liegt.

Woran erkenne ich, wann ich den Test stoppen soll?

Wenn Ihre vorab definierte Fehlerbedingung erfüllt ist, etwa p95 über einem Limit oder eine Fehlerrate über einem Prozentsatz. In k6 kann ein Threshold mit abortOnFail den Lauf für Sie beenden.

Sollte ich ihn in Produktion ausführen?

Nur mit ausdrücklicher Freigabe und einem Plan. Der Test soll Versagen auslösen, daher ist eine Staging-Kopie der Produktion der sicherere Ort.

Wie oft sollte ich ihn wiederholen?

Nach größeren Code- oder Infrastrukturänderungen, bei wachsender Last und nach Optimierungen, um zu sehen, ob sich die Grenze verschoben hat.