Test: Paessler Webserver Stress Tool

Beinahe jede Website hat heutzutage einen mehr oder weniger großen Anteil an dynamischen Inhalten. Sei es nun ein „einfaches“ Forum oder eine komplette Web-Applikation, die eine Reihe von verschiedensten Diensten bereitstellt. Eines ist jedoch beiden Einsatzszenarien gemeinsam:

Der Administrator muss verstärkt ein Auge darauf haben, wie sich die Anwendung unter Last verhält. Denn im Gegensatz zu statischen Inhalten, die ein Apache-Webserver mit hoher Geschwindigkeit ausliefern kann, erzeugt eine dynamische Website erheblich mehr Rechenaufwand auf dem Server. Die Daten müssen aus einer Datenbank abgefragt und zu einer HTML-Datei zusammengestellt werden.

Da die auszugebenden Ergebnisse im Extremfall für jeden Besucher unterschiedlich sind, ist auch mit Caching oder Statifizieren von Ergebnisseiten nicht unbedingt viel gewonnen. Dies könnte beispielsweise bei einer Community-Site der Fall sein, wo jede ausgegebene Seite, dem aktuellen Benutzer angepasst ist.

Allerdings stellt sich dem Administrator vor dem Rollout die Frage der Infrastruktur und der notwendigen Hardware. Um einen annähernden Anhaltswert zu finden, wie viele Benutzer die Applikation auf einer bestimmten Hardware verkraftet, oder zu evaluieren, wie sich die Applikation unter großer Last verhält, benötigt man Lasttests. Hierbei wird eine Anzahl an Besuchern simuliert, die eine Reihe von definierten Aktionen auf dem Webserver ausführt, um das Antwortverhalten zu ermitteln.

Die Nürnberger Firma Paessler bietet mit dem Webserver Stress Tool eine Software an, die dem Betreiber einer Website bei genau diesen Aufgaben helfen soll. Auf den folgenden Seiten lesen Sie, welche Einsatzmöglichkeiten die Software bietet und wo ihre Schwachpunkte und Beschränkungen liegen.

Quickinfo

Produkt	Webserver Stress Tool
Hersteller	Paessler AG
Preis	237,94 Euro (Professional) bis 2374,05 Euro (Enterprise Site License)

Einsatzszenarien und Vorgehensweisen

Vom dem ersten Rollout einer Web-Applikation lassen sich mittels Lasttests Anhaltspunkte über benötigte Hardware und Infrastruktur gewinnen. Dabei wird die Applikation so aufgesetzt, wie sie später auch in den Live-Betrieb gehen soll, also mit Datenbank- und Storage-System und eventuell vorgeschalteten Proxy-Servern. Parallel zu den Antwortzeiten, die das Last-Tool auswirft, sollte man zusätzlich auf die Auslastung der einzelnen Maschinen achten, um Flaschenhälse aufzudecken.

Webapplikationen liefern nicht nur dynamische Inhalte aus, sie werden auch ständig weiterentwickelt. Bevor eine neue Version eingespielt wird, sollte man allerdings ermitteln, wie sie sich auf das Antwortverhalten auswirkt. Am offenen Herzen (also der Live-Anlage) sollte man natürlich nicht operieren – weder entwickeln noch testen. Daher nutzt man am besten die Entwicklungs-Anlage. Die wichtigen Informationen ergeben sich dabei aus dem Vergleich zwischen den Performance-Werten der aktuellen Version und der neuen.

Soll die Hardware der Live-Anlage ausgetauscht werden, können Sie die Ergebnisse des Lasttests vom Rollout mit den Benchmarks der neuen Hardware vergleichen, um eine Idee von der zu erwartenden Leistungssteigerung zu erhalten.

Zudem lohnt es sich, die eigene Applikation dauerhaft zu überwachen. Sich also ständig ein Bild vom Antwortverhalten des Servers zu machen. Dazu lässt man regelmäßig bestimmte Abrufe auf der Site erzeugen und beobachtet die Antwortzeit. Hier ist es nicht notwendig, große Lasten zu erzeugen.

Webstress im Einsatz

Die Installation des ausschließlich in Englisch verfügbaren Webserver Stress Tool stellt keine großen Anforderungen an den Anwender. Es sind lediglich der Installationsort und gegebenenfalls der Lizenzschlüssel anzugeben. Danach ist das Tool einsatzbereit. Für einen ersten Test, bietet es sich an, ein paar einfache URLs vom eigenen Webserver abzurufen.

