Test de charge Tsung : l'outil Erlang passé en revue

21 octobre 2026 7 min de lecture

Tsung est un outil de test de charge open source écrit en Erlang, qui décrit chaque test dans un fichier XML et peut répartir la charge sur de nombreuses machines clientes. Le test de charge avec Tsung garde du sens pour des protocoles que peu d’outils couvrent, comme XMPP, LDAP ou PostgreSQL au niveau du protocole, et pour un très grand nombre d’utilisateurs sur du matériel modeste. La dernière version de Tsung date de mars 2023 : pour de nouveaux tests HTTP ou d’API, la plupart des équipes seront mieux servies par k6, Gatling ou JMeter.

Nous n’avons pas exécuté Tsung pour cette revue. Les faits proviennent de la documentation et du dépôt GitHub de Tsung, vérifiés le 21 octobre 2026, et les appréciations sont les nôtres.

Sujet	Tsung
Licence	GPL-2.0
Écrit en	Erlang (nécessite Erlang/OTP R16B03 ou plus récent)
Dernière version	1.8.0 (2 mars 2023)
Tests écrits en	Fichiers de configuration XML
Modèle de charge	Nouveaux utilisateurs par phase d’arrivée (ouvert)
Protocoles	HTTP, WebDAV, XMPP, PostgreSQL, MySQL, LDAP, WebSocket, AMQP, MQTT, TCP/UDP bruts (en partie expérimentaux)
Montée en échelle	Machines clientes via SSH sans mot de passe
Rapports	Tableau de bord en direct sur le port 8091, rapport HTML avec `tsung_stats.pl`

Qui maintient Tsung, et le projet est-il encore actif ?

ProcessOne héberge le projet sur GitHub sous GPL-2.0. Il est maintenu mais calme : la dernière version, la 1.8.0, date de mars 2023, et depuis il ne reçoit que des pull requests fusionnées de temps en temps.

Le dépôt affiche un dernier commit le 2 mars 2026, une pull request qui remplace des appels dépréciés, et le tag v1.8.0 est daté du 2 mars 2023 (vérifié le 21 octobre 2026). La documentation porte encore le titre 1.7.0 : vérifiez le dépôt quand un détail paraît daté. Un projet calme veut aussi dire moins de réponses quand quelque chose se passe mal.

Comment fonctionne un test Tsung ?

Un test est un fichier XML en quatre parties principales : les machines clientes, les serveurs cibles, les phases de charge et les sessions utilisateur. Chaque nouvel utilisateur choisit une session selon sa probabilité et exécute ses requêtes dans l’ordre.

Cet extrait lance cinq nouveaux utilisateurs par seconde pendant dix minutes ; chacun charge une liste de produits, marque une pause d’environ deux secondes puis envoie une requête POST au panier :

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

La page des sessions indique que les probabilités des sessions doivent totaliser 100 (ou, depuis la 1.5.0, que l’on peut utiliser des poids), et qu’un temps de réflexion aléatoire suit une loi exponentielle autour de sa valeur, sauf si vous donnez une plage min et max (vérifié le 21 octobre 2026). Pour HTTP et PostgreSQL, un enregistreur proxy transforme une session de navigateur ou de client en ce XML.

Quel modèle de charge Tsung utilise-t-il ?

Un modèle de charge ouvert. Chaque phase d’arrivée lance de nouveaux utilisateurs à intervalle ou à taux fixé, quoi que fassent les utilisateurs déjà en cours, et une phase se termine quand son temps est écoulé, même si ses sessions ne sont pas finies.

La page de la charge liste les réglages : interarrival ou arrivalrate par phase, maxnumber pour plafonner les utilisateurs lancés par une phase, un attribut duration sur l’ensemble de la charge pour arrêter le test à heure fixe, et wait_all_sessions_end pour que la phase suivante attende la fin des utilisateurs en cours (vérifié le 21 octobre 2026). Nos articles sur le modèle de charge ouvert ou fermé et sur le temps de réflexion expliquent comment ces choix changent ce que mesure un test.

Quels protocoles Tsung peut-il tester ?

Plus que la plupart des outils de test de charge : HTTP (y compris SOAP), WebDAV, XMPP, PostgreSQL, MySQL, LDAP, WebSocket, AMQP, MQTT, ainsi que TCP, UDP ou SSL bruts. La documentation qualifie d’expérimentaux les plugins MySQL, WebSocket, AMQP et MQTT, avec AMQP 0.9.1 et MQTT 3.1 seulement.

