Tsung-Lasttests: das Erlang-Tool im Überblick

Tsung ist ein in Erlang geschriebenes Open-Source-Lasttest-Tool, das jeden Test in einer XML-Datei beschreibt und die Last auf viele Client-Maschinen verteilen kann. Ein Tsung-Lasttest ist weiterhin sinnvoll für Protokolle, die wenige Tools abdecken, etwa XMPP, LDAP oder PostgreSQL auf Protokollebene, und für sehr viele Benutzer auf bescheidener Hardware. Die letzte Version erschien im März 2023; für neue HTTP- oder API-Tests sind die meisten Teams daher mit k6, Gatling oder JMeter besser bedient.

Wir haben Tsung für dieses Review nicht selbst ausgeführt. Die Fakten stammen aus der Dokumentation und dem GitHub-Repository von Tsung, geprüft am 21. Oktober 2026; die Einschätzungen sind unsere eigenen.

Wer pflegt Tsung, und ist es noch aktiv?

ProcessOne hostet das Projekt unter GPL-2.0 auf GitHub. Es wird gepflegt, ist aber ruhig geworden: Die letzte Version, 1.8.0, stammt vom März 2023, und seither kommen nur gelegentlich zusammengeführte Pull Requests hinzu.

Das Repository zeigt den letzten Commit am 2. März 2026, einen Pull Request, der veraltete Aufrufe ersetzt, und der Tag v1.8.0 ist auf den 2. März 2023 datiert (geprüft am 21. Oktober 2026). Die Dokumentation trägt noch den Titel 1.7.0; prüfen Sie also das Repository, wenn ein Detail veraltet wirkt. Ein ruhiges Projekt bedeutet allerdings weniger Antworten, wenn etwas schiefgeht.

Wie funktioniert ein Tsung-Test?

Ein Test ist eine XML-Datei mit vier Hauptteilen: Client-Maschinen, Zielserver, Lastphasen und Benutzersitzungen. Jeder neue Benutzer wählt eine Sitzung nach ihrer Wahrscheinlichkeit und führt deren Anfragen der Reihe nach aus.

Dieser Ausschnitt startet zehn Minuten lang fünf neue Benutzer pro Sekunde; jeder lädt eine Produktliste, pausiert etwa zwei Sekunden und sendet dann eine POST-Anfrage an den Warenkorb:

<load>
  <arrivalphase phase="1" duration="10" unit="minute">
    <users arrivalrate="5" unit="second"/>
  </arrivalphase>
</load>
<sessions>
  <session name="browse" probability="100"
           type="ts_http">
    <request><http url="/products" method="GET"/></request>
    <thinktime value="2" random="true"/>
    <request><http url="/cart" method="POST"
                   contents="sku=A-100"/></request>
  </session>
</sessions>

Die Seite zu Sitzungen sagt, dass sich die Wahrscheinlichkeiten der Sitzungen zu 100 addieren müssen (seit 1.5.0 gehen auch Gewichte) und dass eine zufällige Think Time einer Exponentialverteilung um ihren Wert folgt, sofern Sie keinen Bereich mit min und max angeben (geprüft am 21. Oktober 2026). Für HTTP und PostgreSQL gibt es einen Proxy-Recorder, der eine Browser- oder Client-Sitzung in dieses XML übersetzt.

Welches Lastmodell nutzt Tsung?

Ein offenes Lastmodell. Jede Ankunftsphase startet neue Benutzer in festem Abstand oder mit fester Rate, egal was die bereits laufenden Benutzer tun, und eine Phase endet, wenn ihre Zeit abgelaufen ist, auch wenn ihre Sitzungen noch nicht fertig sind.

Die Seite zur Last nennt die Stellschrauben: interarrival oder arrivalrate pro Phase, maxnumber als Obergrenze für die Benutzer, die eine Phase startet, ein duration-Attribut für die gesamte Last, um den Test zu einer festen Zeit zu beenden, und wait_all_sessions_end, damit die nächste Phase wartet, bis die aktuellen Benutzer fertig sind (geprüft am 21. Oktober 2026). Unsere Artikel zum offenen vs geschlossenen Lastmodell und zur Think Time erklären, wie diese Entscheidungen verändern, was ein Test misst.

Welche Protokolle kann Tsung testen?

Mehr als die meisten Lasttest-Tools: HTTP (einschließlich SOAP), WebDAV, XMPP, PostgreSQL, MySQL, LDAP, WebSocket, AMQP, MQTT sowie reines TCP, UDP oder SSL. Die Dokumentation kennzeichnet die Plugins für MySQL, WebSocket, AMQP und MQTT als experimentell, AMQP nur in 0.9.1 und MQTT nur in 3.1.

Die Seite zu den Funktionen beschreibt jedes Plugin (geprüft am 21. Oktober 2026). Bei XMPP und PostgreSQL hatte Tsung lange wenige Konkurrenten: Es spricht das Protokoll selbst, Sie testen also den Server und nicht eine Client-Bibliothek. Für Echtzeit-Apps stellt unser Überblick über WebSocket-Lasttest-Tools Tsung neben neuere Optionen.

Wie verteilen Sie einen Tsung-Test auf mehrere Maschinen?

