LAST-TESTS VOR DEM MARKTSTART

Die Frage vor dem Start

Eine Plattform geht an den Start, und irgendwann kommt der erste Abend, an dem alle gleichzeitig online sind. Bis dahin gibt es zwei Arten von Antworten auf die Frage, ob das System das aushält: eine Schätzung ‒ oder eine Messung.

Der Unterschied kostet ein paar Tage Arbeit und entscheidet darüber, ob man unter Volllast entspannt bleiben kann oder im schlimmsten Fall Kunden verliert.

Nicht die Durchschnittswerte zählen, sondern die Peaks

Der erste Fehler passiert in der Planung. Prognosen werden in Usern oder Vorgängen pro Monat gerechnet, Systeme brechen aber in der Spitzenstunde zusammen.

Bei einer Bestellplattform konzentriert sich die Nachfrage extrem: Der Sonntagabend zwischen 18 und 19 Uhr trägt ein Vielfaches des Stundendurchschnitts. Die Zahl, gegen die getestet werden muss, ist diese eine Stunde ‒ nicht der Monat, nicht der Tag.

Daraus wird eine zweite Größe abgeleitet, die sich tatsächlich messen lässt: Anfragen pro Sekunde. Und hier steckt die größte Unsicherheit jeder Kapazitätsrechnung, nämlich wie viel Stöbern auf eine Bestellung kommt. Wer das nicht gemessen hat, muss schätzen ‒ und sollte das Ergebnis dann als Spanne angeben statt als scheinbar valide feste Zahl.

Drei Teststufen

• Smoke ‒ bei jeder Änderung, als Teil des automatisierten Workflows

  Wenige Minuten, Grundlast. Prüft, ob der Code überhaupt funktioniert.

• Last ‒ regelmäßig, zum Beispiel am Ende eines Sprints

  Realistische Spitzenlast über eine Stunde. Prüft echte Antwortzeiten und Fehlerraten.

• Stress ‒ manuell, vor großen Terminen

  Bis zum Überschreiten der gesetzten Toleranzen für ein performantes System. Zeigt, wo die Grenze liegt und wie sich das System an diesem Punkt verhält.

Warum lokal gemessene Werte kritisch sind

Last-Tests auf dem Entwicklungsrechner oder im Container erzeugen Zahlen, die keine Aussage haben: geteilte Prozessorkerne, Datenbank daneben statt im Netz, null Millisekunden Latenz, keine automatische Skalierung.

Deshalb laufen bei uns funktionale Prüfungen lokal und Leistungsmessungen ausschließlich auf einer Umgebung, die dem Live-Server entspricht ‒ gleiche Datenbankklasse, gleicher Speicher, gleiche Verbindungsgrenzen. Alles andere misst eine Labor-Situation, nicht das echte Produkt.

Echte Nutzer statt gleichförmiger Anfragen

Ein Last-Test, der eine einzige Schnittstelle in einer Schleife aufruft, prüft diese Schnittstelle. Nicht das System.

Deshalb bilden wir die tatsächliche Verteilung ab. Bei einer Bestellplattform sind das drei Rollen mit sehr unterschiedlichem Verhalten: Kundschaft, die überwiegend lesend auf das System zugreift; Restaurants, die dauerhaft auf neue Bestellungen warten und Statusänderungen sowie Updates an Artikel einpflegen; Fahrer:innen, die nur punktuell schreibend auf das System zugreifen. Jede Rolle hat ein eigenes Profil und einen eigenen Anteil an der Gesamtlast.

Das ist auch der Grund, warum sich Last-Tests nicht einfach fertig kaufen lassen. Die Arbeit steckt nicht im Werkzeug, sondern in der Frage, was echte Nutzer konkret auslösen.

Aussagekräftige Grenzwerte

Ein Testergebnis ohne hinterlegten Grenzwert ist nur eine Zahl in einem Protokoll, das keinen Kontext hat und daher interpretiert werden muss und im Zweifel missverstanden wird. Wir definieren deshalb Schwellwerte, an die Konsequenzen geknüpft sind:

• 95 Prozent der Anfragen unter 300 Millisekunden
• 99 Prozent unter 500 Millisekunden
• Fehlerquote unter einem Prozent

Wird die Schwelle im Smoke-Test gerissen, signalisiert das System dies automatisch. Wird sie nach dem Deployment gerissen, geht eine Meldung an den Entwicklungskanal. Dafür haben wir das Tool k6 gewählt: Die Schwellen sind Teil eines automatisierten Testlaufs innerhalb unserer Publikationsprozesse.

Was ein Last-Test typischerweise findet

Interessant ist selten die reine Kapazitätszahl am Endes, sondern die Erkenntnisse, die auf dem Weg dorthin gewonnen werden.

Ein immer wiederkehrendes Beispiel dafür ist struktureller Natur: Die Anwendung hält eine Datenbankverbindung offen, während sie Arbeit erledigt, für die sie gar keine Datenbank braucht. Unter Last stehen dadurch fast alle Verbindungen im Leerlauf und warten. Nach einer Korrektur ‒ gleiche Hardware, nur eine Code-Anpassung ‒ schrumpft die Reaktionszeit in solchen Fällen gern schonmal um ein Vielfaches.

Solche Funde macht man im Zweifel nicht im Code-Review. Unter Last werden sie evident und können zu einer stetigen Optimierung der Systemperformance führen. So steigern wir die Resilienz von High Demand Apps systematisch. Ohne unliebsame Überraschungen nach dem Go Live.

Reihenfolge schlägt Reflex

Der letzte Punkt gehört in jedes Betriebshandbuch: Wenn es eng wird, ist der Reflex, Anwendungsserver dazuzuschalten. Ist aber die Datenbank der Engpass, macht genau das die Lage schlechter, weil mehr Server mehr Verbindungen beanspruchen.

Deshalb gehört zu einem Last-Test nicht nur das Ergebnis, sondern eine Reihenfolge: Welche Messgröße wird zuerst geprüft, und welcher Hebel folgt daraus.