Wissen / Kapazität vor wichtigen Terminen

Lasttest für Websites: Auf Besucherspitzen vorbereitet sein

Kurz gesagt: Ein Lasttest untersucht, wie eine Website unter einer vereinbarten gleichzeitigen Nutzung reagiert. Dafür werden wichtige Nutzerwege, erwartbare Belastungsmuster und klare Abbruchgrenzen festgelegt. Aussagekräftig sind Ergebnisse nur für die geprüfte Umgebung und das jeweilige Szenario. Sie helfen bei Kapazitätsentscheidungen, ersetzen aber weder einen Sicherheitscheck noch eine Garantie für jeden Besucheransturm.

Veröffentlicht am / Aktualisiert am / Redaktion: Ruhrstack / 8 Minuten Lesezeit

01 / ANLASS

Eine Kampagne verändert nicht nur die Zahl der Seitenaufrufe.

Entscheidend ist, was Menschen während eines wichtigen Termins tatsächlich tun.

Eine Messe startet, ein Newsletter geht heraus oder ein neues Angebot wird veröffentlicht. Das Unternehmen möchte wissen, ob seine Website vorbereitet ist. Die Frage „Wie viele Besucher hält sie aus?“ greift dafür zu kurz. Eine lesbare Informationsseite und eine Suche mit Datenbankabfragen beanspruchen das System unterschiedlich. Auch derselbe Nutzer kann in kurzer Folge mehrere Anfragen auslösen.

Beginnen Sie mit dem geschäftlichen Ablauf. Welche Adresse wird beworben? Lesen Interessenten anschließend nur eine Unterlage oder durchlaufen sie eine mehrstufige Anfrage? Gibt es Dateien, Suchvorgänge oder eine Verbindung zu einem anderen Dienst? Aus diesen Angaben entsteht ein prüfbarer Nutzerweg. Eine pauschale Startseitenprüfung kann eine Schwachstelle auf dem eigentlichen Kampagnenziel übersehen.

Die Architekturhinweise von Microsoft zu Performanceprüfungen ordnen Tests an messbaren Anforderungen und realistischen Szenarien aus. Diese Methodik setzt kein bestimmtes Hostingprodukt voraus. Für ein kleines Unternehmen bedeutet sie vor allem: Das zu schützende Geschäftsziel muss vor dem Test verständlich beschrieben werden.

Ein Lasttest beantwortet dabei eine andere Frage als die Prüfung der wahrgenommenen Websitegeschwindigkeit. Die Darstellung auf dem Endgerät bleibt wichtig. Hier geht es zusätzlich darum, wie sich der gemeinsame Dienst bei gleichzeitiger Beanspruchung verhält. Beide Beobachtungen können zusammengehören, sollten im Ergebnis aber getrennt erkennbar bleiben.

02 / LASTMODELL

Gleichzeitige Nutzer sind keine vorhergesagten echten Besucher.

Das Testmodell übersetzt eine Annahme in eine kontrollierbare Belastung.

Schreiben Sie auf, worauf Ihre Erwartung beruht. Vielleicht liegen Erfahrungswerte einer früheren Aktion vor. Vielleicht ist nur bekannt, dass viele Empfänger ungefähr gleichzeitig einen Link erhalten. Diese Unsicherheit muss sichtbar bleiben. Ein synthetischer Test kann eine Annahme untersuchen; er macht aus einer unklaren Kampagnenplanung keine verlässliche Besucherprognose.

Die Microsoft-Dokumentation zu Lasttestbegriffen unterscheidet unter anderem virtuelle Nutzer, Anfrageraten und Antwortzeiten. Diese Größen sind nicht austauschbar. Ein virtueller Nutzer kann Pausen einlegen oder mehrere Anfragen ausführen. Eine serverseitig gemessene Antwortzeit beschreibt wiederum nicht automatisch die vollständige Darstellung im Browser.

