Pruebas de carga con Tsung: la herramienta Erlang a fondo

Tsung es una herramienta de pruebas de carga open source escrita en Erlang que describe cada prueba en un archivo XML y puede repartir la carga entre muchas máquinas cliente. Las pruebas de carga con Tsung siguen teniendo sentido para protocolos que cubren pocas herramientas, como XMPP, LDAP o PostgreSQL a nivel de protocolo, y para muchísimos usuarios con hardware modesto. La última versión de Tsung salió en marzo de 2023, así que para pruebas nuevas de HTTP o de API a la mayoría de los equipos les irá mejor con k6, Gatling o JMeter.

No hemos ejecutado Tsung para este análisis. Los datos salen de la documentación y del repositorio de GitHub de Tsung, comprobados el 21 de octubre de 2026, y las valoraciones son nuestras.

¿Quién mantiene Tsung y sigue activo el proyecto?

ProcessOne aloja el proyecto en GitHub con licencia GPL-2.0. Se mantiene, pero con poco movimiento: la última versión, la 1.8.0, es de marzo de 2023, y desde entonces solo llegan de vez en cuando pull requests fusionadas.

El repositorio muestra su último commit el 2 de marzo de 2026, una pull request que sustituye llamadas obsoletas, y el tag v1.8.0 tiene fecha del 2 de marzo de 2023 (comprobado el 21 de octubre de 2026). La documentación todavía lleva el título 1.7.0, así que revisa el repositorio cuando un detalle parezca desfasado. Un proyecto tranquilo también significa menos respuestas cuando algo sale mal.

¿Cómo funciona una prueba de Tsung?

Una prueba es un archivo XML con cuatro partes principales: las máquinas cliente, los servidores de destino, las fases de carga y las sesiones de usuario. Cada usuario nuevo elige una sesión según su probabilidad y ejecuta sus peticiones en orden.

Este fragmento lanza cinco usuarios nuevos por segundo durante diez minutos; cada uno carga una lista de productos, hace una pausa de unos dos segundos y envía una petición POST al carrito:

<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 página de sesiones dice que las probabilidades de las sesiones deben sumar 100 (desde la 1.5.0 también valen pesos) y que un tiempo de reflexión aleatorio sigue una distribución exponencial alrededor de su valor, salvo que indiques un rango con min y max (comprobado el 21 de octubre de 2026). Para HTTP y PostgreSQL hay un grabador proxy que convierte una sesión de navegador o de cliente en este XML.

¿Qué modelo de carga usa Tsung?

Un modelo de carga abierto. Cada fase de llegada lanza usuarios nuevos a un intervalo o una tasa fijos, hagan lo que hagan los usuarios que ya están en marcha, y una fase termina cuando se acaba su tiempo aunque sus sesiones no hayan terminado.

La página de carga recoge los controles: interarrival o arrivalrate por fase, maxnumber para limitar los usuarios que lanza una fase, un atributo duration sobre toda la carga para detener la prueba a una hora fija, y wait_all_sessions_end para que la fase siguiente espere a que terminen los usuarios actuales (comprobado el 21 de octubre de 2026). Nuestros artículos sobre el modelo de carga abierto vs cerrado y sobre el tiempo de reflexión explican cómo esas decisiones cambian lo que mide una prueba.

¿Qué protocolos puede probar Tsung?

Más que la mayoría de las herramientas de pruebas de carga: HTTP (incluido SOAP), WebDAV, XMPP, PostgreSQL, MySQL, LDAP, WebSocket, AMQP, MQTT y TCP, UDP o SSL en bruto. La documentación marca como experimentales los plugins de MySQL, WebSocket, AMQP y MQTT, con AMQP solo en 0.9.1 y MQTT solo en 3.1.

La página de funciones describe cada plugin (comprobado el 21 de octubre de 2026). En XMPP y PostgreSQL Tsung lleva mucho tiempo con pocos rivales: habla el protocolo por sí mismo, así que pruebas el servidor y no una biblioteca cliente. Para aplicaciones en tiempo real, nuestro repaso de herramientas de pruebas de carga WebSocket pone a Tsung junto a opciones más recientes.

¿Cómo se reparte una prueba de Tsung entre varias máquinas?

Enumeras las máquinas cliente en el XML, y el controlador lanza la carga en ellas por SSH sin contraseña, o por rsh. A cada cliente se le puede dar un peso, un límite de usuarios y un número de CPU.

