Lasttest vor der Kampagne: So prüfen Sie, ob Ihre Website standhält
Ein Lasttest schickt kontrolliert so viele Anfragen an Ihre Website, wie Sie zur Spitze erwarten, und noch etwas mehr. Er zeigt vor der Kampagne, ab welcher Last Antwortzeiten steigen oder Fehler auftreten, und wo der Engpass sitzt.
Der Herbst bringt die meisten geplanten Spitzen des Jahres: Messen, Radiospots, der Start des Weihnachtsgeschäfts und Newsletter an große Verteiler. Wer einen Shop, ein Buchungssystem oder einen Ticketverkauf betreibt, merkt ohne Test erst am ersten Kampagnentag, ob die Website die Besucher trägt. Ein Lasttest beantwortet die Frage vorher, mit Zahlen statt Hoffnung. Planen Sie dafür einige Wochen vor dem Termin ein, denn auf den ersten Test folgen meist eine Korrektur und ein zweiter Lauf.
Schritt 1 · Anlass
Wann ein Lasttest für Ihre Website nötig ist
Ein Lasttest ist kein Ritual für jede Website. Er ist sinnvoll, wenn eine Spitze absehbar ist und ein Ausfall Geld oder Ansehen kostet:
vor Kampagnen mit Reichweite, etwa Fernsehen, Radio, Newsletter oder bezahlte Anzeigen mit hohem Budget,
vor saisonalen Spitzen wie Messen, Ferienstart, Weihnachtsgeschäft oder Aktionstagen,
nach größeren Umbauten, einem Wechsel des Hostings oder einem Update von CMS oder Framework,
wenn die Website schon bei normaler Last spürbar langsam ist und Sie wissen wollen, wie viel Luft bleibt.
Ein Lasttest misst den Server. Wie schnell eine Seite im Browser auf Klicks reagiert, ist eine eigene Frage, die der Beitrag INP verbessern behandelt.
Schritt 2 · Szenario
Realistische Szenarien festlegen
Der häufigste Fehler beim Lasttest ist eine Zahl ohne Herleitung, etwa „1.000 gleichzeitige Nutzer“. Sinnvoller ist es, vom Anlass auszugehen und rückwärts zu rechnen. Ein Beispiel mit angenommenen Werten:
Ein Newsletter geht an einen Verteiler, aus dem in den ersten 10 Minuten 3.000 Besucher kommen. Das sind 5 neue Besucher pro Sekunde.
Jeder Besucher sieht 4 Seiten in 3 Minuten.
Daraus folgen 20 Seitenaufrufe pro Sekunde. Gleichzeitig auf der Website sind rund 900 Besucher, nämlich 5 pro Sekunde mal 180 Sekunden Verweildauer.
Getestet wird mit dem Zwei- bis Dreifachen, also 40 bis 60 Seitenaufrufen pro Sekunde.
Der Faktor zwei bis drei ist eine Daumenregel, und sie hat einen Grund, die Verteilung: 3.000 Besucher in 10 Minuten sind im Schnitt 5 pro Sekunde, aber sie kommen nicht gleichmäßig. Die meisten öffnen den Newsletter in den ersten Minuten nach dem Versand, in dieser Spitze liegt die Last deutlich über dem Durchschnitt.
Die Rechnung zeigt nebenbei, dass „900 gleichzeitige Besucher“ und „20 Seitenaufrufe pro Sekunde“ dieselbe Last beschreiben. Ein Seitenaufruf ist aber nicht eine Anfrage: Zu jeder Seite gehören Stylesheets, Skripte, Bilder, Schriften und oft einige Aufrufe von Schnittstellen. Aus 20 Seitenaufrufen werden so schnell mehrere hundert Anfragen pro Sekunde. Einen großen Teil davon beantwortet das CDN oder der Browser-Cache, beim Server kommen vor allem die Seiten selbst und die Schnittstellenaufrufe an. Genau diese Anfragen muss der Test nachbilden.
Wichtig ist außerdem der Weg durch die Website. Eine Startseite aus dem Seiten-Cache oder CDN kostet den Server fast nichts. Teuer sind die Wege, die die Anwendung jedes Mal neu rechnen muss: Suche, Filter, Warenkorb, Kasse, Login, Formulare. Ein gutes Szenario mischt beides im erwarteten Verhältnis, zum Beispiel acht von zehn Aufrufen auf Inhaltsseiten und zwei auf Suche und Warenkorb.
Schritt 3 · Durchführung
Werkzeuge und Ablauf
Für Lasttests gibt es ausgereifte Open-Source-Werkzeuge, etwa k6, Apache JMeter und Locust. k6 hat den Vorteil, dass Szenarien als Skript im Projekt liegen und sich bei jeder größeren Änderung wiederholen lassen. Die k6-Dokumentation unterscheidet mehrere Testarten, von denen vor einer Kampagne vier zählen:
Smoke-Test: wenige Nutzer, wenige Minuten. Prüft, ob das Skript und die Wege funktionieren.
Test mit erwarteter Last: Anstieg, Plateau auf der berechneten Last, Abfall. Zeigt, ob der Normalfall der Kampagne trägt.
Spike-Test: ein plötzlicher, sehr hoher Anstieg für wenige Minuten, so wie in der ersten Viertelstunde nach einem Newsletter.
Breakpoint-Test: Die Last steigt schrittweise, bis Fehler auftreten. Zeigt, wo die Grenze liegt.
Vor dem ersten Lauf sind drei Dinge zu klären:
Absprache: Hoster und CDN-Anbieter wissen Bescheid. Ein Lasttest sieht für deren Schutzsysteme aus wie ein Angriff und kann gesperrt werden.
Ziel: Entweder Staging mit gleicher Ausstattung und realistischer Datenmenge oder das Live-System zu einer ruhigen Zeit. Ein Test gegen einen schwächeren Server sagt wenig über den echten aus.
Nebenwirkungen: Zahlungen, Mails und Schnittstellen zu Dritten laufen im Testmodus. Sonst erzeugt der Test echte Bestellungen oder belastet fremde Systeme.
Ein typisches Fehlerbild: Der Test läuft von einem einzigen Rechner und damit von einer IP-Adresse. Nach kurzer Zeit kommen nur noch Fehler 429 oder 403. Gemessen wurde dann die Ratenbegrenzung in Anwendung, Firewall oder CDN, nicht die Leistung der Website. Solche Begrenzungen müssen für die Testquelle gezielt angepasst oder bewusst mitgetestet werden.
Vorlage
Ein k6-Skript als Ausgangspunkt
Das folgende Skript setzt das Szenario von oben um: Es steigert die Last auf 20 Seitenaufrufe pro Sekunde, hält sie zehn Minuten, geht für fünf Minuten auf das Dreifache und gilt als gescheitert, wenn mehr als 1 Prozent der Anfragen fehlschlagen oder das 95. Perzentil der Antwortzeit über 800 Millisekunden liegt. Die Grenzwerte und Adressen sind Annahmen, die Sie an Ihre Website anpassen. Ein Aufruf mit http.get lädt nur das HTML der Seite, nicht Bilder und Skripte. Das passt, solange diese aus einem CDN kommen. Liegen sie auf demselben Server, gehören sie mit ins Skript.
import http from 'k6/http';
import { check } from 'k6';
const BASE = 'https://staging.example.de';
export const options = {
scenarios: {
campaign: {
executor: 'ramping-arrival-rate',
startRate: 2,
timeUnit: '1s',
preAllocatedVUs: 100,
maxVUs: 600,
stages: [
{ target: 20, duration: '5m' }, // ramp up to expected load
{ target: 20, duration: '10m' }, // hold expected load
{ target: 60, duration: '5m' }, // three times the expected load
{ target: 0, duration: '2m' }, // ramp down
],
},
},
thresholds: {
http_req_failed: ['rate<0.01'],
http_req_duration: ['p(95)<800'],
},
};
export default function () {
// 8 of 10 requests hit content pages, 2 hit search
const path = Math.random() < 0.8 ? '/' : '/suche?q=winterjacke';
const res = http.get(BASE + path);
check(res, { 'status is 200': (r) => r.status === 200 });
}
Schritt 4 · Auswertung
Ergebnisse lesen und Engpässe beheben
Ein Lasttest liefert drei Werte, die zusammen gelesen werden: Antwortzeit, Fehlerquote und Durchsatz. Bei der Antwortzeit zählt nicht der Durchschnitt, sondern das 95. Perzentil, also die Zeit, unter der 95 von 100 Anfragen bleiben. Ein Durchschnitt von 300 Millisekunden kann ein Perzentil von 4 Sekunden verdecken. In k6 lassen sich Grenzwerte dafür festlegen, sodass ein Test automatisch als gescheitert gilt, wenn sie überschritten werden.
Während des Tests gehören die Messwerte des Servers daneben: Prozessorlast, Arbeitsspeicher, Datenbankverbindungen, Länge der Warteschlangen. Erst der Vergleich zeigt, welcher Teil zuerst an seine Grenze kommt. Grüne Übersichtsanzeigen allein reichen dafür nicht, wie der Beitrag Monitoring-Mythen zeigt.
Häufige Engpässe in PHP-Anwendungen und wie sie sich zeigen:
PHP-Prozesse aufgebraucht: Die Antwortzeiten springen ab einer bestimmten Last nach oben, obwohl der Prozessor noch Luft hat. Dann sind meist alle PHP-FPM-Prozesse belegt, die Einstellung pm.max_children begrenzt ihre Zahl, und neue Anfragen warten. Die Lösung ist eine passende Einstellung zum verfügbaren Arbeitsspeicher, nicht blind ein größerer Wert.
Datenbank: Einzelne Abfragen werden unter Last langsam, oft fehlende Indizes oder viele kleine Abfragen pro Seite.
Fehlender Cache: Seiten, die sich selten ändern, werden bei jedem Aufruf neu gerechnet.
Synchrone Arbeit: Mailversand, PDF-Erzeugung oder Aufrufe externer Dienste passieren während der Anfrage statt in einer Warteschlange.
Nach jeder Korrektur folgt derselbe Test noch einmal, damit der Effekt messbar ist. Oft reichen Cache, Warteschlange und ein größerer Server, Wege dazu beschreibt die Seite zur Skalierung. Eine aufwendige Cluster-Architektur braucht es für eine Kampagnenspitze selten, wie der Beitrag Mit Kanonen auf Spatzen begründet.
Vor der Spitze testen
Nennen Sie uns Termin und Reichweite Ihrer Kampagne. Wir leiten die Last her, testen auf Staging und beheben Engpässe, solange noch Zeit für einen zweiten Lauf ist.
Nachweise
Quellen und Stand
Stand: 07.09.2026. Testarten, Szenarien und Grenzwerte laut k6-Dokumentation, PHP-FPM-Konfiguration laut php.net. Alle Zahlen im Szenario und im Skript sind Annahmen.
Später erschienen: Wie sich ein Onlineshop auf den Black Friday vorbereitet, beschreibt der Beitrag Black Friday: So bereiten Sie Ihren Onlineshop technisch vor.
Artikel teilen