Teste de carga com Tsung: análise da ferramenta Erlang

O Tsung é uma ferramenta de teste de carga open source escrita em Erlang, que descreve cada teste num arquivo XML e consegue distribuir a carga entre muitas máquinas cliente. O teste de carga com Tsung ainda faz sentido para protocolos que poucas ferramentas cobrem, como XMPP, LDAP ou PostgreSQL no nível do protocolo, e para um número muito grande de usuários em hardware modesto. A última versão saiu em março de 2023, então para testes novos de HTTP ou de API a maioria dos times se sai melhor com k6, Gatling ou JMeter.

Não rodamos o Tsung para esta análise. Os fatos vêm da documentação e do repositório no GitHub do Tsung, conferidos em 21 de outubro de 2026, e as avaliações são nossas.

Quem mantém o Tsung, e ele ainda está ativo?

A ProcessOne hospeda o projeto no GitHub sob GPL-2.0. Ele é mantido, mas com pouco movimento: a última versão, 1.8.0, é de março de 2023, e desde então chegam só pull requests mescladas de vez em quando.

O repositório mostra o commit mais recente em 2 de março de 2026, uma pull request que troca chamadas obsoletas, e a tag v1.8.0 tem data de 2 de março de 2023 (conferido em 21 de outubro de 2026). A documentação ainda traz o título 1.7.0, então confira o repositório quando um detalhe parecer desatualizado. Um projeto calmo também significa menos respostas quando algo dá errado.

Como funciona um teste do Tsung?

Um teste é um arquivo XML com quatro partes principais: as máquinas cliente, os servidores alvo, as fases de carga e as sessões de usuário. Cada novo usuário escolhe uma sessão pela probabilidade dela e executa as requisições em ordem.

Este trecho inicia cinco novos usuários por segundo durante dez minutos; cada um carrega uma lista de produtos, faz uma pausa de uns dois segundos e manda uma requisição POST para o carrinho:

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

A página de sessões diz que as probabilidades das sessões precisam somar 100 (desde a 1.5.0 também dá para usar pesos) e que um tempo de pensamento aleatório segue uma distribuição exponencial em torno do valor, a menos que você informe uma faixa com min e max (conferido em 21 de outubro de 2026). Para HTTP e PostgreSQL existe um gravador proxy que transforma uma sessão de navegador ou de cliente nesse XML.

Que modelo de carga o Tsung usa?

Um modelo de carga aberto. Cada fase de chegada inicia novos usuários num intervalo ou numa taxa fixos, não importa o que os usuários já em execução estejam fazendo, e uma fase termina quando o tempo dela acaba, mesmo que as sessões não tenham terminado.

A página de carga lista os controles: interarrival ou arrivalrate por fase, maxnumber para limitar os usuários que uma fase inicia, um duration na carga inteira para parar o teste num horário fixo, e wait_all_sessions_end para a fase seguinte esperar os usuários atuais terminarem (conferido em 21 de outubro de 2026). Nossos artigos sobre o modelo de carga aberto vs fechado e sobre o tempo de pensamento explicam como essas escolhas mudam o que um teste mede.

Quais protocolos o Tsung consegue testar?

Mais do que a maioria das ferramentas de teste de carga: HTTP (inclusive SOAP), WebDAV, XMPP, PostgreSQL, MySQL, LDAP, WebSocket, AMQP, MQTT e TCP, UDP ou SSL puros. A documentação marca como experimentais os plugins de MySQL, WebSocket, AMQP e MQTT, com AMQP só na 0.9.1 e MQTT só na 3.1.

A página de recursos descreve cada plugin (conferido em 21 de outubro de 2026). Em XMPP e PostgreSQL o Tsung tem há muito tempo poucos concorrentes: ele fala o protocolo por conta própria, então você testa o servidor, não uma biblioteca cliente. Para apps em tempo real, nosso panorama de ferramentas de teste de carga WebSocket coloca o Tsung ao lado de opções mais novas.

Como distribuir um teste do Tsung entre várias máquinas?

Você lista as máquinas cliente no XML, e o controlador inicia a carga nelas via SSH sem senha, ou via rsh. Cada cliente pode receber um peso, um limite de usuários e um número de CPUs.

