Stresstest für Websites

Veröffentlicht: 27. Jan 2002 | Aktualisiert: 15. Jun 2004

Von Christian Wenz

Um eine Website einem sogenannten Stresstest zu unterziehen, benötigen Sie entweder viele Freiwillige oder ein Tool, dass dies automatisch erledigt. Das Web Application Stress Tool von Microsoft bietet viele Möglichkeiten, eine Website einem Belastungstest zu unterziehen.

Auf dieser Seite

 Scripts erstellen
 Page Groups
 Zusätzliche Messdaten
 Mehrere Benutzer und Testrechner
 Seiten importieren
 Testeinstellungen wählen
 Support?

Diesen Artikel können Sie hier lesen dank freundlicher Unterstützung der Zeitschrift:

Bild04

Beim lokalen Testen funktioniert eine Website zumeist ohne Klagen, doch der Schock erfolgt oft, wenn die Seiten für Jedermann erreichbar sind. Aufgrund schlampiger Programmierung, schlechter Anbindung oder unzureichender Hard- und Software stößt so manches Webangebot bei vielen gleichzeitigen Zugriffen schnell an seine Leistungsgrenzen. Es sind also praxisrelevante Testmechanismen gefragt, bevor eine Site live geschaltet werden sollte.
Eine nahe liegende, wenn auch sehr teure Variante besteht darin, eine Reihe von Testkandidaten gleichzeitig die Site besuchen zu lassen und dabei auf Fehler zu achten. Aufgrund von übermäßiger Serverlast kann es beispielsweise zu der gefürchteten HTTP-Fehlermeldung "Server Busy" kommen. Doch das ist nicht besonders effektiv, da Sie so nur Stichproben vornehmen können. Automatisierung tut also Not, und Microsoft bietet mit dem Web Application Stress Tool - kurz WAS - ein mächtiges Werkzeug an, um Websites einem Belastungstest unterziehen zu können.
Die Software befindet sich etwas versteckt unter webtool.rte.microsoft.com und ist etwa 10 Megabyte groß. Durch Starten der heruntergeladenen Datei setup.exe beginnt die Installation der Software. Sie sollen das Programm nicht direkt auf dem Webserver installieren, da so das Ergebnis der Messungen verfälscht werden könnte - die Ausführung des Tools würde zusätzliche Ressourcen belegen. Wenn Sie lediglich die Konfiguration und Ausstattung des Webservers testen möchten, sollten Sie sich einen Rechner im LAN suchen und von dort aus die Website testen, dann ist der Datendurchsatz am Größten. Wenn Sie zusätzlich auch noch die realen Gegebenheiten in Sachen Anbindung in das Ergebnis mit einfließen lassen wollen, sollten Sie einen Rechner in einem anderen Netzwerk verwenden und über das Internet auf die Website zugreifen. Beachten Sie aber die Systemvoraussetzung. Das Web Application Stress Tool benötigt als Betriebssystem Windows NT 4.0 mit Service Pack 4 oder höher oder Windows 2000. Dazu ist ein x86-Prozessor erforderlich. Für Alpha-Prozessoren existiert auch eine Version, deren Entwicklung jedoch Ende 1999 eingestellt worden ist.

Scripts erstellen

Eine Testkonfiguration wird in WAS als sogenanntes Script gespeichert. Dies ist nichts anderes als eine Beschreibungsdatei, die Einstellungen für den Test enthält. Beim ersten Start von WAS sehen Sie im linken Teil des Fensters eine Beispielsdatei, genannt Sample Script. Diese enthält eine exemplarische Konfiguration für einen Test des lokalen Webservers. Wenn Sie tatsächlich einen lokalen Webserver installiert haben, können Sie das Skript durch die Pfeil-Schaltfläche oder den Menübefehl Scripts / Run durchlaufen lassen. Zuvor sollten Sie aber den Ordner samples im Programmverzeichnis von WAS in das Hauptverzeichnis Ihres Webservers kopieren (in der Regel c:\inetpub\wwwroot). Auf diese Dateien wird vom Skript aus zugegriffen. Der Durchlauf des Tests dauert 15 Minuten (ist so eingestellt), danach erhalten Sie einen Report (Bild B1). Hier sehen Sie sowohl die Durchschnittswerte der Seite als auch aufgetretene Fehlercodes sowie eine Aufschlüsselung der Analyse nach einzelnen Seiten. Über File / Export Report können die Daten im CSV-Format abgespeichert werden. Damit lassen sich die Daten in anderen Programmen weiterverwenden, beispielsweise können sie in Excel importiert und dann als Chart grafisch visualisiert werden.