Beim Testprojekt kann man zwischen verschiedenen Varianten wählen:

• Clicks legt fest, wie viele Seitenaufrufe ein Benutzer erzeugen soll.

• Time legt fest, dass der Test eine bestimmte Zeit laufen soll.

• Ramp bedeutet, dass der Test eine bestimmte Zeit läuft, wobei die Anzahl der simulierten Benutzer immer weiter steigt.

Im nächsten Bereich legt man die Anzahl zu simulierender Benutzer fest und welche Verzögerung zwischen zwei Klicks liegen soll (Click delay). Hier unterstützt das Stress Tool einen festgelegten oder einen zufälligen Wert. Optional kann man später auch pro abzurufender URL einstellen, wie groß die Klickpause sein soll.

Hier finden sich auch die einzigen Unterschiede zwischen Demo-, Professional- und Enterprise-Version:

	Max User	min Click-Delay (s)
Enterprise	10000	0
Professional	100	5
Demo	10	5

Zudem kann die Enterprise-Version auch SSL-Seiten messen.

Für den ersten Test legen wir einen Benutzer fest, der eine Reihe von URLs abruft. Hier kann man am besten sehen, ob die URLs richtig konfiguriert wurden – insbesondere wenn es um dynamische Seiten mit Login-Funktion geht.

Auswahl der URLs

Im nächsten Schritt geht es an die Auswahl der abzurufenden URLs. Hier kann man entweder die Web-Adressen direkt angeben, sie per Recorder aufzeichnen lassen oder ein VBScript erstellen, das erheblich mehr Steuerungsmöglichkeiten bietet.

Für den ersten Test verlassen wir uns auf die direkte Eingabe der abzurufenden URLs und hinterlegen eine Reihe von URLs, die das Tool sequentiell abrufen soll. Optional bietet das Webserver Stress Tool auch die Möglichkeit, die Web-Seiten zufallsgesteuert oder nach einem Muster zu testen. Es bietet sich an, den einzelnen URLs einen Namen zu geben – dieser wird später im Bericht und den Grafiken angezeigt. Andernfalls ist es schwer, die einzelnen Kurven den richtigen URLs zuzuordnen.

Simulierte Logins

Um Login-Vorgänge zu simulieren, kann WST auch Daten per POST übermitteln und zurückgegebene Cookies speichern. Der Klickrecorder speichert die POST-Daten automatisch – bei händischer Eingabe sind diese Informationen selbst zu kodieren.

Die nächste Seite legt fest, wie sich WST dem Webserver gegenüber melden soll (User Agent) und wie er mit den übermittelten HTML-Seiten verfahren soll. Hier lässt sich einstellen, dass er den HTML-Code interpretiert und entsprechend die referenzierten Bilder, Objekte oder Frames abruft. Das kostet zwar mehr Rechenleistung auf dem testenden Client liefert aber ein realistischeres Ergebnis. Ist das HTML-Parsing ausgeschaltet, muss man gegebenenfalls sämtliche sonstigen Objekte händisch für den Abruf konfigurieren. Einen kleinen Unterschied im Vergleich zu einem normalen Webbrowser leistet sich das WST allerdings: Ein normaler Webbrowser fordert immer nur eine beschränkte Anzahl von Objekten gleichzeitig an – WST analysiert die Seite und startet sofort für jedes Objekt eine Anfrage.

Damit sind die Vorarbeiten auch schon abgeschlossen und der Test kann starten. Ein Klick auf Start Test lässt das Tool loslegen. Nach wenigen Sekunden ist das Tool fertig und wirft eine Reihe von Informationen über den Testlauf aus.

Ergebnisse

Direkt nach dem Lauf startet WST den Webbrowser, um eine HTML-Ansicht der Ergebnisse darzustellen. Allerdings bietet diese keine Vorteile gegenüber der Ansicht im Programm selber. Daher wechseln wir gleich wieder ins Programm.

Der erste Blick gilt dem Graphen „Test Client Health“. Hier kann man schnell feststellen, ob nicht etwa Probleme im Testclient das Ergebnis verfälschen – ob beispielsweise eine dauerhaft zu hohe CPU-Auslastung dafür sorgt, dass die Antwortzeiten des Servers vermeintlich zu hoch sind. Auch die Netzwerkbandbreite sagt etwas aus – ist sie immer nahe beim theoretischen Maximum, zeigen die Ergebnisse möglicherweise nicht die tatsächliche Leistungsfähigkeit des Servers.