Vereinbaren Sie deshalb Belastung und Ablauf gemeinsam: gleichzeitige Nutzung, Verteilung auf Funktionen, Pausen, Dauer und allmählicher oder sprunghafter Anstieg. Für eine zeitlich konzentrierte Veröffentlichung passt ein anderes Muster als für einen über den Tag verteilten Katalogbesuch. Das Modell wird mit Begründung dokumentiert, damit Ergebnisse später nicht aus ihrem Zusammenhang gelöst werden.

Es kann sinnvoll sein, einen bekannten normalen Betrieb und eine höhere Belastung getrennt zu betrachten. Führen Sie die zweite Stufe erst aus, wenn der kleinere Durchlauf technisch und organisatorisch funktioniert. Eine außergewöhnliche Spitzensituation ist außerdem keine passende Grundlage, um gewöhnliche Seitenaufrufe grundsätzlich mit zusätzlichen Hürden zu versehen.

03 / PRÜFUMFANG

Erst einen kleinen Ablauf verifizieren, dann gezielt steigern.

Unterschiedliche Testarten beantworten unterschiedliche Kapazitätsfragen.

Die k6-Dokumentation zu Testarten trennt beispielsweise einen kleinen Funktionstest von gewöhnlicher Last, einer kurzen Spitze oder länger anhaltender Beanspruchung. Daraus folgt keine Pflicht, jede Variante durchzuführen. Der geplante Anlass entscheidet, welche Beobachtung einen nützlichen nächsten Schritt ermöglicht.

Der erste kleine Durchlauf prüft, ob das Skript tatsächlich den richtigen Weg abbildet. Ein fehlerhaft angemeldeter Test kann sonst überwiegend eine Fehlermeldung abrufen. Ein Test ohne die erwarteten Parameter kann unbemerkt die günstige Standardantwort messen. Eine große Menge solcher Abrufe erzeugt eindrucksvolle Zahlen, ohne die Unternehmensfrage zu beantworten.

Stimmen Sie Testumgebung und Auslieferungsweg ab. Abweichende Datenmengen, ausgeschaltete Zwischenspeicher oder eine andere Serverausstattung begrenzen die Übertragbarkeit. Wenn die Produktionsumgebung geprüft werden soll, sind ein vereinbartes Zeitfenster und die Zustimmung der zuständigen Betreiber nötig. Die vorhandene Testumgebung für Änderungen hilft bei der Vorbereitung, ist aber nicht automatisch ein maßstabsgleiches Abbild der Kapazität.

Halten Sie relevante Unterschiede fest, statt sie im Bericht zu verstecken. Ein bestandener Test einer vereinfachten Umgebung ist ein Ergebnis für genau diese Umgebung. Ob daraus eine belastbare Aussage zum öffentlichen Betrieb entsteht, muss fachlich begründet werden. Manchmal ist ein eng begrenzter zusätzlicher Nachweis hilfreicher als eine umfangreichere, aber unpassende Simulation.

04 / SICHERE GRENZEN

Ein vereinbarter Test darf keine unkontrollierten Nebenwirkungen erzeugen.

Zuständigkeit, Abbruch und Testdaten gehören vor die erste größere Last.

Erfassen Sie vorab alle beteiligten Stellen: Hosting, vorgeschaltete Dienste, Datenbanken, E-Mail-Versand und externe Schnittstellen. Der Auftraggeber kann nicht stellvertretend eine beliebige Belastung fremder Dienste freigeben. Entsprechende Aufrufe werden abgestimmt, geeignet ersetzt oder ausdrücklich ausgenommen. Auch Kontingente und mögliche Kosten sind vorab zu klären.

Besonders wichtig sind schreibende Vorgänge. Ein wiederholt versendetes Formular darf nicht versehentlich echte Vertriebsvorgänge, Nachrichten oder Buchungen auslösen. Verwenden Sie gekennzeichnete synthetische Daten und eine kontrollierte Verarbeitung. Werden Funktionen dabei ersetzt, nennt der Bericht diese Einschränkung. Ein abgefangener Versand belegt beispielsweise nicht die Kapazität des echten Versanddienstes.

