If I want to test how much load a (perhaps even distributed) system can take, I launch a load generator. Some time ago, I praised Siege [1] in my column, which I still consider to be a good barrage tool. However, most load generators fire unrealistically from all barrels and do not simulate the behavior of a real user. Tsung [2] can do this better.

Tsung evolved in several evolutionary steps from a tool that ran load tests against Jabber/XMPP servers. Under the fear-inspiring name of idx-Tsunami, it was given multiprotocol capabilities. Since 2014, the development of idx-Tsunami has petered out. Tsung has simply taken the basis and continued developing Tsunami's codebase.

XMPP is still one of the services that Tsung can deploy to cause unrest on its test servers. On top of this, Tsung supports HTTP with and without TLS, WebDAV, SOAP, PostgreSQL, MySQL, AMQP, MQTT, and LDAP. All protocols are integrated via a plugin engine, so further protocols can follow at any time.

Planning the Attack Using XML

Using XML configuration files, the Tsung user designs their load test scenarios in detail. For example, you can stipulate that the requests should not only originate from one machine, but that several load generators (or clients) should play a key role. I can assign more or less work to clients with different performance characteristics by using weighting. I can also configure several back-end servers. IPv4 and IPv6 are allowed for the connections, also in mixed mode.

The details of the requests that Tsung uses to stress the servers can be configured within a wide range. In order to simulate realistic user behavior, the software does not torment the servers with constant fire on request, but instead makes well-planned pauses, just as a human user would if he or she were looking at the content of a website and then clicking on it.

Reception Center

If you want to make it even more realistic, use the supplied recorder: After starting, it records the behavior of one or more users, and Tsung replicates this session later. For example, variables can be brought into play when simulated users enter data in a search mask.

I can bundle a group of requests into one transaction. Tsung understands this term as a logically related request, for example: A user calls the website, authenticates themselves (say, using OAuth), then accesses the sub-page using the search function, and submits a search query.

Statistics Reveal All to the Administrator

In addition to the existing evaluations of the load behavior for the back-end servers, Tsung also generates reports on the performance of such transactions (Figure 1). These statistics are, as expected, more useful for the behavior of the systems in production than synthetic flak tests – and that's exactly what I like about Tsung.

Figure 1: In this report, Tsung has the transaction time per call on the y axis and the sequence of the benchmark on the x axis.