Accounts 
Lasttest einer Website vor dem Start
Ein Lasttest beantwortet die Frage, wie viele Besucher eine Website auf dem gewählten Server verkraftet und was zuerst versagt. Sie führen ihn auf Ihrem eigenen Server durch und nur dort: Der Lastgenerator läuft auf einer separaten Maschine, der Hoster ist informiert, und externe Dienste sind durch Platzhalter ersetzt. Hier lesen Sie, auf welche Zahlen es ankommt, mit welchen Programmen Sie sie erheben und wie Sie danach den Tarif wählen.
Eine Website, die beim Entwickler schnell lädt, kann aufhören zu antworten, sobald hundert Menschen gleichzeitig kommen: Dann gehen die PHP-Prozesse, die Datenbankverbindungen oder der Arbeitsspeicher aus. Das am Tag einer Werbekampagne zu erfahren, kostet mehr als eine Woche davor. Ein Lasttest bildet den Besucherstrom auf Ihrem Server nach und zeigt, wo die Grenze liegt und wie viel Abstand bis dorthin bleibt.
Was Sie messen
Das Ergebnis eines Tests ist keine einzelne Zahl, sondern ein Bündel von Kennzahlen, die Sie gemeinsam betrachten:
- RPS (Anfragen pro Sekunde) gibt an, wie viele Anfragen der Server verarbeitet. Für sich allein sagt RPS wenig: Ein Server kann tausend Anfragen pro Sekunde beantworten, und trotzdem braucht jede Antwort fünf Sekunden.
- Antwortzeit nach Perzentilen. p95 bedeutet, dass 95 % der Anfragen innerhalb dieser Zeit beantwortet wurden, p99 entsprechend 99 %. Der Mittelwert verdeckt langsame Antworten: Laufen 90 Anfragen in 100 ms durch und 10 in 3 Sekunden, wirkt ein Mittelwert von etwa 400 ms ordentlich, obwohl jeder zehnte Besucher drei Sekunden wartet.
- Fehlerquote: 5xx-Antworten, Verbindungsabbrüche und Timeouts. Unter Last treten Fehler meist früher auf, als die Antwortzeit spürbar steigt.
- Serverressourcen: CPU-Auslastung, freier Arbeitsspeicher und Swap, Wartezeit auf die Festplatte (iowait), Zahl der Datenbankverbindungen. Diese Werte erfassen Sie während des Tests auf dem Server selbst, sonst bleibt unklar, woran die Website gescheitert ist.
Das Ziel legen Sie vorher fest, und zwar in denselben Einheiten, zum Beispiel: „Bei 50 Anfragen pro Sekunde liegt p95 für Startseite und Katalog unter 500 ms, die Fehlerquote unter 1 %.“ Ohne Ziel wird der Test zu einer Sammlung von Diagrammen, aus denen sich keine Entscheidung ableiten lässt.
Welche Testarten es gibt
- Smoke-Test: einige virtuelle Nutzer über eine Minute. Er prüft, ob das Szenario richtig geschrieben ist, und liefert die Basis-Antwortzeit ohne Last.
- Lasttest: der erwartete Spitzenandrang über 15–30 Minuten. Er zeigt, ob der Server die geplante Last bewältigt.
- Stresstest: Die Last wird stufenweise erhöht, bis die Fehler oder die Antwortzeit steigen. Er zeigt die Grenze und wie sich die Website jenseits davon verhält: ob sie schnell einen Fehler liefert oder hängen bleibt.
- Dauertest: moderate Last über mehrere Stunden. Er findet Speicherlecks, volllaufende Logs und Festplatten sowie sich anhäufende Verbindungen.
Das Szenario sollte echten Besuchern ähneln: eine Mischung aus Seiten (Startseite, Katalog, Produktseite, Suche), Pausen zwischen den Aktionen und ein Teil der Nutzer mit Anmeldung oder Warenkorb. Ein Test, der tausendmal pro Sekunde dieselbe gecachte Seite abruft, misst den Cache, nicht die Website.
Werkzeuge
Alle vier Programme sind kostenlos und laufen auf der Kommandozeile. Für Szenarien mit mehreren Seiten eignen sich die ersten beiden, für eine schnelle Prüfung einer einzelnen Adresse die letzten beiden.
- k6: Szenarien schreiben Sie in JavaScript, das Ergebnis erscheint sofort mit Perzentilen. Im Szenario legen Sie Schwellenwerte fest: Laut Dokumentation von k6 werden Bedingungen wie
http_req_failed: ['rate<0.01']undhttp_req_duration: ['p(95)<200']am Ende des Tests geprüft, und bei einer Verletzung beendet sich k6 mit einem Exit-Code ungleich null. Deshalb lässt sich k6 gut in CI einbinden: Ein Build, nach dem die Website langsamer geworden ist, kommt nicht durch. - Apache JMeter: Szenarien werden in einer grafischen Oberfläche zusammengestellt, mit Formularen, Anmeldung, Auswertung von Antworten und Daten aus CSV-Dateien. Den Test selbst sollten Sie im Kommandozeilenmodus starten, mit
jmeter -n -t test.jmx -l test.jtl: Der grafische Modus verbraucht Ressourcen des Generators und verfälscht das Ergebnis. - wrk ist ein Lastgenerator mit mehreren Threads, der von einer einzigen Maschine aus hohe Last auf eine Adresse erzeugt. Beispiel:
wrk -t4 -c100 -d60s --latency https://example.com/bedeutet 4 Threads, 100 Verbindungen, eine Minute, mit Verteilung der Latenzen. Komplexere Szenarien schreiben Sie in Lua. - ab (ApacheBench) ist die einfachste Variante und oft schon zusammen mit Apache installiert. In der Dokumentation steht ausdrücklich, dass ab HTTP/1.x nicht vollständig implementiert und bei hoher Last womöglich die eigene Geschwindigkeit misst statt die des Servers. Keep-Alive ist standardmäßig aus, Sie schalten es mit
-kein. Für eine schnelle Prüfung reicht das, für eine Tarifentscheidung nicht.
Testen, ohne andere zu stören
Ein Lasttest erzeugt denselben Anfragestrom wie ein Besucheransturm. Durchführen dürfen Sie ihn deshalb nur auf einem Server, den Sie selbst verwalten, und unter Beachtung der Regeln der Plattform, auf der er läuft.
- Nur der eigene Server und die eigene Domain. Last auf fremde Websites und APIs ohne schriftliche Zustimmung des Inhabers ist unzulässig, auch „nur für eine Minute“. Greift Ihre Website auf ein Zahlungsgateway, einen Versanddienst oder eine externe API zu, ersetzen Sie diese für die Dauer des Tests durch Platzhalter oder durch die Testumgebungen dieser Dienste.
- Informieren Sie den Hoster. Der DDoS-Schutz des Anbieters kann den Test für einen Angriff halten und die Adresse des Generators sperren, und die Regeln mancher Hoster verlangen, solche Prüfungen abzustimmen. So erlaubt die Richtlinie von AWS Stresstests eigener, dafür vorbereiteter Dienste, untersagt aber die Simulation von DDoS-Angriffen. Eine kurze Nachricht an den Support mit Datum, Uhrzeit, Adressen und erwartetem Volumen klärt die Frage. Wie der Schutz bei Hostern aufgebaut ist, erklärt der Artikel DDoS-Schutz: was Hoster tatsächlich bieten.
- Nicht auf Shared Hosting. Auf einem geteilten Server bremst der Test die Nachbarn, und das Ergebnis hängt von ihnen ab. Getestet wird auf einem VPS oder dedizierten Server, dessen Ressourcen Ihnen fest zugeteilt sind.
- Der Generator läuft auf einer separaten Maschine. Starten Sie ihn auf demselben Server, nimmt er der Website CPU-Zeit weg. Für den Generator eignet sich ein VPS mit stündlicher Abrechnung: Sie legen ihn für die Dauer des Tests an und löschen ihn danach. Laut dem Katalog von accsly.io, Stand November 2026, ist stündliche Abrechnung bei 173 von 2.247 VPS-Hostern ausdrücklich angegeben, die Tarife finden Sie auf der Seite VPS mit stündlicher Abrechnung.
- Denken Sie an den Traffic. Eine Stunde Test kann Hunderte Gigabyte übertragen. Ist der Traffic im Tarif begrenzt oder teilen Sie die Anbindung mit Nachbarn, wird die Überschreitung berechnet oder die Geschwindigkeit gedrosselt. Mehr dazu im Artikel Bandbreite und Traffic: was 1 Gbit/s und „unbegrenzt“ bedeuten.
- CDN und Schutzdienste vor der Website. Ist die Domain an ein CDN angebunden, prüft ein Test darüber das CDN und kann an dessen Limits stoßen. Den Ursprungsserver testen Sie direkt über seine Adresse, Last über das CDN stimmen Sie mit dem CDN-Anbieter ab.
Ergebnisse lesen und den Tarif wählen
Bei stufenweise steigender Last wächst RPS zunächst mit, während sich die Antwortzeit kaum ändert. Dann kommt der Sättigungspunkt: RPS wächst nicht mehr, p95 steigt sprunghaft, und Fehler treten auf. Die Betriebslast sollte deutlich unter diesem Punkt bleiben, denn Reserve brauchen Sie für Spitzen, Hintergrundaufgaben und wachsendes Publikum. Ein praktischer Richtwert: Die erwartete Spitze sollte nicht mehr als die Hälfte der gefundenen Grenze ausmachen.
Danach sehen Sie nach, woran der Server am Sättigungspunkt gescheitert ist:
- Die CPU ist zu 100 % ausgelastet: Sie brauchen mehr Kerne oder eine höhere Taktfrequenz, wenn der Engpass in einem einzelnen Thread liegt; Tarife ab 4 GHz finden Sie auf der Seite VPS mit hoher CPU-Taktfrequenz.
- Der Arbeitsspeicher ist erschöpft, und der Server lagert in den Swap aus: Sie brauchen mehr Speicher oder weniger PHP-FPM-Prozesse und Worker; Richtwerte zur Größe nennt der Artikel Wie viel Arbeitsspeicher und wie viele Kerne braucht eine Website?
- Hoher iowait: Die Festplatte kommt nicht hinterher, meist wegen der Datenbank; hier helfen NVMe und Indizes, einen Vergleich bietet der Artikel NVMe oder SSD: Gibt es einen Unterschied für die Website?
- Die Ressourcen sind frei, trotzdem gibt es Fehler: Dann ist eine Einstellung das Limit, etwa die maximale Zahl der Datenbankverbindungen, die Zahl der Worker des Webservers oder der offenen Dateien.
Vor dem Kauf lohnt es sich, den Test auf genau dem Tarif zu wiederholen, den Sie nehmen wollen: Prozessoren und Festplatten unterscheiden sich zwischen Hostern stärker als die Zahlen in der Beschreibung. Am bequemsten geht das mit stündlicher Abrechnung oder in einer Testphase, wie im Artikel Ping und Geschwindigkeit eines VPS vor der Bezahlung prüfen beschrieben. Nach dem Start übernehmen Sie dieselben Kennzahlen, also Antwortzeit, Fehler und Ressourcenauslastung, in das Monitoring, damit wachsende Last sichtbar wird, bevor die Website mit Fehlern antwortet.