Sie listen die Client-Maschinen im XML auf, und der Controller startet die Last auf ihnen über SSH ohne Passwort oder über rsh. Jeder Client kann ein Gewicht, eine Benutzergrenze und eine CPU-Zahl erhalten.

Die Seite zu Clients und Server erklärt, dass Tsung auf jedem Client eine virtuelle Erlang-Maschine pro mit cpu angegebener CPU betreibt (standardmäßig eine) und eine neue startet, wenn eine VM maxusers erreicht. Client-Maschinen kann es auch von einem Batch-Scheduler wie PBS, LSF oder OAR übernehmen. Die Installationsseite nennt Erlang/OTP R16B03 oder neuer, dazu optional Perl 5 und gnuplot oder Python und matplotlib für die Grafiken (geprüft am 21. Oktober 2026).

LoadFocus, der Herausgeber dieser Website, führt keine Tsung-Dateien aus. LoadFocus führt JMeter-Testpläne und k6-Skripte aus 25 Cloud-Regionen aus.

Wie lesen Sie Tsung-Ergebnisse?

Auf zwei Wegen: über ein Live-Dashboard, das der Controller auf Port 8091 bereitstellt, und über einen HTML-Bericht, den das Skript tsung_stats.pl nach dem Lauf erzeugt.

Laut Seite zu den Berichten gibt es das Dashboard seit 1.6.0; es zeigt den aktuellen Status, erstellt Grafiken während des Tests und stoppt mit dem Testende, außer Sie starten Tsung mit -k (geprüft am 21. Oktober 2026). Der Bericht umfasst Antwort- und Verbindungsaufbauzeiten, Transaktionen, Anfragen pro Sekunde und Fehlercodes und kann CPU-, Speicher- und Netzwerkwerte der Server enthalten, gesammelt über Erlang-Agenten, SNMP oder munin. Einen Pass/Fail-Schwellenwert beschreibt die Dokumentation nicht, eine CI-Pipeline muss die Ergebnisse also selbst auswerten; unser Leitfaden zu Pass/Fail-Kriterien für Lasttests zeigt, was zu prüfen ist.

Was kann Tsung gut, und wo liegen seine Grenzen?

Stark ist es bei der Protokollbreite, bei offenen Ankunftsphasen und bei vielen Benutzern pro Maschine, laut Dokumentation Tausende pro CPU. Seine Grenzen sind eine ruhige Versionsgeschichte, Skripte nur in XML und keine eingebauten Pass/Fail-Prüfungen.

• XMPP-, LDAP- und Datenbanktests auf Protokollebene, ohne Client-Code zu schreiben.
• Verteilung über einfaches SSH, ohne Broker oder Zusatzdienst.
• Servermonitoring im selben Bericht.
• Logik jenseits des XML bedeutet Erlang, das nur wenige Teams schreiben.
• Erlang muss auf dem Controller und auf jedem Client installiert sein.

Wann sollten Sie stattdessen k6, Gatling oder JMeter wählen?

Wählen Sie ein anderes Tool, wenn Sie HTTP oder APIs testen und ein aktives Projekt mit Skripten in einer verbreiteten Sprache wollen.

Wählen Sie k6 für JavaScript-Skripte mit im Skript eingebauten Schwellenwerten und ein aktives Projekt (geprüft am 21. Oktober 2026). Wählen Sie Gatling für Code-first-Simulationen auf der JVM; unser Gatling-Review behandelt es. Wählen Sie JMeter, wenn Tester eine GUI wollen oder Sie JDBC-, JMS- oder LDAP-Sampler mit einem großen Plugin-Ökosystem brauchen. LoadFocus führt JMeter und k6 aus 25 Cloud-Regionen aus, und der Überblick über Open-Source-Lasttest-Tools stellt diese Tools nebeneinander.

FAQ

Wird Tsung noch gepflegt? Ja, aber selten. Die letzte Version, 1.8.0, erschien am 2. März 2023, und das Repository erhält weiterhin gelegentlich zusammengeführte Änderungen, zuletzt im März 2026.

Welche Protokolle unterstützt Tsung? HTTP und SOAP, WebDAV, XMPP, PostgreSQL, LDAP und reines TCP, UDP oder SSL, dazu MySQL, WebSocket, AMQP und MQTT, die die Dokumentation als experimentell kennzeichnet.

Kann LoadFocus Tsung-Tests ausführen? Nein. LoadFocus führt JMeter-Testpläne und k6-Skripte aus. Um einen Tsung-Test auf mehrere Maschinen zu verteilen, listen Sie diese als Clients in der XML-Datei auf.

Weiterlesen

• WebSocket-Lasttest-Tools: sechs Optionen im Vergleich
• Open-Source-Lasttest-Tools: sechs Optionen im Überblick
• Offenes vs geschlossenes Lastmodell: welches passt wann?
• Gatling-Lasttests: das JVM-Tool im Überblick
• NBomber-Lasttests: das .NET-Framework im Überblick
• pgbench: PostgreSQL benchmarken und unter Last testen
• sysbench nutzen: CPU-, Festplatten- und MySQL-Benchmarks

Die technischen Aussagen in diesem Artikel wurden nicht unabhängig geprüft.