La página de clientes y servidor explica que Tsung ejecuta una máquina virtual de Erlang por cada CPU que declares con cpu en cada cliente (una por defecto) y arranca una nueva cuando una VM llega a maxusers. También puede tomar las máquinas cliente de un planificador de lotes como PBS, LSF u OAR. La página de instalación pide Erlang/OTP R16B03 o posterior y, de forma opcional, Perl 5 y gnuplot, o Python y matplotlib, para los gráficos (comprobado el 21 de octubre de 2026).

LoadFocus, que publica este sitio, no ejecuta archivos de Tsung. Ejecuta planes de prueba JMeter y scripts de k6 desde 25 regiones en la nube.

¿Cómo se leen los resultados de Tsung?

De dos maneras: con un panel en vivo que sirve el controlador en el puerto 8091 y con un informe HTML que genera el script tsung_stats.pl después de la ejecución.

La página de informes dice que el panel existe desde la 1.6.0, muestra el estado actual, construye los gráficos mientras corre la prueba y se detiene cuando la prueba termina, salvo que arranques Tsung con -k (comprobado el 21 de octubre de 2026). El informe cubre tiempos de respuesta y de conexión, transacciones, peticiones por segundo y códigos de error, y puede incluir datos de CPU, memoria y red de los servidores, recogidos con agentes de Erlang, SNMP o munin. La documentación no describe ningún umbral de aprobación, así que un pipeline de CI tiene que analizar los resultados por su cuenta; nuestra guía de criterios de aprobación en pruebas de carga explica qué revisar.

¿Qué hace bien Tsung y dónde están sus límites?

Es fuerte en variedad de protocolos, fases de llegada abiertas y muchos usuarios por máquina, que la documentación cifra en miles por CPU. Sus límites son un historial de versiones con poco movimiento, scripts solo en XML y ninguna comprobación de aprobación integrada.

• Pruebas de XMPP, LDAP y bases de datos a nivel de protocolo, sin escribir código cliente.
• Reparto por SSH sin más, sin broker ni servicio adicional.
• Monitorización de los servidores en el mismo informe.
• Cualquier lógica más allá del XML exige Erlang, que pocos equipos escriben.
• Erlang tiene que estar instalado en el controlador y en cada cliente.

¿Cuándo elegir k6, Gatling o JMeter en lugar de Tsung?

Elige otra herramienta cuando pruebes HTTP o API y quieras un proyecto activo con scripts en un lenguaje habitual.

Elige k6 para scripts en JavaScript con umbrales dentro del propio script y un proyecto activo (comprobado el 21 de octubre de 2026). Elige Gatling para simulaciones basadas en código sobre la JVM; nuestro análisis de Gatling lo explica a fondo. Elige JMeter si tus testers quieren una interfaz gráfica o necesitas samplers JDBC, JMS o LDAP con un gran ecosistema de plugins. LoadFocus ejecuta JMeter y k6 desde 25 regiones en la nube, y el repaso de herramientas de pruebas de carga open source compara estas herramientas.

FAQ

¿Tsung sigue teniendo mantenimiento? Sí, aunque con poco movimiento. La última versión, la 1.8.0, salió el 2 de marzo de 2023, y el repositorio todavía recibe de vez en cuando cambios fusionados, el último en marzo de 2026.

¿Qué protocolos admite Tsung? HTTP y SOAP, WebDAV, XMPP, PostgreSQL, LDAP y TCP, UDP o SSL en bruto, además de MySQL, WebSocket, AMQP y MQTT, que la documentación marca como experimentales.

¿Puede LoadFocus ejecutar pruebas de Tsung? No. LoadFocus ejecuta planes de prueba JMeter y scripts de k6. Para repartir una prueba de Tsung entre varias máquinas, enuméralas como clientes en el archivo XML.

Lecturas relacionadas

• Herramientas de pruebas de carga WebSocket: seis opciones
• Herramientas de pruebas de carga open source: seis opciones
• Modelo de carga abierto vs cerrado: cuál usar y cuándo
• Pruebas de carga con Gatling: la herramienta JVM a fondo
• Pruebas de carga con NBomber: análisis del framework .NET
• pgbench: benchmark y pruebas de carga de PostgreSQL
• Cómo usar sysbench: benchmarks de CPU, disco y MySQL

Las afirmaciones técnicas de este artículo no se han revisado de forma independiente.