Lasttest durchführen: eine Schritt-für-Schritt-Anleitung

Für einen Lasttest legen Sie fest, wie ein gutes Ergebnis aussieht, skripten eine realistische Nutzerreise, prüfen das Skript mit einem einzelnen Nutzer und steigern dann die Last in Stufen, während Sie Antwortzeiten und Fehler beobachten. Vergleichen Sie das Gemessene mit dem Ziel vom Anfang und ändern Sie vor dem nächsten Lauf immer nur eine Sache.

Was sollten Sie vor einem Lasttest festlegen?

Legen Sie fest, für welche Last Sie testen und welches Ergebnis als bestanden gilt. Ohne beides liefert ein Lasttest Zahlen, aber keine Antwort.

Gehen Sie von echtem Traffic aus, wenn Sie welchen haben. Analytics oder Zugriffslogs zeigen die stärkste Stunde, wie viele Anfragen pro Sekunde ankommen und welche Seiten oder Endpunkte den Großteil davon abbekommen. Setzen Sie das Ziel über diese Spitze, denn es geht darum zu wissen, dass Sie Reserve haben. Schreiben Sie dann die Kriterien als Zahlen auf, zum Beispiel: Das 95. Perzentil der Antwortzeit bleibt unter 500 ms und weniger als 1 % der Anfragen schlagen fehl, bei 200 virtuellen Benutzern.

Zwei praktische Entscheidungen gehören ebenfalls hierher. Wählen Sie eine Umgebung, die der Produktion in Größe und Konfiguration ähnelt, denn ein Staging-Server mit einem Viertel der Kapazität sagt wenig über die Produktion. Und stellen Sie sicher, dass Sie sie testen dürfen: Ein Lasttest gegen ein System, das Ihnen nicht gehört oder das Sie mit anderen Teams teilen, sieht ohne Vorwarnung genau wie ein Angriff aus.

Wie skriptet man eine realistische Nutzerreise?

Skripten Sie den Pfad, der für das Geschäft am wichtigsten ist, Schritt für Schritt und mit Pausen dort, wo ein echter Mensch lesen oder tippen würde. Ein Skript, das eine einzige URL so schnell wie möglich aufruft, misst zwar etwas, aber selten das, worauf es ankommt.

Bei einem Shop könnte das so aussehen: Startseite öffnen, suchen, ein Produkt öffnen, in den Warenkorb legen. Bei einer API: anmelden, Einträge auflisten, einen Eintrag abrufen. Bauen Sie zwischen den Schritten eine kurze Pause ein (Think Time), verwenden Sie wechselnde Testdaten, damit sich Caches wie im echten Betrieb verhalten, und prüfen Sie jede Antwort, damit eine Fehlerseite nicht als schnelle Antwort durchgeht.

Hier ist das Skript, das wir für den Beispiellauf in dieser Anleitung verwendet haben, geschrieben für k6. Es fährt auf 10 virtuelle Benutzer hoch, hält die Last und fährt wieder herunter, mit zwei eingebauten Kriterien:

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

