Hilfe
Alles, was du brauchst, um lasttester zu benutzen.
🚀 Quickstart: dein erster Test in 5 Minuten
-
Hetzner-Token hinterlegen — Einstellungen → API-Token einfügen → speichern.
Wird gebraucht, damit lasttester Worker-Server fĂĽr dich erstellen kann.
-
Worker provisionieren — Workers → "Provision from Hetzner" → "Create" klicken.
Dauert ~90 Sek. Der Worker erscheint dann grĂĽn in der Liste.
-
Szenario mit dem Wizard erstellen — Wizard starten.
Schritt-für-Schritt Fragen, keine Vorkenntnisse nötig.
- Lauf starten — am Ende des Wizards auf "Erstellen & starten" klicken.
- Ergebnis ansehen — live im Browser. Nach dem Lauf bleibt alles in der Läufe-Liste.
- Worker wieder abstoßen — wenn du fertig bist: Workers → Delete. Die VM wird bei Hetzner gelöscht, die Kosten hören auf.
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?
| Typ | Wann nehmen | Runner |
|---|---|---|
| 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?
| Ziel | Empfohlener Typ | Anzahl | Grob-Kosten |
|---|---|---|---|
| Schnell ausprobieren | CX22 (2 vCPU, 4 GB) | 1 | ~0,006 €/h |
| 1.000 HTTP-Nutzer (RPS) | CPX22 (2 vCPU AMD) | 1 | ~0,013 €/h |
| 10.000 HTTP-Nutzer | CPX22 | 2–3 | ~0,03–0,04 €/h |
| 5.000 HLS-Viewer (3 Mbit/s) | CPX32 | 3–5 | ~0,07–0,11 €/h |
| 100 echte Browser | CPX32 | 5 | ~0,11 €/h |
| 1.000 echte Browser | CPX42 | ~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
sudo journalctl -u lasttester-agent -n 50.
sudo lasttester-controller workers:purge --confirm.
sudo tail -f /var/log/lasttester-autoupdate.log. Pausieren: sudo touch /etc/lasttester/autoupdate.disabled.
sudo lasttester-controller admin:create-user --email=x@beispiel.de --role=admin --password=GEHEIM.
Was bedeuten die Live-Metriken?
| Metrik | Bedeutung |
|---|---|
| RPS | Requests pro Sekunde, die die Worker ans Ziel senden. |
| p95 Latenz | 95 % der Antworten sind schneller als dieser Wert. Wenn der hochgeht, hat dein Server Probleme. |
| HLS Stalls | Wie oft ein Segment nicht rechtzeitig geladen wurde = Buffering fĂĽr echte Zuschauer. |
| HLS Bitrate | Effektiver Durchsatz pro Viewer. Sollte nah an der nominalen Stream-Bitrate bleiben. |
| Worker CPU/RAM | Wenn die >80 % gehen, ist nicht dein Server am Limit — sondern der Worker. Mehr Worker provisionieren. |
WeiterfĂĽhrende Links
- k6 Dokumentation — für Custom-Scripts
- Playwright Docs — Browser-Automation
- Hetzner Cloud Console — hier Token generieren
- MetricsQL — für Custom-Dashboard-Queries