Tool reviews

Tsung load testing: a review of the Erlang tool

6 min read

Tsung is an open source load testing tool written in Erlang that describes each test in an XML file and can spread the load over many client machines. Tsung load testing still makes sense for protocols few tools cover, such as XMPP, LDAP or PostgreSQL at the wire level, and for very large user counts on modest hardware. Tsung’s last release came out in March 2023, so for new HTTP or API work most teams are better served by k6, Gatling or JMeter.

We have not run Tsung for this review. The facts come from Tsung’s documentation and GitHub repository, checked on 21 October 2026, and the judgements are ours.

TopicTsung
LicenceGPL-2.0
Written inErlang (needs Erlang/OTP R16B03 or later)
Latest release1.8.0 (2 March 2023)
Tests written asXML configuration files
Load modelNew users per arrival phase (open)
ProtocolsHTTP, WebDAV, XMPP, PostgreSQL, MySQL, LDAP, WebSocket, AMQP, MQTT, raw TCP/UDP (some experimental)
Scaling outClient machines over passwordless SSH
ReportsLive dashboard on port 8091, tsung_stats.pl HTML report

Who maintains Tsung, and is it still active?

ProcessOne hosts the project on GitHub under GPL-2.0. It is maintained but quiet: the last release, 1.8.0, is from March 2023, and changes since then are occasional merged pull requests.

The repository shows its most recent commit on 2 March 2026, a pull request that replaces deprecated calls, and the v1.8.0 tag is dated 2 March 2023 (checked on 21 October 2026). The documentation still carries the 1.7.0 title, so check the repository when a detail looks out of date. A quiet project also means fewer answers when something goes wrong.

How does a Tsung test work?

A test is one XML file with four main parts: the client machines, the target servers, the load phases and the user sessions. Each new user picks a session by its probability and runs its requests in order.

This fragment starts five new users a second for ten minutes, and each user loads a product list, pauses about two seconds and posts to a cart:

<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>

The sessions page says the session probabilities must add up to 100 (or, since 1.5.0, you can use weights), and that a random think time follows an exponential distribution around its value unless you give a min and max range (checked on 21 October 2026). For HTTP and PostgreSQL there is a proxy recorder that turns a browser or client session into this XML.

What load model does Tsung use?

An open model. Each arrival phase starts new users at a set interval or rate, whatever the users already running are doing, and a phase ends when its time is up even if its sessions have not finished.

The load page lists the controls: interarrival or arrivalrate per phase, maxnumber to cap the users a phase starts, a duration on the whole load to stop the test at a fixed time, and wait_all_sessions_end to hold the next phase until the current users finish (checked on 21 October 2026). Our articles on the open vs closed workload model and on think time explain how those choices change what a test measures.

Which protocols can Tsung test?

More than most load testing tools: HTTP (including SOAP), WebDAV, XMPP, PostgreSQL, MySQL, LDAP, WebSocket, AMQP, MQTT and raw TCP, UDP or SSL. The documentation marks the MySQL, WebSocket, AMQP and MQTT plugins as experimental, with AMQP 0.9.1 and MQTT 3.1 only.

The features page describes each plugin (checked on 21 October 2026). XMPP and PostgreSQL are where Tsung has long had few rivals: it speaks the protocol itself, so you test the server rather than a client library. For real-time apps, our roundup of WebSocket load testing tools puts Tsung next to newer options.

How do you scale a Tsung test across machines?

You list the client machines in the XML, and the controller starts the load on them over SSH without a password, or rsh. Each client can take a weight, a user limit and a CPU count.

The clients and server page explains that Tsung runs one Erlang virtual machine per CPU you declare with cpu on each client (one by default) and starts a new one when a VM reaches maxusers. It can also take client machines from a batch scheduler such as PBS, LSF or OAR. The installation page lists Erlang/OTP R16B03 or later, plus optional Perl 5 and gnuplot, or Python and matplotlib, for the graphs (checked on 21 October 2026).

LoadFocus, which publishes this site, does not run Tsung files. It runs JMeter test plans and k6 scripts from 25 cloud regions.

How do you read Tsung results?

Two ways: a live dashboard served by the controller on port 8091, and an HTML report built after the run with the tsung_stats.pl script.

The reports page says the dashboard has existed since 1.6.0, shows the current status and builds graphs while the test runs, and stops when the test ends unless you start Tsung with -k (checked on 21 October 2026). The report covers response and connection times, transactions, requests per second and error codes, and can include server CPU, memory and network figures collected through Erlang agents, SNMP or munin. The documentation describes no pass/fail threshold, so a CI pipeline has to parse the results itself; our guide to load test pass/fail criteria covers what to check.

What does Tsung do well, and where are its limits?

It is strong on protocol breadth, open-model arrival phases and many users per machine, which the documentation puts at thousands per CPU. Its limits are a quiet release history, XML-only scripting and no built-in pass/fail checks.

  • XMPP, LDAP and wire-level database tests without writing client code.
  • Distribution over plain SSH, with no broker or extra service.
  • Server monitoring in the same report.
  • Logic beyond the XML means Erlang, which few teams write.
  • Erlang must be installed on the controller and every client.

When should you choose k6, Gatling or JMeter instead?

Choose another tool when you test HTTP or APIs and want an active project with scripts in a mainstream language.

Choose k6 instead for JavaScript scripts with thresholds built into the script and an active project (checked on 21 October 2026). Choose Gatling instead for code-first simulations on the JVM; our Gatling review covers it. Choose JMeter instead when testers want a GUI or you need JDBC, JMS or LDAP samplers with a large plugin ecosystem. LoadFocus runs JMeter and k6 from 25 cloud regions, and the open source load testing tools overview sets these tools side by side.

FAQ

Is Tsung still maintained? Yes, but quietly. The latest release, 1.8.0, came out on 2 March 2023, and the repository still receives occasional merged changes, most recently in March 2026.

Which protocols does Tsung support? HTTP and SOAP, WebDAV, XMPP, PostgreSQL, LDAP and raw TCP, UDP or SSL, plus MySQL, WebSocket, AMQP and MQTT, which the documentation marks as experimental.

Can LoadFocus run Tsung tests? No. LoadFocus runs JMeter test plans and k6 scripts. To spread a Tsung test over several machines, list them as clients in the XML file.


The technical claims in this article have not been independently reviewed.

LoadFocus team
Written by the LoadFocus team, the people behind a cloud load testing service.