Bild01

B1 Report des Beispielskripts

Werfen wir nun einen Blick auf die einzelnen Elemente eines WAS-Scripts. Zunächst einmal sehen Sie - wenn Sie im linken Bereich des Programmfensters auf Sample Script klicken - im rechten Bereich einige Eingabefelder. Neben dem Namen des Webservers (WAS kann jeweils nur einen Webserver testen) sehen Sie eine Liste von Dateien, die aufgerufen werden sollen. Wenn Sie die Schaltfläche links von dem Element mit den Werten GET und POST doppelt klicken, öffnet sich das Eigenschaftenfenster für die jeweilige Datei. Dort können Sie nicht nur die Zugriffsmethode einstellen (GET/POST), sondern ggf. auch die Daten, die an das Skript übermittelt werden, sowie weitere Header-Informationen. Damit lässt sich beispielsweise der Versand eines Formulars originalgetreu simulieren.
An späterer Stelle in diesem Artikel stellen wir noch alternative Möglichkeiten vor, die Dateien einzugeben, auf die zugegriffen werden soll. Sie müssen also nicht alle Dateien von Hand aufführen. So können Sie etwa im Bereich Content Tree weitere Dateien und Verzeichnisse angeben, die von dem Testprogramm überwacht werden sollen. Sobald Sie dort einen Eintrag ankreuzen, taucht dieser in der Hauptübersicht Ihres Scripts auf.

 

Page Groups

Die zu testenden Bereiche der Website können in einzelne Gruppen aufgeteilt werden. Hierzu dient primär der Bereich Page Groups. Dort können Sie beliebig viele Seitengruppen erstellen. In der Dateiliste werden dann die Dateien der jeweiligen Gruppe zugeordnet. Dieses Vorgehen hat mehrere Vorteile. Zunächst einmal werden die Skripteinstellungen deutlich lesbarer und damit transparenter, wenn Sie den Gruppen klingende Namen geben. Beispielsweise könnten Sie Ihre Website in die Bereiche Produktinformationen, Support und Downloads unterteilen. Im Ergebnisreport eines Stress Tests werden die Statistiken auch nach Gruppen aufgeteilt. Sie sehen so auf einen Blick, welche Auslastung welche Bereiche der Website beim Stresstest hatten.
Auch in umgekehrter Richtung bringt dieses Vorgehen Vorteile mit sich. Wenn Sie die Logfiles Ihrer Website analysieren, was Sie bei einem professionellen Webangebot auch unbedingt machen sollten, wissen Sie recht genau, wie sich die Besucherzahlen auf die einzelnen Bereiche Ihrer Website verteilen. Beispielsweise können Sie überprüfen, welcher Anteil Ihrer Besucher direkt zum kostenlosen Produktdownload oder in die Knowledge Base geht und wie viele Besucher sich zunächst Ihre Produktinformationen oder Firmenhistorie ansehen. Um einen Stress Test möglichst realistisch zu gestalten, sollte diese Verteilung der Auslastung auch in den Testeinstellungen repräsentiert werden. Unter Page Groups können Sie einstellen, welcher prozentuale Anteil der Zugriffe auf den jeweiligen Bereich erfolgen soll. Lockt also das Bild Ihres Vorstandsvorsitzenden nur einen einstelligen Prozentteil der Besucher an, sollten Sie das auch im Test berücksichtigen, denn sonst erhalten Sie ein verfälschtes Ergebnis.
Insbesondere bei komplexeren Seiten, beispielsweise Datenbankabfragen oder der Zusammenarbeit mit COM-Objekten, ist es für einen repräsentativen Test sehr wichtig, geeignete Testbedingungen zu haben. Wenn der ressourcenhungrigste Bereich einer Website üblicherweise eher selten aufgerufen wird, beispielsweise nur von autorisierten Nutzern, im Stresstest aber die Hälfte der Zugriffe erhält, ist das Testergebnis sicherlich verfälscht. Durch eine Aufteilung in Page Groups kann ein den realen Gegebenheiten entsprechenderes Ergebnis erzielt werden.
Für einen möglichst realistischen Stress Test empfiehlt sich natürlich das umgekehrte Vorgehen. Überprüfen Sie hauptsächlich diejenigen Bereiche Ihrer Website, die viele Ressourcen verbrauchen. So stellen Sie sehr schnell fest, ob und wie Ihr System an seine Grenzen gerät. Im Report des Tests verrät dann oft schon ein Blick auf die HTTP-Fehlermeldungen, ob das System an seine Grenzen gestoßen ist. Kam es zu einem Timeout? Häuft sich das Auftreten des HTTP-Fehlers 500 (Internal Server Error)? Das ist ein recht sicheres Anzeichen dafür, dass der Server überlastet ist.

 

