Ferramentas de teste de carga: como escolher entre k6, JMeter e Locust

Autor: Pedro Tebaldi PM do KeepGreen

Publicado set/2026

A conta de capacidade raramente fecha no dia do pico. O ambiente responde bem enquanto o tráfego é o de sempre, porque a fila do banco cabe na memória disponível. Quando a campanha triplica as sessões simultâneas, o gargalo aparece onde ninguém apontaria no quadro branco.

Testar carga em laboratório antecipa esse momento. A escolha da ferramenta, porém, decide bem mais do que a sintaxe do script. Essa decisão define onde o teste roda, quem consegue mantê-lo depois que o autor sai do time e quanto hardware o gerador de carga consome.

Este comparativo olha k6, JMeter e Locust da cadeira de quem responde pelo ambiente depois que o teste termina. Além do critério de escolha, ele fecha com a parte que a maioria dos comparativos ignora: o que monitorar enquanto a carga sobe. O número do relatório só vale quando você sabe qual recurso saturou primeiro.

O que um teste de carga mede e onde ele difere do teste de estresse

Um teste de carga mede como a aplicação se comporta sob o volume de usuários simultâneos que você espera receber. A carga fica de pé por tempo suficiente para o sistema estabilizar. Três perguntas saem daí: quanto tempo a requisição leva no percentil 95, quando a taxa de erro sobe e qual recurso satura primeiro.

Cinco exercícios diferentes viajam sob o mesmo nome, o que produz a confusão mais comum do briefing. Cada um responde a uma pergunta própria e exige uma curva de carga própria. Nenhum deles produz um número que substitua o dos outros.

Nenhum desses testes responde por que o número deu aquilo. A ferramenta de carga enxerga o sistema pela porta da frente, do mesmo jeito que o usuário enxerga.

O relatório informa que o percentil 95 saltou de 400 ms para 3 segundos. A causa pode estar em bloqueio no banco, no coletor de lixo da JVM ou na latência acrescentada pela rede entre camadas. Distinguir as três não é trabalho dessa ferramenta.

Degradação custa dinheiro antes de virar indisponibilidade. O usuário abandona o carrinho quando a página demora, mesmo que o painel de disponibilidade siga verde durante todo o episódio.

k6, JMeter e Locust: o que cada uma faz em uma frase

Cada ferramenta resolve o mesmo problema por um caminho próprio. A diferença aparece já na primeira linha do script:

• k6: script em JavaScript, núcleo em Go, feito para rodar dentro do pipeline.
• JMeter: plano montado em interface gráfica, executado na JVM, com a maior cobertura de protocolo.
• Locust: cenário em classe Python, com distribuição nativa entre máquinas e interface web ao vivo.

Nenhuma das três substitui a outra, porque cada uma assume um perfil de time. Quem escolhe pela lista de recursos costuma acertar a ferramenta e errar o dono dela. Errar o dono sai caro, já que script sem manutenção envelhece em duas sprints.

k6: script em JavaScript, thresholds e execução no pipeline

O k6 nasceu para rodar por linha de comando dentro de uma esteira automatizada. O teste é um arquivo JavaScript e a carga é declarada em estágios de rampa.

Os critérios de aprovação ficam no mesmo arquivo, de modo que o resultado vira decisão binária em vez de relatório para interpretação humana.

Esse desenho se sustenta em um recurso chamado thresholds. Segundo a documentação oficial do projeto, são critérios de aprovação e reprovação definidos sobre as métricas do teste.

Quando a condição é violada, a execução termina com status de falha e o processo sai com código diferente de zero.

import http from 'k6/http';
import { check, sleep } from 'k6';
export const options = {
  stages: [
    { duration: '2m', target: 300 },
    { duration: '8m', target: 300 },
    { duration: '2m', target: 0 },
  ],
  thresholds: {
    http_req_duration: ['p(95)<800'],
    http_req_failed: ['rate<0.01'],
  },
};
export default function () {
  const res = http.get('https://checkout.exemplo.com.br/api/carrinho');
  check(res, { 'status 200': (r) => r.status === 200 });
  sleep(1);
}

