Ferramentas de teste de carga WebSocket: seis opções

Entre as ferramentas de teste de carga WebSocket, k6, Artillery, Gatling e Tsung suportam o protocolo de fábrica, enquanto o JMeter precisa do plugin WebSocket Samplers e o Locust precisa de código cliente escrito por você ou do seu usuário experimental de Socket.IO. Escolha pela linguagem em que o seu time escreve e, depois, pelo rigor com que você precisa verificar as mensagens que o servidor devolve.

Para este artigo, não rodamos essas ferramentas contra um servidor WebSocket. Os dados vêm da documentação e do repositório de cada projeto, conferidos em 9 de outubro de 2026, e as notas de “Prefira” são a nossa avaliação.

O que muda na carga WebSocket em relação à carga HTTP?

Um usuário WebSocket abre uma conexão e a mantém durante toda a sessão, e o servidor pode mandar mensagens quando quiser. Por isso um teste tem dois controles, conexões abertas e mensagens por segundo, e cada um carrega o servidor de um jeito.

O guia de WebSocket do k6 descreve tráfego full-duplex sobre uma única conexão TCP e explica que um usuário virtual roda ali um loop de eventos enquanto o socket fica aberto e para de repetir a função principal. A referência de WebSocket do Gatling acrescenta que o tráfego vai nos dois sentidos, então o modelo de requisição e resposta do HTTP deixa de servir.

Planeje três formatos de teste. Muitas conexões ociosas mostram quantos sockets os seus servidores conseguem manter. Um grupo menor de clientes que falam muito testa o tratamento de mensagens. Um broadcast, em que uma mensagem vai para todos os assinantes, testa o caminho do push.

O que medir em um teste de carga WebSocket?

Meça o tempo de conexão, a latência das mensagens e as conexões perdidas, além de quantas conexões continuam abertas. São esses valores que os usuários de um app em tempo real sentem.

As métricas embutidas do k6 incluem ws_connecting, ws_ping, ws_session_duration, ws_sessions e contadores de mensagens. Nenhuma delas cronometra uma mensagem da aplicação, então o tempo entre a mensagem de um cliente e a resposta do servidor pede uma métrica Trend própria. A engine ws do Artillery reporta a contagem e a taxa de mensagens, e a engine de Socket.IO acrescenta socketio.response_time, do envio de uma mensagem até a chegada da resposta.

Para as conexões perdidas, conte os eventos close e error que o seu script não provocou, e compare as sessões iniciadas com as que ainda estão abertas no fim de cada etapa.

Quando o k6 é a ferramenta WebSocket certa?

Quando o seu time escreve JavaScript e cada usuário virtual precisa manter vários sockets ao mesmo tempo. O k6 traz suporte a WebSocket de fábrica, sem extensão para instalar.

O módulo k6/websockets segue a API WebSocket do navegador e usa um loop de eventos global, que permite a um usuário virtual manter várias conexões abertas. O módulo antigo k6/ws continua documentado, mas o k6 recomenda k6/websockets para testes novos, e k6/experimental/websockets está obsoleto.

import { WebSocket } from 'k6/websockets';

export default function () {
  const ws = new WebSocket('wss://example.com/ws');
  ws.onopen = () => ws.send('hello');
  ws.onmessage = (e) => {
    console.log(e.data);
    ws.close();
  };
}

Os thresholds também funcionam com métricas próprias, então uma meta de latência não cumprida devolve à CI um código de saída diferente de zero. Prefira o Artillery quando o seu servidor fala Socket.IO e você quer verificar emits e acknowledgements sem escrever código cliente. A nossa comparação k6 vs Artillery cobre as outras diferenças.

Quando o Artillery faz sentido?

Quando você quer cenários YAML curtos, ou quando o seu servidor usa Socket.IO. As duas engines vêm com o próprio Artillery.

Um cenário na engine de WebSocket é montado com cinco ações: connect, send, think, loop e function. A engine de Socket.IO vai além: um emit pode declarar a resposta que espera, validar um acknowledgement com uma correspondência JSONPath e dividir o cenário com requisições HTTP, o que serve bem a apps que fazem login por HTTP antes de abrir um socket.

Prefira o k6 ou o Gatling quando um teste precisa verificar o que um servidor WebSocket puro devolve, porque a documentação da engine ws não descreve nenhuma etapa que espere ou compare uma resposta.

Para quem é o Gatling em WebSockets?

Para times na JVM, ou no SDK de JavaScript do Gatling, que querem escrever as verificações de mensagens dentro do cenário. O suporte a WebSocket faz parte do SDK de HTTP do Gatling, então os passos HTTP e WebSocket dividem a mesma simulação.