Zusätzliche Messdaten

Im Abschnitt Perf Counters können Sie weitere Daten über das System sammeln. Ein Klick auf die Schaltfläche Add Counter ruft ein Dialogfenster auf, in dem Sie unter einer Reihe von Performanceindikatoren auswählen können, wie Sie es auch im Systemmonitor von Windows NT/2000 machen können. Die folgenden Indikatoren sind beispielsweise geeignet, mit WAS während eines Stress Tests aufgezeichnet zu werden:

  • Zeitüberschreitungen beim Aufruf von ASP-Seiten

  • Anzahl Sitzungen

  • Prozessorlast

  • Anzahl der Anforderungen von ASP-Seiten pro Sekunde

Für diese Indikatoren ist es natürlich erforderlich, das WAS-Tool auf demselben Rechner auszuführen, auf dem sich auch der Webserver befindet.

 

Mehrere Benutzer und Testrechner

Ein Klick auf den Knoten Users zeigt im Sample Script 200 exemplarische Benutzer an. Dies ist ein weiterer Kniff, um eine möglichst originalgetreue Testumgebung zu schaffen. Wenn dies nicht so wäre, würde jeder Zugriff auf die Website eine neue ASP-Session öffnen. Die 200 Beispielsnutzer jedoch bekommen jeweils ein Session-Cookie, weswegen damit effektiv das gleichzeitige Surfen von 200 Nutzern simuliert wird.
Über View / Users blenden Sie die Benutzerübersicht ein und können dort Nutzer hinzufügen. Diesen Nutzern können Sie auch einen Benutzernamen und ein Passwort zuweisen. Damit lässt sich HTTP-Authentifizierung durchführen. Es ist also auch möglich, geschützte Webseiten mit WAS zu testen, wenn Sie die Passwörter bei der Benutzerübersicht eintragen. In der Hauptübersicht können Sie unter dem Punkt Cookies für jeden Benutzer Cookies einrichten. Verwenden Sie dazu dieselbe Syntax, die Sie auch beim Setzen eines Cookies im HTTP-Header verwenden würden: Name1=Wert1; Name2=Wert2.
Der Menübefehl View / Clients bietet die Möglichkeit an, mehrere Maschinen an dem Stresstest zu beteiligen. Der Webserver wird dann von mehreren Clients aus befragt. Dem Test stehen damit mehr Ressourcen (Prozessor, Hauptspeicher, Bandbreite) zur Verfügung. Dadurch ist es möglich, eine größere Last auf dem Server zu erzeugen als dies mit einer einzigen Maschine möglich wäre - also eine Form von verteilter Anwendung. Dieses Vorgehen empfiehlt sich jedoch nur, wenn das WAS-Tool mehr als 50% Prozessorlast belegt. Ansonsten kommt es zu einem Sättigungseffekt, wie es oft auch beim Ausbau des Speichers eines Systems spürbar ist: Die Effekte sind kaum spürbar.

 

Seiten importieren

Bei umfangreichen Websites ist die Eingabe der Seiten, die alle im Testlauf überprüft werden sollen, sehr aufwendig. Wenn Sie jedoch für die Seite ein aktuelles Logfile haben, umso besser. Sie können dieses Logfile in WAS importieren. Der Import-Assistent liest alle Dateien aus dem Logfile aus, entfernt auf Wunsch Duplikate und fügt die Dateiliste in ein neues Skript ein. Dies ermöglicht einen besonders realitätsnahen Test, da alle Dateien überprüft werden, die auch von den Benutzern in letzter Zeit aufgerufen worden sind. Beim Starten des Programms erhalten Sie ein Dialogfenster (Bild B2). Dort können Sie den Assistenten aufrufen, indem Sie auf die Schaltfläche Log File klicken.

Bild02

B2 Assistent-Auswahl beim Programmstart

Es gibt auch noch eine weitere Methode, die zu überprüfenden URLs dem WAS-Tool mitzuteilen. Die Schaltfläche Record beim Programmstart ermöglicht es Ihnen, einen Besuch einer Website im Webbrowser mitzuschneiden und dann über das WAS-Tool wiederholt ablaufen zu lassen. Dazu müssen Sie zunächst im Internet Explorer den Proxyserver auf "localhost" und den Proxyport auf 8000 stellen (auch für lokale Seiten). Starten Sie nun die Aufnahme und surfen auf der Seite herum oder, noch besser, lassen Sie eine Testperson surfen - als Sitebetreiber ist man erfahrungsgemäß "betriebsblind". WAS speichert dann die aufgerufenen Seiten samt der zugehörigen Verzögerung beim Aufruf ab.

 