Die OWASP-Hinweise zum Schutz vor Überlastung zeigen, dass Ressourcen und Grenzen auf verschiedenen Ebenen betrachtet werden müssen. Ein vereinbarter Lasttest ist deshalb keine Aufforderung, Schutzmechanismen pauschal zu deaktivieren. Blockiert eine Schutzregel den Test, wird zunächst geklärt, ob die Regel, das Testmodell oder die Umgebung angepasst werden muss.

Definieren Sie beobachtbare Abbruchgründe, erreichbare Ansprechpartner und einen sicheren Rückweg. Dazu können unerwartete Fehler, Auswirkungen auf andere Dienste oder das Überschreiten einer abgestimmten Grenze gehören. Die Durchführung stoppt dann kontrolliert. Ein abgebrochener Versuch kann eine wichtige Erkenntnis liefern; für einen erfolgreichen Test muss nicht um jeden Preis die höchste Stufe erreicht werden.

05 / ARBEITSBLATT

Ein fiktives Messeangebot macht die entscheidenden Annahmen sichtbar.

Das folgende Raster ist eine eigene Planungshilfe und keine Kapazitätsempfehlung.

Ein fiktiver Zulieferer bewirbt auf einer Messe ein neues Beratungsangebot. Besucher sollen die Angebotsseite lesen, eine technische Unterlage öffnen und bei Bedarf eine Anfrage beginnen. Das Unternehmen hat keine gesicherte Prognose für gleichzeitige Zugriffe. Es vereinbart daher begründete Prüfstufen, statt eine erfundene Besucherzahl als feste Anforderung auszugeben.

Fiktives Beispiel: Lasttest vor einer Messe
NutzerwegZu klärende AnnahmeGrenze des Ergebnisses
Angebot lesenBeworbene Adresse und typische FolgeaufrufeKeine Aussage zu ungetesteten Unterseiten
Unterlage öffnenDateigröße und tatsächlicher AuslieferungswegKeine vollständige Bewertung langsamer Endgeräte
Anfrage beginnenValidierung und benötigte HintergrunddiensteKein Beleg für abgeschlossene echte Anfragen
Test beendenAbbruchsignal und verantwortliche PersonKein Freibrief für unbegrenzte Belastung

Ergänzen Sie Messzeit, Umgebungsstand und ausgeschlossene Dienste. Das Raster hilft auch beim Vergleich zweier Durchläufe: Wurde tatsächlich dasselbe geprüft? Eine bessere Zahl nach einer Änderung ist nur dann aussagekräftig, wenn sich nicht gleichzeitig die Testdaten oder das Lastmuster unbemerkt verändert haben.

06 / AUSWERTUNG

Ein brauchbarer Bericht verbindet Messung, Grenze und Entscheidung.

Die höchste Zahl allein erklärt weder einen Engpass noch einen Handlungsbedarf.

Vor dem Test vereinbarte Kriterien verhindern eine nachträgliche Auswahl besonders günstiger Messwerte. Die k6-Dokumentation zu Schwellenwerten beschreibt prüfbare Bedingungen für ausgewählte Metriken. Die dortigen Beispielwerte sind keine allgemeingültigen Qualitätsziele für jede Unternehmenswebsite. Passende Grenzen ergeben sich aus Funktion und vereinbartem Anspruch.

Betrachten Sie neben typischen Antwortzeiten auch langsame Antworten, Fehler und den Verlauf während des Tests. Ein Mittelwert kann einzelne problematische Wege verdecken. Zusätzliche Beobachtungen an den verantwortlichen Systemen helfen, einen möglichen Engpass einzugrenzen. Eine steigende Antwortzeit beweist für sich allein noch nicht, dass lediglich mehr Arbeitsspeicher gekauft werden sollte.