A referência cobre connect, sendText, sendBytes e close, além de checks que bloqueiam até a mensagem esperada chegar ou um timeout passar. As configurações do protocolo permitem reconectar um socket que o servidor fechou, responder automaticamente a certas mensagens de texto, como um ping, e guardar em buffer as mensagens que nenhum check reconheceu. Segundo o repositório, WebSocket faz parte da Community Edition sob Apache 2.0, sem limites.

Prefira o k6 se você gosta mais de reagir às mensagens enviadas pelo servidor em handlers de eventos do que em checks bloqueantes.

O JMeter consegue fazer teste de carga de WebSockets?

Sim, com um plugin. O JMeter não tem sampler de WebSocket, e a extensão de costume é o WebSocket Samplers, de Peter Doornbosch.

A referência de componentes do JMeter não menciona WebSocket em nenhum momento. O repositório do plugin descreve seis samplers: abrir conexão, request-response, ping-pong, leitura única, escrita única e fechamento. Eles rodam na thread do próprio thread group, suportam wss e frames binários, e podem filtrar os frames que não importam para o teste. A instalação é pelo Plugins Manager ou copiando o jar para lib/ext, e a versão 1.3.2 foi marcada em janeiro de 2026 (conferido em 9 de outubro de 2026).

Escolha outra ferramenta se você prefere não manter um plugin de terceiros em cada gerador de carga.

E o Locust e o Tsung?

O Locust só chega aos WebSockets puros com código cliente que você adiciona, e o Tsung os suporta na configuração XML, mas lança versões novas raramente. Os dois funcionam, com mais esforço.

Segundo a documentação do Locust, a ferramenta suporta de fábrica só HTTP e HTTPS; outros protocolos entram envolvendo uma biblioteca cliente e disparando um evento request depois de cada chamada. A biblioteca precisa aceitar o patch do gevent, ou vai bloquear o processo inteiro. Para Socket.IO existe um SocketIOUser experimental. Escolha o Locust se o seu time escreve Python e não se importa de manter esse código cliente.

O Tsung é um projeto em Erlang que se descreve como uma ferramenta de teste de carga distribuída e multiprotocolo. A sua documentação de sessões define para WebSocket as requisições connect, message e close, com um atributo ack para esperar uma resposta. A sua última versão marcada, a 1.8.0, é de março de 2023.

Onde entra um serviço hospedado como a LoadFocus?

Manter muitos sockets abertos a partir das suas próprias máquinas dá trabalho, e um serviço hospedado assume a geração de carga. Ele se encaixa melhor quando os seus testes já são scripts k6.

A LoadFocus, que publica este site, roda scripts k6 a partir de 25 regiões na nuvem, e a sua página de k6 lista conexões WebSocket entre os recursos do k6 suportados. Ela também oferece um template de teste WebSocket com rampa de subida e descida (em inglês). Não verificamos se ela roda plugins do JMeter como o WebSocket Samplers, então não afirmamos nada sobre isso.

Como escolher entre elas?

Parta da linguagem do seu time e depois pergunte se você testa WebSockets puros ou Socket.IO e com que rigor precisa verificar as mensagens enviadas pelo servidor. Normalmente sobram uma ou duas candidatas.

Escreva nas duas o mesmo teste curto de conectar, enviar e receber, e compare o tempo de conexão e a latência das mensagens com pouca carga. O nosso guia Como fazer um teste de carga mostra os passos, e o panorama de ferramentas de teste de carga open source compara esses projetos além do WebSocket.

FAQ

Com qual ferramenta de teste de carga WebSocket devo começar? Se o seu time escreve JavaScript, comece pelo k6, que traz WebSocket de fábrica. Para apps com Socket.IO, a engine do Artillery pede menos código, e times da JVM vão se sentir em casa no Gatling.

O JMeter consegue testar WebSockets sem plugin? A referência de componentes dele não traz nenhum sampler de WebSocket, então o caminho prático é o plugin WebSocket Samplers, instalado pelo Plugins Manager ou como jar em lib/ext.

Devo usar k6/ws ou k6/websockets? Use k6/websockets em testes novos, como recomenda a documentação do k6. O módulo antigo k6/ws continua documentado para scripts existentes.

Leituras relacionadas

• Ferramentas de teste de carga open source: seis opções
• Teste de carga de API GraphQL: guia prático
• Ferramentas de benchmark HTTP: wrk, hey, oha, ab e mais
• Teste de carga gRPC: ferramentas, configuração e métricas
• Teste de carga com Artillery: análise da ferramenta Node.js
• Teste de carga com Tsung: análise da ferramenta Erlang

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