Testeinstellungen wählen

Bevor der eigentliche Test gestartet wird, können unter Settings noch einige Einstellungen getätigt werden:
Unter dem Punkt Concurrent Connections kann die Last, dem der Server ausgesetzt wird, genauer konfiguriert werden (Bild B3). Unter Stress level wird die Anzahl der gleichzeitigen Verbindungen angegeben (Threads). Der Stress multiplier ist, wie der Name schon sagt, ein Multiplikator. Er gibt an, wie viele Sockets pro Thread geöffnet werden dürfen. Die empfohlene Standardeinstellung ist: Beliebig viele Threads, ein Socket pro Thread. Für diese Regel gibt es jedoch eine Ausnahme: Es ist empfehlenswert, nicht mehr als 100 gleichzeitige Threads aufzubauen. Wenn Sie mehr gleichzeitige Zugriffe simulieren möchten, arbeiten Sie mit dem Stress multiplier. Geben Sie also eine Thread-Zahl unter 100 an und einen entsprechenden Multiplikator. Die angegebenen Werte werden dabei multipliziert, um die Zahl der gleichzeitigen Verbindungen zu ermittelt. 50 Threads à drei Sockets ergibt also 50 * 3 = 150 gleichzeitige Verbindungen.

Bild03

B3 Allgemeine Einstellungen

In diesem Dialogfenster lässt sich auch die Testlaufzeit einstellen, wobei die Standardeinstellung im Beispiel 15 Minuten beträgt. Während dieser Zeit macht das WAS Tool nacheinander Zugriffe auf den Webserver, und zwar einen nach dem anderen. Die Maxime des Vorgehens lautet dabei "so schnell wie möglich", was bedeutet, dass Sie nicht einstellen können, wie schnell die Zugriffe erfolgen sollen. Sie können dieses Verhalten mit anderen Einstellungen steuern - doch dazu später. Zwischen zwei einzelnen Zugriffen gibt es jeweils eine kurze Zeitspanne, in der das Tool pausiert. Diese wird per Zufall festgelegt, wieder eine Methode, die realen Gegebenheiten nachzubilden. Die Standardeinstellung liegt zwischen 20 und 40 Millisekunden.
Um möglichst viele gleichzeitige Verbindungen zu ermöglichen, können Sie unter Bandwidth die dem Tool zur Verfügung stehende Bandbreite einschränken. In der Kombiliste stehen dazu mehrere Einstellungen zur Verfügung, vom 14.400-Baud-Modem bis zur T1-Leitung. Durch die Verringerung der Bandbreite erhält jeder einzelne Benutzer weniger Daten pro Zeiteinheit und es sind mehr gleichzeitige Verbindungen möglich, da der Webserver nicht so schnell überlastet ist.
Die nächste interessante Einstellungsmöglichkeit befindet sich unter Throughput. Zunächst einmal können Sie angeben, ob Benutzernamen, Passwörter und Cookies gespeichert werden sollen. Wenn Sie diese Option deaktivieren, läuft der Stress Test schneller durch und kann mehr Daten anfordern, die Performance des Web Servers könnte aber schlechter werden (beispielsweise, weil ohne Cookies bei jedem Aufruf eine neue Session erzeugt wird). Die Einstellung Save page statistics sorgt dafür, dass die Ergebnisse des Stress Tests überhaupt gespeichert und in einem Report angezeigt werden sollen. Wenn Sie diese Option deaktivieren, wird das Tool zwar schneller, aber Sie bekommen die Ergebnisse nicht mehr so detailliert dargestellt. Dies ist nur empfehlenswert, wenn Sie die für Sie interessanten Ergebnisse, beispielsweise ob der Server sich aufhängt oder nicht, an anderer Stelle erhalten (beispielsweise durch ein weiteres Monitoring-Tool).
Sie sollen die Testdurchführung sorgfältig planen und dabei bedenken, was genau Sie testen wollen. Im Allgemeinen geht es darum zu überprüfen, ob ein Server mit einer erwarteten oder geschätzten Last zurecht kommt oder nicht. Sie müssen dazu also schätzen, wie viele Besucher Sie in einem bestimmten Zeitraum haben und für wie viele Zugriffe diese Besucher sorgen. Hierfür gibt es mehrere Anhaltspunkte:

  • Logfile-Auswertung der Website im Vormonat (oder zumindest möglichst aktuell)

  • Erfahrungswerte von anderen, vergleichbaren Websites

  • Hochrechnung, also der Versuch, die Gegebenheiten auf einer kleineren oder weniger populären Website auf die zu testende Website zu übertragen. Das ist zwar fehleranfällig, aber immerhin ein erster Schätzwert.