A página de clientes e servidor explica que o Tsung roda uma máquina virtual Erlang por CPU declarada com cpu em cada cliente (uma por padrão) e sobe uma nova quando uma VM chega a maxusers. Ele também pode pegar as máquinas cliente de um agendador de lotes como PBS, LSF ou OAR. A página de instalação pede Erlang/OTP R16B03 ou mais novo e, como opção, Perl 5 e gnuplot, ou Python e matplotlib, para os gráficos (conferido em 21 de outubro de 2026).

A LoadFocus, que publica este site, não roda arquivos do Tsung. Ela roda planos de teste JMeter e scripts k6 a partir de 25 regiões na nuvem.

Como ler os resultados do Tsung?

De duas formas: num painel ao vivo que o controlador serve na porta 8091 e num relatório HTML que o script tsung_stats.pl gera depois da execução.

A página de relatórios diz que o painel existe desde a 1.6.0, mostra o status atual, monta os gráficos enquanto o teste roda e para quando o teste termina, a menos que você inicie o Tsung com -k (conferido em 21 de outubro de 2026). O relatório cobre tempos de resposta e de conexão, transações, requisições por segundo e códigos de erro, e pode incluir dados de CPU, memória e rede dos servidores, coletados por agentes Erlang, SNMP ou munin. A documentação não descreve nenhum limite de aprovação, então um pipeline de CI precisa analisar os resultados por conta própria; nosso guia de critérios de aprovação de um teste de carga mostra o que conferir.

O que o Tsung faz bem, e onde estão os limites?

Ele é forte em variedade de protocolos, fases de chegada abertas e muitos usuários por máquina, que a documentação coloca na casa dos milhares por CPU. Os limites são um histórico de versões com pouco movimento, scripts só em XML e nenhuma checagem de aprovação embutida.

• Testes de XMPP, LDAP e banco de dados no nível do protocolo, sem escrever código cliente.
• Distribuição por SSH simples, sem broker nem serviço extra.
• Monitoramento dos servidores no mesmo relatório.
• Qualquer lógica além do XML exige Erlang, que poucos times escrevem.
• O Erlang precisa estar instalado no controlador e em cada cliente.

Quando escolher k6, Gatling ou JMeter em vez do Tsung?

Escolha outra ferramenta quando você testa HTTP ou APIs e quer um projeto ativo, com scripts numa linguagem popular.

Escolha o k6 para scripts em JavaScript com thresholds dentro do próprio script e um projeto ativo (conferido em 21 de outubro de 2026). Escolha o Gatling para simulações em código na JVM; nossa análise do Gatling cobre o tema. Escolha o JMeter quando os testadores querem uma interface gráfica ou quando você precisa de samplers JDBC, JMS ou LDAP com um grande ecossistema de plugins. A LoadFocus roda JMeter e k6 a partir de 25 regiões na nuvem, e o panorama de ferramentas de teste de carga open source coloca essas ferramentas lado a lado.

FAQ

O Tsung ainda é mantido? Sim, mas com pouco movimento. A última versão, 1.8.0, saiu em 2 de março de 2023, e o repositório ainda recebe de vez em quando mudanças mescladas, a mais recente em março de 2026.

Quais protocolos o Tsung suporta? HTTP e SOAP, WebDAV, XMPP, PostgreSQL, LDAP e TCP, UDP ou SSL puros, além de MySQL, WebSocket, AMQP e MQTT, que a documentação marca como experimentais.

A LoadFocus consegue rodar testes do Tsung? Não. A LoadFocus roda planos de teste JMeter e scripts k6. Para distribuir um teste do Tsung entre várias máquinas, liste-as como clientes no arquivo XML.

Leituras relacionadas

• Ferramentas de teste de carga WebSocket: seis opções
• Ferramentas de teste de carga open source: seis opções
• Modelo de carga aberto vs fechado: qual usar e quando
• Teste de carga com Gatling: análise da ferramenta JVM
• Teste de carga com NBomber: análise do framework .NET
• pgbench: benchmark e teste de carga do PostgreSQL
• Como usar o sysbench: benchmarks de CPU, disco e MySQL

As afirmações técnicas deste artigo não foram revisadas de forma independente.