export const options = {
  stages: [
    { duration: "10s", target: 10 },
    { duration: "20s", target: 10 },
    { duration: "5s", target: 0 },
  ],
  thresholds: {
    http_req_duration: ["p(95)<500"],
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  const res = http.get("http://127.0.0.1:8765/");
  check(res, { "status is 200": (r) => r.status === 200 });
  sleep(1);
}

Eine echte Nutzerreise hat mehrere Anfragen und echte URLs. Diese bleibt bewusst winzig, damit die Schritte leicht nachzuvollziehen sind.

Warum zuerst ein Smoke-Test mit einem Nutzer?

Ein Smoke-Test mit einem virtuellen Benutzer beweist, dass das Skript funktioniert, bevor Sie irgendetwas unter echte Last setzen. Er ist der billigste Weg, eine falsche URL, ein fehlendes Login-Token oder eine Prüfung zu finden, die immer fehlschlägt.

In k6 können Sie die Last über die Kommandozeile überschreiben, sodass dasselbe Skript einmal mit einem einzigen Benutzer läuft:

k6 run --vus 1 --iterations 1 script.js

Bei unserem Lauf bestand die eine Prüfung, das Skript war also bereit für Last. Wenn hier eine Prüfung fehlschlägt, reparieren Sie zuerst das Skript: Fehler bei einem Nutzer werden bei hundert zu Rauschen.

Wie sollte man die Last steigern?

Erhöhen Sie die Last in Stufen und halten Sie jede Stufe lange genug, damit sie sich einpendelt, statt direkt auf das Ziel zu springen. Eine stufenweise Rampe zeigt Ihnen, ab welcher Last es schlechter wird.

Eine übliche Form: auf eine erste Stufe hochfahren, einige Minuten halten, auf die nächste Stufe hochfahren, wieder halten und so weiter bis zum Ziel, dann herunterfahren. Wenn Sie jede Haltephase einzeln betrachten, sehen Sie, ob die Antwortzeiten gleichmäßig mit der Last steigen oder erst flach bleiben und dann springen. Dieser Sprung, der Punkt, an dem jeder zusätzliche Nutzer jede Anfrage langsamer macht, ist das Nützlichste, was ein Lasttest finden kann. Unser Beispiel fährt nur auf 10 Benutzer hoch und hält 20 Sekunden, genug, um die Stufen zu zeigen, aber viel zu kurz für einen echten Test.

Was sollten Sie während des Tests beobachten?

Beobachten Sie die Perzentile der Antwortzeit, die Fehlerrate und den Durchsatz auf Seiten des Lastgenerators sowie CPU, Speicher und Datenbanklast auf dem getesteten System. Die ersten drei sagen Ihnen, wie es sich für Nutzer anfühlen würde, die letzten drei, warum.

Vereinbaren Sie vor dem Start Abbruchbedingungen, zum Beispiel: abbrechen, wenn die Fehlerrate 5 % übersteigt oder die Antwortzeiten mehrere Sekunden erreichen. Ein System weiter zu belasten, das bereits umgefallen ist, bringt keine Erkenntnis, und in einer geteilten Umgebung stört es die Arbeit anderer.

Beobachten Sie auch den Lastgenerator. Wenn er bei voller CPU-Auslastung läuft, können die langsamen Antworten von Ihrem eigenen Laptop kommen statt vom Server.

Wie liest man die Ergebnisse eines Lasttests?

Lesen Sie die Perzentile und die Fehlerrate gegen die Kriterien, die Sie zu Beginn aufgeschrieben haben. Die durchschnittliche Antwortzeit ist die am wenigsten nützliche Zahl im Bericht.

Das hat unser Beispiellauf gemeldet (35 Sekunden, bis zu 10 virtuelle Benutzer, eine kleine statische Seite auf einem Laptop, ausgeführt am 8. Oktober 2026):

Die Zahlen sind winzig, weil das Ziel eine statische Datei auf demselben Rechner war, sie taugen also nicht als Benchmark. Die Lehre steckt in der Form: Der Durchschnitt lag über dem 90. Perzentil, weil eine Handvoll langsamer Anfragen ihn nach oben gezogen hat. Perzentile beschreiben, was die meisten Anfragen erlebt haben, und das 99. Perzentil und die langsamste Anfrage zeigen den Ausläufer, den einige wenige Nutzer treffen. Bewerten Sie den Lauf am Perzentil aus Ihren Kriterien und nutzen Sie den Ausläufer, um zu entscheiden, ob etwas genauer angeschaut werden muss.

Wenn ein Lauf sein Ziel verfehlt, ändern Sie eine Sache (eine Abfrage, eine Cache-Einstellung, eine Instanzgröße) und führen Sie denselben Test erneut aus, damit Sie wissen, was den Unterschied gemacht hat.

Wann sollte der Test aus der Cloud laufen?

Verlegen Sie den Lastgenerator in die Cloud, wenn ein Rechner die nötige Last nicht erzeugen kann oder wenn es darauf ankommt, wo Ihre Nutzer sind. Ein Laptop im Büro-WLAN misst Ihre Büroverbindung genauso wie Ihren Server.

Dasselbe k6-Skript kann auf Infrastruktur laufen, die Sie selbst betreiben, auf dem gehosteten Dienst von Grafana oder bei LoadFocus, das k6-Skripte aus 25 Cloud-Regionen ausführt. Die Berichte dort schlüsseln Ergebnisse nach Standort auf und zeigen die Antwortzeit im Verhältnis zur Zahl der virtuellen Benutzer, und genau dort wird der oben beschriebene Sprung sichtbar (Ergebnisse in LoadFocus lesen).

FAQ

Wie lange sollte ein Lasttest laufen? Lange genug, um die Ziellast nach dem Hochfahren mehrere Minuten zu halten, damit kurze Spitzen nicht über das Ergebnis entscheiden. Mindestens 10 Minuten Haltezeit sind ein vernünftiger Start, deutlich länger, wenn Sie nach Speicherlecks oder schleichender Verschlechterung suchen.

Wie viele virtuelle Benutzer brauche ich? Leiten Sie es aus echtem Traffic ab. Nehmen Sie die Anfragen pro Sekunde der stärksten Stunde, schätzen Sie, wie viele Anfragen eine Nutzerreise macht und wie lange sie dauert, und bemessen Sie die virtuellen Benutzer so, dass der Test diese Rate plus etwas Reserve erzeugt.

Ist es sicher, die Produktion zu testen? Das kann es sein, mit Vorsicht: zu einer ruhigen Zeit testen, die Verantwortlichen informieren, Abbruchbedingungen festlegen und deutlich unter der erwarteten Spitze beginnen. Viele Teams bevorzugen eine Staging-Umgebung in Produktionsgröße, damit ein fehlgeschlagener Test keine Kunden treffen kann.

Weiterlesen

• Pass/Fail-Kriterien für Lasttests: so legen Sie sie fest
• Lasttests in GitHub Actions: ein praktischer Leitfaden

Die technischen Aussagen in diesem Artikel wurden nicht unabhängig geprüft.