Hilfe

Alles, was du brauchst, um lasttester zu benutzen.

🚀 Quickstart: dein erster Test in 5 Minuten

  1. Hetzner-Token hinterlegen — Einstellungen → API-Token einfügen → speichern.
    Wird gebraucht, damit lasttester Worker-Server fĂĽr dich erstellen kann.
  2. Worker provisionieren — Workers → "Provision from Hetzner" → "Create" klicken.
    Dauert ~90 Sek. Der Worker erscheint dann grĂĽn in der Liste.
  3. Szenario mit dem Wizard erstellen — Wizard starten.
    Schritt-für-Schritt Fragen, keine Vorkenntnisse nötig.
  4. Lauf starten — am Ende des Wizards auf "Erstellen & starten" klicken.
  5. Ergebnis ansehen — live im Browser. Nach dem Lauf bleibt alles in der Läufe-Liste.
  6. Worker wieder abstoßen — wenn du fertig bist: Workers → Delete. Die VM wird bei Hetzner gelöscht, die Kosten hören auf.
Jetzt Wizard starten →

Wie lasttester funktioniert

lasttester besteht aus zwei Teilen:

  • Controller (dieser Server): stellt die Weboberfläche bereit, speichert Szenarien und Läufe, orchestriert die Tests.
  • Worker (Hetzner-VMs, die du bei Bedarf anlegst): fĂĽhren die eigentlichen Last-Tests aus. Jede Sekunde Last = 1 Sekunde Worker-Laufzeit = Geld. AbstoĂźen, wenn nicht in Benutzung.

Ein Szenario ist eine gespeicherte Test-Definition (z. B. "100 Nutzer laden https://example.com 60 Sekunden lang"). Ein Lauf ist die Ausführung eines Szenarios zu einem bestimmten Zeitpunkt. Läufe kann man später vergleichen.

Welcher Szenario-Typ passt?

TypWann nehmenRunner
HTTP Klassische Last auf Webseiten, APIs, PHP-Apps. Du gibst RPS (Requests pro Sekunde) und Dauer an. k6
HLS Streaming-Test. Gib die .m3u8-URL an, die Anzahl simulierter Zuschauer, Dauer. Segmente werden tatsächlich runtergeladen — damit belastest du Origin/CDN realistisch. k6
WebSocket Chat/Live-Streams. Wie viele Clients, wie viele Nachrichten pro Sekunde pro Client. k6
Browser Landing Echte Chrome-Browser laden die Seite und warten. FĂĽr "sieht die Seite ĂĽberhaupt noch gut aus unter Last?"-Tests. Playwright
Browser Player Echter Chrome lädt die Player-Seite, klickt den Play-Button, guckt X Sekunden. Realistischster Stream-Test, aber teuer (max. 20 Browser pro Worker). Playwright

Faustregel: Protokoll-Tests (HTTP/HLS/WS) für die große Last (10.000+ virtuelle Nutzer), Browser-Tests nur für Smoke-Checks mit 50–500 Browsern.

Wie viele Worker brauche ich?

ZielEmpfohlener TypAnzahlGrob-Kosten
Schnell ausprobierenCX22 (2 vCPU, 4 GB)1~0,006 €/h
1.000 HTTP-Nutzer (RPS)CPX22 (2 vCPU AMD)1~0,013 €/h
10.000 HTTP-NutzerCPX222–3~0,03–0,04 €/h
5.000 HLS-Viewer (3 Mbit/s)CPX323–5~0,07–0,11 €/h
100 echte BrowserCPX325~0,11 €/h
1.000 echte BrowserCPX42~20~0,82 €/h

Faustregel zur Typ-Familie: CX = billig, älter, reicht für Smoke-Tests. CPX = Allrounder, gute Preisleistung, hier startet man normalerweise. CCX = dedizierte vCPUs, wenn du absolute Stabilität unter Dauerlast brauchst.

Wenn zu wenig Worker da sind: der Lauf meldet "no-online-workers". Einfach mehr provisionieren, dann nochmal starten.

Troubleshooting

Worker erscheint nicht in der Liste
Nach dem "Provision from Hetzner"-Klick dauert das Bootstrap 60–120 Sekunden (apt install, Node, k6, Chromium). Seite kurz refreshen. Wenn der Worker nach 3 Min. immer noch "provisioning" zeigt, in den Logs der Hetzner-VM gucken: sudo journalctl -u lasttester-agent -n 50.
"no-online-workers" beim Starten
Entweder ist kein Worker online, oder der Worker unterstützt den gewählten Runner nicht. k6-Szenarien (HTTP/HLS/WS) und Playwright-Szenarien (Browser) können beide auf demselben Worker laufen, also ist das meistens nur eine Frage der Anzahl.
Kosten im Griff behalten
Oben auf der Workers-Seite siehst du die aktuelle €/h-Rate. Wenn du fertig bist: alle Worker löschen. Oder per CLI: sudo lasttester-controller workers:purge --confirm.
Controller-Updates
Der Controller pullt alle 5 Minuten aus Git. Du pushst — 5 Min. später läuft's. Logs: sudo tail -f /var/log/lasttester-autoupdate.log. Pausieren: sudo touch /etc/lasttester/autoupdate.disabled.
Weiteren User anlegen
Per SSH auf dem Controller: sudo lasttester-controller admin:create-user --email=x@beispiel.de --role=admin --password=GEHEIM.

Was bedeuten die Live-Metriken?

MetrikBedeutung
RPSRequests pro Sekunde, die die Worker ans Ziel senden.
p95 Latenz95 % der Antworten sind schneller als dieser Wert. Wenn der hochgeht, hat dein Server Probleme.
HLS StallsWie oft ein Segment nicht rechtzeitig geladen wurde = Buffering fĂĽr echte Zuschauer.
HLS BitrateEffektiver Durchsatz pro Viewer. Sollte nah an der nominalen Stream-Bitrate bleiben.
Worker CPU/RAMWenn die >80 % gehen, ist nicht dein Server am Limit — sondern der Worker. Mehr Worker provisionieren.

WeiterfĂĽhrende Links