Abbildung 1: Auf der y-Achse trägt Tsung in diesem Report die Transaktionsdauer pro Abruf ein, auf der x-Achse den zeitlichen Ablauf des Benchmark.

Wie vielen Usern hält die Datenbank stand? Wann wirft ein CMS das Handtuch? Um Leistungsgrenzen auszuloten, missbraucht Charly Kühnast nicht die im Grunde produktiv gestimmten Anwender als Betatester, sondern lieber den Lastgenerator Tsung.

Wenn ich testen möchte, wie viel Last ein (vielleicht sogar verteiltes) System verträgt, setze ich einen Lastgenerator in Gang. Vor längerer Zeit hatte ich in meiner Kolumne bereits Siege [1] gelobt, den ich auch weiterhin für einen guten Dauertrommler halte. Die meisten Lastgeneratoren feuern aber nur unrealistisch aus allen Rohren und simulieren nicht das Verhalten einer echten Userschaft. Das kann Tsung [2] besser.

Die Software entstand in mehreren Evolutionsschritten aus einem Tool, das Lasttests gegen Jabber-XMPP-Server fuhr. Unter dem zerstörerischen Namen IDX-Tsunami bekam es noch Multiprotokoll-Fähigkeiten verpasst. Seit 2014 ist die Entwicklung bei IDX-Tsunami abgeebbt. Tsung hat sich einfach des Fundaments bemächtigt und macht auf Tsunamis Codebasis weiter.

XMPP gehört immer noch zu den Diensten, mit denen Tsung bei seinen Test-Servern für Unruhe sorgen kann. Hinzugesellt haben sich HTTP mit und ohne TLS, Webdav, SOAP, PostgreSQL, MySQL, AMQP, MQTT und LDAP. Alle Protokolle sind über eine Plugin-Engine eingebunden, also können jederzeit weitere folgen.

Per XML den Angriff planen

Über XML-Konfigurationsdateien gestaltet der Tsung-Benutzer seine Lasttest-Szenarien im Detail. Hier konfiguriert er zum Beispiel, dass die Requests nicht nur von einer Maschine ausgehen, sondern mehrere Lastgeneratoren (Clients genannt) ein stressendes Konzert spielen sollen. Unterschiedlich starken Clients darf ich mittels einer Gewichtung mehr oder weniger Arbeit aufbürden. Ebenso kann ich auf der Gegenseite mehrere Backendserver konfigurieren. Bei den Verbindungen sind IPv4 und IPv6 erlaubt, auch gemischt.

Die Einzelheiten der Anfragen, mit denen Tsung die Server stresst, lassen sich in weiten Grenzen konfigurieren. Um etwa ein realistisches Nutzerverhalten zu simulieren, traktiert die Software auf Wunsch die Server nicht mit Dauerfeuer, sondern legt sinnvoll gestaltete Pausen ein, wie sie auch ein menschlicher Nutzer machen würde, wenn er den Inhalt einer Webseite betrachtet und danach weiterklickt.

Aufnahme-Zentrum

Wer es noch realistischer möchte, benutzt den mitgelieferten Recorder: Der zeichnet nach seinem Start das Verhalten eines oder mehrerer Nutzer auf und Tsung repliziert diese Session später. Dabei kann man Variablen ins Spiel bringen, etwa wenn simulierte User Eingaben in eine Suchmaske tätigen.

Eine Gruppierung von Anfragen kann ich zu einer Transaktion bündeln. Unter dem Begriff versteht Tsung logisch zusammenhängende Anfrage, etwa: Ein Nutzer ruft die Webseite auf, muss sich zum Beispiel per Oauth authentifizieren, ruft dann die Unterseite mit der Suchfunktion auf und schickt eine Suchanfrage ab.

Statistiken geben dem Admin Aufschluss

Neben den ohnehin vorhandenen Auswertungen über das Lastverhalten der Backendserver erzeugt Tsung auch Reports über die Performance solcher Transaktionen (Abbildung 1). Diese Statistiken sind erwartungsgemäß aussagekräftiger für des Verhalten der Systeme im Produktionsbetrieb als synthetische Trommelfeuer-Tests – und genau das ist es, was mir an Tsung so gut gefällt.

Abbildung 1: Auf der y-Achse trägt Tsung in diesem Report die Transaktionsdauer pro Abruf ein, auf der x-Achse den zeitlichen Ablauf des Benchmark.