Com esse arquivo, o build quebra quando o percentil 95 passa de 800 ms ou quando a taxa de erro ultrapassa 1%. É a mesma lógica do deslocamento dos testes para a esquerda: a prova de performance roda a cada mudança relevante, não na véspera do lançamento.

Onde o k6 aperta

Cobertura de protocolo é o primeiro limite: HTTP, gRPC, WebSocket e alguns bancos, sem o alcance do JMeter em mensageria e diretório.

A execução distribuída também exige trabalho extra, porque o binário roda em uma máquina só. Distribuir carga passa por um operador em Kubernetes ou pelo serviço em nuvem do fornecedor.

Para cenários de API REST, no entanto, uma máquina bem dimensionada resolve muito mais do que a intuição sugere.

JMeter: interface gráfica, cobertura de protocolo e custo de memória

O JMeter é o mais antigo dos três e continua sendo a resposta quando o alvo não fala HTTP. Componentes nativos cobrem JDBC, JMS, FTP, LDAP, SMTP e TCP. Isso importa em ambientes onde a fila de mensagens ou o procedimento armazenado é justamente o suspeito.

Quem monta o plano usa a interface gráfica, que salva o arquivo em XML. O próprio projeto recomenda a interface apenas para construir e depurar. A execução real acontece em modo não gráfico, que consome bem menos recurso na máquina geradora.

# heap maior antes de subir milhares de threads
export JVM_ARGS="-Xms2g -Xmx4g"
jmeter -n -t plano-checkout.jmx -l resultado.jtl -e -o relatorio/

O custo aparece na conta de memória. Cada usuário virtual do JMeter é uma thread da JVM, com pilha própria. Dez mil usuários simultâneos exigem uma máquina generosa ou um cluster de geradores. As outras duas ferramentas trabalham com concorrência cooperativa, que cabe bem mais densamente no mesmo hardware.

A questão da manutenção em 2026

Há um dado que pesa na decisão e costuma passar em branco. Na página oficial de download do projeto, a versão atual é a 5.6.3, publicada em janeiro de 2024.

k6 e Locust publicaram versões novas ao longo de 2026, enquanto o JMeter passou mais de dois anos sem release. Nada disso invalida a ferramenta, já que o protocolo HTTP não mudou e o ecossistema de plugins continua ativo.

Ainda assim, quem escolhe uma base para os próximos três anos pesa o ritmo de manutenção junto com a lista de recursos.

Locust: cenário em Python, master e worker

O Locust troca o plano declarativo por código de verdade. O cenário é uma classe Python comum. Qualquer comportamento programável entra no teste: ler um arquivo de credenciais, assinar um payload ou seguir uma máquina de estados de sessão.

from locust import HttpUser, task, between
class UsuarioCheckout(HttpUser):
    wait_time = between(1, 3)
    @task(3)
    def consultar_carrinho(self):
        self.client.get("/api/carrinho")
    @task(1)
    def finalizar_compra(self):
        self.client.post("/api/checkout", json={"cupom": "BLACK"})

Pesos declarados em @task distribuem o comportamento do usuário sintético. Três consultas de carrinho acontecem para cada compra finalizada. Modelar proporção de jornada assim sai bem mais direto do que encadear controladores em interface gráfica.

Distribuir a carga entre máquinas é nativo no Locust e não custa licença. Na documentação de execução distribuída o motivo está explícito: Python não usa mais de um núcleo por processo, então cada núcleo pede um worker próprio.

Um processo sobe com --master e os demais com --worker. O master concentra a interface web e coordena a rampa, enquanto os workers geram as requisições e devolvem as estatísticas.

Sete critérios para escolher entre k6, JMeter e Locust

Fora de contexto, a pergunta sobre qual é a melhor não tem resposta. Três variáveis decidem quase tudo: a linguagem que o time já escreve, o protocolo do alvo e o lugar onde o teste roda. Na tabela abaixo estão os critérios que costumam aparecer na reunião de decisão.

Times que vivem dentro do pipeline e testam APIs REST rendem mais com o k6, porque o portão de aprovação nasce junto com o script.

Quando o alvo inclui fila de mensagens, banco por JDBC ou protocolo legado, o JMeter continua sendo o caminho mais curto.

