Blog - gnuheidix

Mit dieser Information kann man dann entscheiden, ob das für den jeweiligen Zweck ausreichend ist, oder ob man die Performance noch weiter optimieren muss. Besonders nachdem man Änderungen vorgenommen hat, sollte ein Lasttest gefahren werden, um zu sehen, ob sich das System diesbezüglich verschlechtert hat.

Brot und Butter

All das, was eine Applikation sehr oft machen muss, hat so wenig Ressourcen wie nur irgend möglich zu verbrauchen. Beispielsweise bei einem Blog muss das Aufrufen von Beiträgen flutschen, damit im Ernstfall hohe Zugriffszahlen bewältigt werden können. Das Erstellen von Kommentaren ist im Vergleich äußerst selten, wodurch man dort nicht so viel Zeit investieren muss.

Wenn die Webapplikation nicht trivial ist, sollte man prüfen, wie sich die meisten Benutzer verhalten. So kann man herausfinden, wo sich Optimierungen am meisten lohnen würden.

Do it yourself

Es gibt eine Menge Werkzeuge, die einem beim Erzeugen von Last unterstützen. Diese können aber nur dann aussagekräftige Ergebnisse liefern, wenn man sie unter Rahmenbedingungen einsetzt, die der realen Nutzung entsprechen.

Folgendes ist zu beachten:

1. Wenn man von Daheim aus Tests durchführt, kann die eigene Internetverbindung eher ausgelastet sein, als das unter Feuer zu nehmende Zielsystem.
2. Wenn man direkt gegen das Produktionssystem testet, darf man sich bei dessen Ausfall nicht beschweren. Ein Testsystem mit einer möglichst der Produktionsumgebung entsprechenden Hardware, Anbindung und einem repräsentativen Datenbestand ist erforderlich.
3. Wenn man das zu testende System über das Loopback-Interface sich selbst belasten lässt, fehlt ein erheblicher Teil der Realität bei der Netzwerkkommunikation. Paketlaufzeiten, das Verlorengehen von Paketen und das lange Offenhalten von Verbindungen langsamer weit entfernter Clients; Weiter verfälscht man das Ergebnis, weil die Lasterzeugung selbst auch Last erzeugt.
   

Siege

Mit Siege kann man zusammenhanglose GET und POST HTTP-Anfragen absetzen. Externe Ressourcen wie Bilder usw. werden dabei nicht nachgeladen. Mit dem folgenden Befehl wird beispielsweise die Startseite dieses Blogs von 50 simulierten Benutzern abgefragt und dies für zehn Sekunden lang mit jeweils einer Sekunde Wartezeit zwischen der jeweiligen Benutzerabfrage.

$ siege http://gnuheidix.de/ -d1 -c50 -t10s
** SIEGE 3.0.5
** Preparing 50 concurrent users for battle.
The server is now under siege...
HTTP/1.1 200   0.04 secs:    3430 bytes ==> GET  /
HTTP/1.1 200   0.06 secs:    3430 bytes ==> GET  /
:
:
Lifting the server siege...      done.

Transactions:		         857 hits
Availability:		      100.00 %
Elapsed time:		        9.82 secs
Data transferred:	        2.80 MB
Response time:		        0.05 secs
Transaction rate:	       87.27 trans/sec
Throughput:		        0.29 MB/sec
Concurrency:		        4.78
Successful transactions:         857
Failed transactions:	           0
Longest transaction:	        0.15
Shortest transaction:	        0.04

Die Auswertung des Testlaufs ist informativ, spiegelt aber wie gesagt nur die der Startseite alleine wider. Dies lässt dadurch keine Aussage über die Zugriffsfestigkeit zu. Dieser Test ergibt Sinn, wenn die abzufragende Seite bei jeder Anfrage on-the-fly gerendert wird und man wissen möchte, ab welcher Anzahl an gleichzeitigen Zugriffen dieser Prozess in die Knie geht.

Apache JMeter

Im Gegensatz zu Siege kann man sich bei JMeter umfangreiche Testsuites zusammenklicken, bei denen einzelne Aufrufe voneinander abhängen und Prüfungen der Abfrageergebnisse durchgeführt werden. Die Bedienung ist entsprechend der vielen Möglichkeiten kompliziert. Die Hilfefunktion ist allerdings sehr ausführlich und verständlich.

Dave Gardner hat in seinem Blogbeitrag Effective load testing with Apache JMeter gut beschrieben, wie man etwas mehr als nur einen "Hello World" HTTP-Request macht.

Dienstanbieter

Da nicht jeder eine gut angebundene Maschine hat, die zur Erzeugung der Last benutzt werden kann, wurden einige Plattformen entwickelt, die darauf spezialisiert sind, Last auf anderen Systemen zu erzeugen.

Last erzeugt man mit Netzwerktraffic und das kostet Geld. Die meisten Anbieter geben aber ein gewisses Monatskontingent frei.

Blitz

Bei Blitz gibt man eine unter Last zu setzende URL mit ein paar Rahmenbedingungen wie Dauer, simulierter Benutzeranzahl, Anfragenherkunft, Ramp-Up usw. ein und schon bekommt man zwei schicke Graphen und einen kurzen Report über Fehler und Antwortzeiten. Blitz ist mit Siege vergleichbar. Es werden keine externen Ressourcen nachgeladen. Besonders praktisch finde ich, dass man sich von verschiedenen Rechenzentren aus unter Feuer nehmen lassen kann.

Load Impact

Etwas mehr als Blitz kann Load Impact. Dort werden alle Ressourcen nachgeladen und man kann sich Benutzungsszenarios zusammenbauen. Dies kann man in einer Art Skript machen oder Klickpfade direkt im Browser aufzeichnen lassen. Es ist sogar möglich, die Anfragen aus Rechenzentren verschiedener Länder gleichzeitig kommen zu lassen. Am Ende gibt es einen verlinkbaren Report. Die Möglichkeiten kommen zwar bei weitem nicht an JMeter heran, aber für die meisten Zwecke dürfte es ausreichen.

Fazit

Lasttests gehören einfach in den Entwicklungsprozess einer jeden guten Webapplikation. Dabei ist es egal, ob es ein Blog, ein Shop, eine Kommunikationsplattform oder ein API ist. Habt bei Euren Tests stets genügend Monitoring auf das zu testende System ausgerichtet, um herausfinden zu können, an welcher Stelle der Applikation Probleme auftauchen. Falls Ihr das nicht macht, ist die Findung von Verbesserungsansätzen reines Rätselraten.

Nachtrag vom 04.01.2014

Bei Blitz kann man nun bis zu vier URLs angeben, die beim Testlauf auch abgerufen werden sollen. So könnte man also im Falle eines Blogs die Startseite laden, einen Beitrag aufrufen und einen Kommentar schreiben. Auf einen sehr kurzen Report kann man sogar verlinken. Dessen Informationsgehalt ist gering, aber zum Angeben reicht es.

Nachtrag vom 09.08.2016

Seit der Version 4.0.0 von Siege ist die Option parser zur siegerc hinzugekommen. Diese standardmäßig aktivierte Funktionalität parst das geladene HTML und fügt nun auch Bilder, Stylesheets, Skripte,... mit zur Liste der URLs hinzu, die abfragt werden.