Checkliste für Best Practices beim Lasttest

# Load Testing aus der Sicht eines performance-orientierten Zuverlässigkeitsingenieurs - Beginne jeden Lasttest mit einem schriftlichen Ziel, wie z.B. p95-Latenz unter 300 ms bei 500 Anfragen pro Sekunde, nicht mit einem vagen "sehen, was kaputt geht". - Schreibe Lasttests als Code mit k6, Gatling oder Locust und halte sie im selben Repository wie den Dienst. - Modelliere realistischen Verkehr aus Produktionslogs: die Mischung der Endpunkte, Payload-Größen und Denkzeit zwischen Anfragen. - Verwende ein offenes Arbeitslastmodell mit einer festen Ankunftsrate, wenn du Dienste testest, die dem Internet ausgesetzt sind, da geschlossene Modelle Warteschlangenverzögerungen verbergen. - Führe separate Testtypen gezielt aus: Smoke, Last bei erwartetem Peak, Stress über den Peak hinaus, Spike und einen langen Soak-Test für Speicherlecks. - Berichte Latenz als Perzentile, mindestens p50, p95 und p99, und verlasse dich niemals nur auf den Durchschnitt. - Definiere Bestehen- oder Scheitern-Schwellenwerte im Testskript, damit CI den Build automatisch fehlschlagen lassen kann. - Führe Lasttests gegen eine produktionsähnliche Umgebung mit denselben Instanzgrößen, Datenvolumen und Konfiguration durch. - Seed Testdaten, die der Produktionskardinalität entsprechen, denn eine winzige Datenbank lässt jede Abfrage schnell aussehen. - Wärme Caches und Verbindungspools vor der Messung auf und schließe die Aufwärmphase von den Ergebnissen aus. - Erzeuge Last von Maschinen mit ausreichend CPU- und Netzwerkreserven und beobachte die eigenen Metriken des Lastgenerators. - Korreliere Testergebnisse mit serverseitigen Metriken, Traces und Logs, um den echten Engpass zu finden, statt zu raten. - Verfolge Fehlerrate und Timeouts neben der Latenz; eine schnelle Antwort, die einen Fehler zurückgibt, ist kein Erfolg. - Ändere eine Variable pro Lauf und zeichne den Commit, die Konfiguration und die Umgebung mit jedem Ergebnis auf. - Führe bei jedem Merge auf main einen kurzen Performance-Smoke-Test durch und die vollständige Suite vor größeren Releases. - Vergleiche Ergebnisse mit einer gespeicherten Baseline und markiere Regressionen, die größer als ein vereinbarter Prozentsatz sind. - Mocke oder sandboxe APIs von Drittanbietern, die pro Aufruf abrechnen oder Ratenlimits durchsetzen, aber teste deine eigenen Abhängigkeiten real. - Finde den Bruchpunkt und dokumentiere, wie das System ausfällt: Graceful Rejection mit 429 oder 503 ist besser als Zusammenbruch. - Verifiziere, dass Autoscaling rechtzeitig reagiert, indem du die Last allmählich erhöhst und misst, wie lange neue Kapazität braucht, um zu helfen. - Kündige Lasttests dem Team und den Bereitschaftsingenieuren an und richte sie niemals ohne Genehmigung auf gemeinsame Produktionssysteme. - Verwandle Erkenntnisse in Kapazitätspläne mit klaren Headroom-Zielen, wie z.B. bei nicht mehr als 60 Prozent des getesteten Limits zu laufen.