Lasttest

Ein Lasttest setzt ein System genau dem Traffic aus, den Sie tatsächlich erwarten, typischerweise der normalen Spitzenlast, und misst, wie es sich verhält: Latenz-Perzentile, Fehlerrate, Durchsatz und Ressourcenverbrauch. Er beantwortet die Frage: „Erreicht das System seine Performanceziele unter der Last, für die wir planen?“ Es geht nicht darum, das System zum Absturz zu bringen; das ist Aufgabe des Stresstests.

Beispiel (k6)

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 }, // ramp up to 100 virtual users
    { duration: '10m', target: 100 }, // hold at expected peak
    { duration: '1m', target: 0 },    // ramp down
  ],
  thresholds: {
    http_req_duration: ['p(95)<500', 'p(99)<1200'],
    http_req_failed: ['rate<0.01'],
  },
};

export default function () {
  const res = http.get('https://staging.example.com/api/products');
  check(res, { 'status is 200': (r) => r.status === 200 });
  sleep(1); // think time between iterations
}

Wird einer der Schwellenwerte (Thresholds) überschritten, beendet sich k6 mit einem Exit-Code ungleich null. Dasselbe Skript kann daher in der CI als Gate dienen.

Last-, Stress-, Soak- und Spike-Test

Typ	Lastprofil	Beantwortete Frage
Last	Erwartete Spitzenlast, konstant gehalten	Erreichen wir unsere Ziele bei normaler Spitzenlast?
Stress	Steigend über das Erwartete hinaus	Wo und wie bricht das System, und erholt es sich wieder?
Soak	Normale Last über Stunden	Verschlechtert es sich mit der Zeit (Speicherlecks, erschöpfte Pools)?
Spike	Plötzlicher Anstieg, dann Abfall	Übersteht es einen Burst und skaliert es wieder zurück?

Worauf es ankommt

• Realen Traffic modellieren. Verwenden Sie die Mischung aus Endpunkten, Payload-Größen und Denkzeiten (Think Times), die Sie in den Produktionsanalysen sehen, statt eine einzige URL in einer Schleife zu bombardieren.
• Eine produktionsähnliche Umgebung nutzen. Ergebnisse von einem unterdimensionierten Staging-Server sagen Ihnen nur etwas über genau diesen Server.
• Nach Perzentilen bewerten, nicht nach Durchschnittswerten. Ein Durchschnitt verdeckt den langsamen Ausläufer, über den sich Nutzer tatsächlich beschweren.
• Auch die Serverseite beobachten. CPU, Arbeitsspeicher, Datenbankverbindungen und Queue-Tiefe erklären, warum sich die Latenz verändert hat.
• Ziele vorher vereinbaren. Ohne ein klar formuliertes Ziel wie „p95 unter 500 ms bei 200 Anfragen pro Sekunde“ liefert ein Lasttest Zahlen, aber kein Urteil.