Die Anzahl der zu erwartenden Besuche wird dabei in einer der folgenden Einheiten gemessen:

  • Zugriffe pro Zeiteinheit

  • (verschiedene) gleichzeitige Nutzer pro Zeiteinheit

  • Anzahl (verschiedene) Benutzer pro Zeiteinheit

Wie oben bereits erläutert, kann beim WAS-Tool das Maß für die Zugriffe pro Zeiteinheit nicht eingestellt werden, da das Tool versucht, die Zugriffe möglichst schnell zu erledigen. Durch Beschränkung der dem Tool zur Verfügung stehenden Bandbreite können Sie dabei die Anzahl der Zugriffe erhöhen. Versuchen Sie, durch entsprechende Einstellungen für Threads und Sockets die Anzahl der gleichzeitigen Nutzer möglichst genau nachzubilden.
Für die gleichzeitigen Nutzer pro Zeiteinheit ist es auf sehr einfache Art und Weise möglich, den gewünschten Wert exakt nachzubilden: Das Produkt aus Threads und Sockets muss die gewünschte Zahl an gleichzeitigen Nutzern ergeben; dabei sollte die Thread-Zahl 100 nicht überschreiten. Sehr populäre Websites haben mitunter eine vierstellige Anzahl an gleichzeitigen Nutzern (also nicht an gleichzeitigen Zugriffen!). Um dies nachbilden zu können, sollten Sie die Bandbreite beschränken, um so die Anzahl der Zugriffe ein wenig einzudämmen. Sollte das noch nicht genügen, überprüfen Sie Ihr Webangebot dahingehend, ob nicht ein Teil davon auch als statisches HTML realisierbar wäre, denn HTML-Seiten sind natürlich immer weniger ressourcenhungrig als ASP-Seiten.
Die letzte vorgestellte Einheit ist die Anzahl der Nutzer pro Zeiteinheit, beispielsweise "1000 pro Tag" oder "eine Million pro Monat". Zunächst müssen Sie dafür sorgen, dass das WAS-Tool auch die entsprechende Anzahl an simulierten Nutzern auf die Website losschickt. Wählen Sie dazu View / Users und erzeugen Sie die gewünschte Anzahl an Nutzern. Bevor Sie den Test starten, müssen Sie darauf achten, dass auch jeder dieser Nutzer zum Zuge kommt. Wenn Sie 600 Nutzer einrichten und den Test eine Minute lang laufen lassen, muss der Webserver zehn Zugriffe pro Sekunde vertragen. Das WAS-Tool führt die Zugriffe ja sequenziell aus, weswegen das Produkt aus Testdauer (in Sekunden) und Anzahl der Zugriffe pro Sekunde die Zahl der Nutzer übersteigen muss. Für eine Million Nutzer und einen Webserver, der 20 Zugriffe pro Sekunde verkraftet, muss der Test 1000000/20 = 50000 Sekunden laufen, das sind fast 14 Tage. Bei solchen Zahlen sollten Sie die Zugriffe herunterrechnen: Eine Million Nutzer pro Monat entspricht etwa 250000 Nutzern pro Woche oder gut 33000 Nutzern pro Tag. Achten Sie darauf, nicht zu weit herunterzurechnen. Die Zugriffszahlen sind bei den meisten Websites von Uhrzeit und Wochentag abhängig.

 

Support?

Microsoft weist auf der Website zum WAS-Tool explizit darauf hin, dass hierzu kein Support angeboten wird. Es ist aber möglich, den Entwicklern Fehler zu berichten und auch Wünsche für neue Funktionalitäten zuzuschicken. Dennoch gibt es hierfür keine Garantie. Unter http://webtool.rte.microsoft.com steht jedoch eine recht umfangreiche Knowledge Base zu WAS zur Verfügung. Offensichtlich wurden dort zum Teil auch Mailwechsel zwischen Anwendern und den Entwicklern abgelegt, so dass dort auch eine ganze Reihe von "Real World" Problemen behandelt - und gelöst - sind. Ein Besuch lohnt sich also auf jedem Fall.