Der Bericht benennt Szenario, Umgebung, beobachtetes Verhalten und Einschränkungen. Daraus folgt eine Entscheidung: Die vereinbarte Situation ist ausreichend abgedeckt, ein bestimmter Engpass wird bearbeitet oder eine offene Annahme muss geklärt werden. Nach einer gezielten Änderung wird der betroffene Fall erneut geprüft. Ein unauffälliges Ergebnis wird nicht zu einer unbegrenzten Verfügbarkeitszusage erweitert.

Auch die Erzeugung der Testlast besitzt Grenzen. Wenn bereits der Prüfaufbau oder seine Verbindung zum Engpass wird, darf das Ergebnis nicht ungeprüft als Kapazitätsgrenze der Website ausgegeben werden. Der Bericht nennt deshalb, ob die vereinbarte Belastung tatsächlich erzeugt wurde. Ein nicht erreichtes Testziel und ein unter dieser Last versagender Dienst sind unterschiedliche Befunde.

07 / RUHRSTACK

Den Umfang nach dem tatsächlichen Geschäftsweg vereinbaren.

Eine belastbare Kapazitätsfrage beginnt mit nachvollziehbaren technischen Abhängigkeiten.

Ruhrstack betrachtet beim Hosting und Betrieb die eingesetzte Technik, benötigte Laufzeiten und zugehörige Dienste. Das ist eine sinnvolle Grundlage, um einen möglichen Prüfbedarf vor einer wichtigen Aktion zu besprechen. Welche Lastprüfung im konkreten Auftrag sinnvoll und durchführbar ist, wird gesondert abgestimmt.

Für die erste Einordnung helfen die beworbene Adresse, der geplante Anlass und die entscheidenden Nutzeraktionen. Teilen Sie auch mit, ob Erfahrungswerte vorliegen und welche externe Verarbeitung beteiligt ist. So wird aus „Wir erwarten viele Besucher“ eine konkrete technische Fragestellung. Das erleichtert eine angemessene Entscheidung über Prüfung, mögliche Anpassung und nachvollziehbaren Nachweis.

08 / QUELLEN

Quellen und redaktioneller Stand.

Die Quellen wurden am 22. Oktober 2026 geprüft. Die verlinkten Primärquellen wurden am 22. Oktober 2026 geprüft. Das Messebeispiel und die Planungstabelle sind fiktive eigene Arbeitshilfen. Produktdokumentationen dienen zur Erläuterung der Methodik, nicht als Empfehlung eines bestimmten Hosting- oder Testprodukts.

  1. Microsoft Learn: Performance testing: Geschäftsbezogene Anforderungen, repräsentative Szenarien und Umgebungsbezug. Abgerufen am 22. Oktober 2026.
  2. Microsoft Learn: Load testing concepts: Unterscheidung von virtuellen Nutzern, Anfrageraten und Antwortzeiten. Abgerufen am 22. Oktober 2026.
  3. Grafana k6: Test types: Kleine Vorprüfung sowie unterschiedliche Belastungsmuster. Abgerufen am 22. Oktober 2026.
  4. Grafana k6: Thresholds: Vorab definierte Bedingungen zur Bewertung von Messergebnissen. Abgerufen am 22. Oktober 2026.
  5. OWASP: Denial of Service Prevention Cheat Sheet: Ressourcenbegrenzung und Schutz auf unterschiedlichen Ebenen. Abgerufen am 22. Oktober 2026.

Redaktioneller Hinweis: Dieser Beitrag dient der allgemeinen Information und ersetzt keine Einzelfallprüfung. Trotz sorgfältiger Recherche wird keine Gewähr für Vollständigkeit und fortdauernde Aktualität übernommen. Eine Haftung nach zwingenden gesetzlichen Vorschriften bleibt unberührt. Redaktionelle Einordnung.

Steht eine wichtige Veröffentlichung bevor?

Nennen Sie den Anlass, die Zielseite und die entscheidenden Funktionen. Wir besprechen technische Abhängigkeiten und einen passenden Prüfbedarf.

Besucherspitze besprechen