Überblick

Danach kann man einen Blick auf den Graphen „Click Times and Errors (per URL)“ werfen. Dort findet sich für jede abgerufene Seite sowie aggregiert für alle Bilder je eine Kurve für die Dauer der Anfrage und eine für die Fehler im unteren Bildabschnitt. Da hier jedoch ein zeitlicher Verlauf dargestellt ist, sind die Ergebnisse immer unter dem Gesichtspunkt zu sehen, welche URLs in welcher Reihenfolge mit welchen Verzögerungen abgerufen wurden. So kann beispielsweise eine URL, die frühestens nach 50 Sekunden das erste Mal angefordert wird, auch frühestens nach 50 Sekunden eine Auswirkung in der Kurve haben.

Die aggregierten Informationen für eine URL finden sich unter dem Menupunkt „Log Files“ „Results per URL“. Dort gibt WST aus, wie oft die Adresse abgerufen wurde, wie viele Fehler es gab und wie das durchschnittliche Antwortverhalten des Servers für diese Ressource war.

Logdateien

Dort finden sich auch die einzelnen Logdateien des Testlaufs. Das „Summary Log“ teilt den Testlauf in gleichlange Perioden auf und liefert für jede Periode Informationen über die Anzahl der abgeschlossenen Anfragen inklusive der Fehler, die durchschnittliche „Click Time“ pro User und die erfolgreichen Klicks pro Sekunde.

Das „Detailed Log“ gibt zunächst Informationen über die Konfiguration des Testlaufs aus, und danach für jede Periode eine Reihe von Angaben:

• Anzahl gesendeter und empfangener Anfragen

• Abgeschlossene Abfragen

• Abgeschlossene Seitenaufrufe inklusive Fehlerzahl

• Anzahl Bildabrufe inklusive Fehlern und durchschnittlicher Abrufdauer

• Verteilung der „Click Times“

• Durchschnittliche Zeit für das Öffnen des lokalen Socket, die DNS-Abfrage, den Verbindungsaufbau zum Server, bis zum ersten Antwort-Byte des Servers und bis zum Abschluss der Anfrage.

• Anfragen (Hits) pro Sekunde

• Abgeschlossene Abrufe (Clicks) pro Sekunde

• Durchschnittliche Abrufdauer, Anzahl Clicks, Anzahl Fehler für jede URL

• Bandbreite pro User und Gesamt

Detail-Log pro Benutzer

Für jeden simulierten Benutzer findet sich ein separates Testlog, das je nach Konfiguration mehr oder weniger Informationen über den Verlauf des Tests enthält. So können darin beispielsweise sämtliche Abrufe, gesendete und empfangene Header und Statuscodes enthalten sein. Bei komplettem Logging finden sich dort auch der empfangene HTML-Code.

Letzteren kann der Benutzer aber auch separat speichern lassen, etwa um herauszufinden, ob bei dynamisch generierten Seiten bestimmte Elemente vorhanden sind oder nicht.

Erweiterte Abfragemöglichkeiten

Um die abgerufenen URLs dynamischer zu gestalten, bietet WST das so genannte „Data Merging“ an. Hier kann der Anwender spezielle Platzhalter durch dynamisch generierte Daten ersetzen lassen.

So lässt sich beispielsweise die Sequenz @@ durch eine fortlaufende Nummer austauschen, so dass jede Anfrage anders aussieht. Das ist beispielsweise sinnvoll, wenn Sie fortlaufend durchnummerierte Artikel im Shop haben. Dann würde die URL http://meineseite/artikel/detail.php?id=@@ dafür sorgen, dass ein Artikel nach dem anderen abgerufen wird (sofern es natürlich in Ihrem Shop eine detail.php gibt, die zu einer übergebenen Artikel-ID Details auswirft).

Weitergehende Möglichkeiten bietet WST durch Verwendung von kommaseparierten Dateien. Hier werden die Platzhalter @x@ mit dem Inhalt der Spalte x ersetzt. So könnte man beispielsweise simulieren, dass sich verschiedene Benutzer einloggen. WST kann die hinterlegten Daten sequenziell oder zufällig auswählen. Zudem kann das Tool für jede eingestellte URL eine andere Datei als Datenquelle verwenden.

Abfragen per VBScript

Wem die Möglichkeiten bisher noch nicht ausreichen, der kann ein VBScript erstellen, um die Abfragen komplett dynamisch zu generieren. WST erleichtert den Einstieg in die Skript-Programmierung mit einem vorgefertigten Demoskript, das alle Events und Eingriffsmöglichkeiten in Kommentaren erläutert.