La page des fonctionnalités décrit chaque plugin (vérifié le 21 octobre 2026). Sur XMPP et PostgreSQL, Tsung a longtemps eu peu de concurrents : il parle lui-même le protocole, vous testez donc le serveur et non une bibliothèque cliente. Pour les applications temps réel, notre panorama des outils de test de charge WebSocket place Tsung à côté d’options plus récentes.

Comment répartir un test Tsung sur plusieurs machines ?

Vous listez les machines clientes dans le XML, et le contrôleur y lance la charge via SSH sans mot de passe, ou via rsh. Chaque client peut recevoir un poids, une limite d’utilisateurs et un nombre de CPU.

La page clients et serveur explique que Tsung fait tourner une machine virtuelle Erlang par CPU déclaré avec cpu sur chaque client (un seul par défaut) et en démarre une nouvelle quand une VM atteint maxusers. Il peut aussi récupérer ses machines clientes auprès d’un ordonnanceur de lots comme PBS, LSF ou OAR. La page d’installation demande Erlang/OTP R16B03 ou plus récent, plus, en option, Perl 5 et gnuplot, ou Python et matplotlib, pour les graphiques (vérifié le 21 octobre 2026).

LoadFocus, qui publie ce site, n’exécute pas de fichiers Tsung. LoadFocus exécute des plans de test JMeter et des scripts k6 depuis 25 régions cloud.

Comment lire les résultats de Tsung ?

De deux façons : avec un tableau de bord en direct servi par le contrôleur sur le port 8091, et avec un rapport HTML généré après l’exécution par le script tsung_stats.pl.

La page des rapports indique que le tableau de bord existe depuis la 1.6.0, montre l’état courant, construit les graphiques pendant le test et s’arrête à la fin du test, sauf si vous lancez Tsung avec -k (vérifié le 21 octobre 2026). Le rapport couvre les temps de réponse et de connexion, les transactions, les requêtes par seconde et les codes d’erreur, et peut inclure les mesures CPU, mémoire et réseau des serveurs, collectées par des agents Erlang, SNMP ou munin. La documentation ne décrit pas de seuil de réussite : un pipeline CI doit analyser lui-même les résultats ; notre guide des critères de réussite d’un test de charge dit quoi vérifier.

Quels sont les points forts et les limites de Tsung ?

Il est solide sur l’étendue des protocoles, les phases d’arrivée ouvertes et le nombre d’utilisateurs par machine, que la documentation chiffre en milliers par CPU. Ses limites sont un historique de versions calme, des scripts uniquement en XML et aucun contrôle de réussite intégré.

Tests XMPP, LDAP et bases de données au niveau du protocole, sans écrire de code client.
Répartition par simple SSH, sans broker ni service supplémentaire.
Supervision des serveurs dans le même rapport.
Toute logique au-delà du XML passe par Erlang, que peu d’équipes écrivent.
Erlang doit être installé sur le contrôleur et sur chaque client.

Quand choisir plutôt k6, Gatling ou JMeter ?

Choisissez un autre outil si vous testez du HTTP ou des API et voulez un projet actif, avec des scripts dans un langage répandu.

Choisissez k6 pour des scripts JavaScript avec des seuils intégrés au script et un projet actif (vérifié le 21 octobre 2026). Choisissez Gatling pour des simulations orientées code sur la JVM ; notre revue de Gatling le couvre. Choisissez JMeter si vos testeurs veulent une interface graphique ou si vous avez besoin de samplers JDBC, JMS ou LDAP avec un large écosystème de plugins. LoadFocus exécute JMeter et k6 depuis 25 régions cloud, et le panorama des outils de test de charge open source compare ces outils côte à côte.

FAQ

Tsung est-il encore maintenu ? Oui, mais discrètement. La dernière version, la 1.8.0, est sortie le 2 mars 2023, et le dépôt reçoit encore de temps en temps des changements fusionnés, le dernier en mars 2026.

Quels protocoles Tsung prend-il en charge ? HTTP et SOAP, WebDAV, XMPP, PostgreSQL, LDAP et TCP, UDP ou SSL bruts, plus MySQL, WebSocket, AMQP et MQTT, que la documentation qualifie d’expérimentaux.

LoadFocus peut-il exécuter des tests Tsung ? Non. LoadFocus exécute des plans de test JMeter et des scripts k6. Pour répartir un test Tsung sur plusieurs machines, listez-les comme clients dans le fichier XML.