Para jornada complexa de usuário, com estado e regra de negócio no meio, o Locust ganha por usar a linguagem que o time já domina.

Por que duas ferramentas medem tempos diferentes no mesmo teste

Rodar o mesmo cenário em duas ferramentas e receber números distintos confunde qualquer comparação. A diferença não indica erro de nenhuma delas, já que o relógio de cada uma começa a contar em momentos diferentes.

Parte da divergência vem do que entra na medida. Uma ferramenta pode incluir resolução de DNS e handshake TLS no tempo da requisição, enquanto outra cronometra a partir do primeiro byte enviado. Reaproveitamento de conexão e política de keep-alive também mudam o resultado sem que o servidor tenha mudado nada.

Concorrência é a parte mais séria da divergência. Ferramentas baseadas em usuário virtual esperam a resposta chegar antes de emitir a próxima requisição. O servidor lento recebe menos carga justamente quando está sofrendo, de modo que o relatório subestima o problema.

Executores por taxa de chegada mantêm o ritmo combinado de requisições, independentemente do tempo de resposta, o que reproduz melhor o comportamento do usuário real.

Na prática, a conclusão é direta: compare séries da mesma ferramenta ao longo do tempo, nunca o número absoluto de uma contra o da outra. Fixe também a versão da ferramenta e a máquina geradora, porque trocar qualquer um dos dois invalida a comparação com as medições anteriores.

O que monitorar no ambiente enquanto o teste roda

O relatório da ferramenta diz quando o sistema quebrou, sem dizer onde. Essa lacuna separa um teste de carga de um exercício de capacidade de verdade. Enquanto a rampa sobe, o ambiente precisa estar instrumentado com a mesma seriedade da produção.

Quatro camadas pedem acompanhamento durante a execução do teste. Saturação de CPU e memória por processo, fila no banco de dados, pool de conexões e descarte de pacotes na rede cobrem o mínimo.

Como recorte inicial, os quatro sinais de ouro do SRE funcionam bem: latência, tráfego, erros e saturação no mesmo painel.

Sem essa correlação, o time cai no diagnóstico por tentativa. No Instituto Butantan, a plataforma crítica de gestão de documentos travava sem causa visível, com esperas de 3 a 5 minutos por operação. A resposta padrão até então era reiniciar o serviço ou aumentar hardware.

Quando instrumentamos a aplicação com traces e logs centralizados, a causa apareceu: uma query lenta no SQL Server somada ao consumo de memória do Java. O ajuste saiu no banco e na aplicação, sem servidor novo, como mostra o relato completo do projeto do Butantan.

Ferramentas de APM ajudam nessa hora, porque quebram o tempo da transação por camada e apontam a chamada que segurou a fila. Sem elas, o percentil 95 do relatório vira número órfão, sem responsável e sem plano de ação.

Do ponto de quebra ao limiar de alerta

Virar limiar operacional é o melhor destino do resultado. Se o ambiente degrada a partir de 2.400 sessões simultâneas, esse número entra no planejamento de capacidade como teto conhecido. O alerta dispara bem antes, em torno de 70% do valor medido.

Tempo de resposta segue o mesmo raciocínio. O percentil aceito no teste vira candidato natural a SLO da jornada, com apuração contínua em produção. Um exercício pontual vira, assim, régua permanente de operação.

O número que sobra depois do teste

Escolher entre k6, JMeter e Locust cabe em três perguntas: linguagem do time, protocolo do alvo e lugar da execução em seis meses. Responda a elas antes de abrir qualquer comparativo de recursos, porque a ferramenta que ninguém mantém perde para a menos elegante que continua rodando.

Depois da decisão, o valor real do exercício aparece na ponte com a operação. Um teste isolado gera um PDF, enquanto um teste correlacionado com CPU, banco, fila e rede gera limiar defensável, ordem de investimento e alerta calibrado.

Times que fazem essa ponte param de discutir se o servidor aguenta. A discussão passa a ser sobre qual recurso ampliar primeiro, com número medido no lugar de opinião.

Todo pico relevante tem data marcada no calendário comercial. Quando o ambiente ainda não acompanha a carga em tempo real, fale com um especialista da OpServices antes que a campanha comece.