Bestimmte Methoden dieses Skripts werden an vier Stellen eines Seitenabrufs aufgerufen:

OnBeforeClick wird als erstes aufgerufen und dient dem Programmierer dazu, die abzurufende URL und weitergehende Parameter wie POST-Daten festzulegen.

OnAfterClick wird nach dem simulierten Klick angesteuert und lässt sich primär für Ausgaben in das Testlog nutzen.

OnBeforeRequest wird für jede HTTP-Anfrage ausgelöst, also zunächst für die HTML-Seite an sich und danach für jedes zu ladende Objekt (Bilder, Flash und so weiter).

OnAfterRequest wird für jede abgeschlossenene Anfrage aufgerufen. Als Parameter kommt neben Informationen wie HTTP-Statuscode und –Header vor allem auch das zurückgelieferte Objekt mit, also beispielsweise die Bilddaten oder der HTML-Quelltext.

Neben dem reinen Protokollieren von Informationen kann man das Skripting auch für erweiterte Abfragen nutzen. So lässt sich der HTML-Quelltext beispielsweise mittels diverser Skriptfunktionen auch auf das Vorhandensein bestimmter HTML-Elemente durchsuchen. Abhängig vom Ergebnis dieser Untersuchung kann der Programmierer so genannte Tokens setzen, die beim Aufruf der nächsten URL in OnBeforeClick verarbeitet werden.

Gelieferte Messwerte

Das Paessler Webserver Stress Tool liefert in verschiedenen Graphen und Tabellen eine Reihe von Daten über die Website.

• Click Time – die Gesamtzeit, die ein User vom Klicken auf einen Link bis zu dem Zeitpunkt, an dem sämtliche Objekte geladen sind, warten muss.

• Time for DNS – die für das Auflösen des Domainnamens benötigte Zeit.

• Time to connect – Für den Verbindungsaufbau zum Server benötigte Zeit.

• Time to first byte (TFB) – Zeit zwischen dem Verbindungsaufbau und dem ersten empfangenen Byte. Bei dynamischen Web-Anwendungen ist das beispielsweise die für das Erzeugen der Seite benötigte Zeit. Also der wichtigste Indikator für die Performance der Anwendung.

• Time to last byte (TLB) – Die für eine HTTP-Anfrage benötigte Zeitspanne, also eine HTML-Datei oder ein Bild.

• Server Bandwidth – Die genutzte Bandbreite des Webservers.

• User Bandwidth – Die durchschnittliche Bandbreite, die einem simulierten Benutzer zur Verfügung stand.

• Sent Requests – Während eines bestimmten Zeitraums gesendete Anfragen.

• Received Requests – Während eines Zeitraums empfangene Antworten. Im Idealfall also derselbe Wert wie bei Sent Requests.

• Open Requests – Offene, also noch nicht beantwortete, Anfragen zu einem bestimmten Zeitpunkt.

• Error rates – Die Anzahl fehlgeschlagener Anfragen während einer Periode, pro User oder pro URL.

Fazit

Der Betreiber einer Website sollte nicht nur vor dem Rollout sondern auch während des Betriebs über die Leistungsfähigkeit seiner Web-Infrastruktur genauestens Bescheid wissen. Denn nichts ist schlimmer als ein Besucher, der entnervt die Site verlässt, weil er ständig Ewigkeiten auf die Seiten warten muss.

Mit dem Webserver Stress Tool von Paessler hat der Administrator ein leistungsfähiges Tool zur Hand, das ihm sowohl bei der initialen Bewertung seiner Infrastruktur als auch bei der regelmäßigen Überwachung hilft. Dabei ist WST gleichermaßen einfach wie flexibel einsetzbar: Dank Klickrecorder ist schnell ein Test aufgesetzt, der die wichtigsten Anforderungen erfüllt.

Detailliertere Analysen lassen sich über die Skripting-Schnittstelle mit etwas mehr Aufwand generieren. Für mittlere Sites reicht die Professional-Version für knapp 240 Euro inklusive Mehrwertsteuer völlig aus, darin enthalten ist bereits ein Jahr Software-Maintenance. Größere Sites oder Sites mit SSL benötigen die Enterprise-Variante, die in der Single-User-Lizenz mit knapp 590 Euro inklusive Mehrwertsteuer ebenfalls nicht zu teuer ist. (mha)