Gatling vs JMeter: testes como código ou plano na GUI?

Gatling e Apache JMeter são ferramentas de teste de carga gratuitas e open source que rodam na JVM, e a escolha depende principalmente de como o seu time quer construir os testes. Escolha o Gatling se você quer testes como código em Java, Kotlin, Scala, JavaScript ou TypeScript, perfis de injeção abertos e um relatório HTML depois de cada execução. Escolha o JMeter se você precisa de protocolos como JDBC, LDAP, FTP ou e-mail sem instalar nada a mais, prefere montar os testes em uma interface gráfica ou já tem planos de teste .jmx.

Os dados desta comparação Gatling vs JMeter vêm da documentação e do repositório de cada projeto, conferidos em 9 de outubro de 2026.

Qual é a diferença entre Gatling e JMeter?

No Gatling, um teste é um programa dentro de um projeto de build. No JMeter, um teste é uma árvore de elementos que você monta em uma interface gráfica de desktop e salva como arquivo XML, e daí vem a maior parte das outras diferenças.

O README do Gatling chama os testes de simulações e os guarda no seu repositório como código da aplicação, executados por um plugin de Maven, Gradle, sbt ou npm. O SDK de JavaScript e TypeScript é instalado pelo npm e baixa o próprio ambiente GraalVM.

Um plano do JMeter tem um Thread Group para os usuários, samplers para as requisições e assertions e listeners para os resultados. O JMeter 5.6.3, versão atual na página de download, exige Java 8 ou mais recente. O README do branch de desenvolvimento do JMeter já exige Java 17 (conferido em 10 de outubro de 2026). Por baixo, o JMeter roda cada usuário virtual como uma thread Java, enquanto o README do Gatling descreve os usuários virtuais como mensagens leves em um motor não bloqueante construído sobre o Netty.

Como escrever um teste em cada ferramenta?

No Gatling, você escreve uma classe de simulação que define um cenário, um perfil de injeção e assertions. No JMeter, você adiciona um Thread Group e samplers na interface gráfica, salva o plano e depois roda esse arquivo pela linha de comando.

Uma simulação em Java baseada no tutorial da primeira simulação do Gatling: novos usuários chegam primeiro a um por segundo, sobem para dez por segundo em um minuto e ficam nesse ritmo por cinco minutos. A execução falha se o percentil 95 passar de 500 ms ou se mais de 1% das requisições falharem:

import static io.gatling.javaapi.core.CoreDsl.*;
import static io.gatling.javaapi.http.HttpDsl.*;

import io.gatling.javaapi.core.*;
import io.gatling.javaapi.http.*;

public class ApiSimulation extends Simulation {

  HttpProtocolBuilder httpProtocol =
      http.baseUrl("https://staging.example.com");

  ScenarioBuilder users = scenario("API users")
      .exec(http("list users").get("/api/users"))
      .pause(1);

  {
    setUp(users.injectOpen(
            rampUsersPerSec(1).to(10).during(60),
            constantUsersPerSec(10).during(300)))
        .protocols(httpProtocol)
        .assertions(
            global().responseTime().percentile(95.0).lt(500),
            global().failedRequests().percent().lt(1.0));
  }
}

Rode com ./mvnw gatling:test; uma simulação em JavaScript ou TypeScript roda com npx gatling run.

No JMeter, o mesmo teste é um Thread Group com um sampler HTTP Request, e uma Duration Assertion pode marcar como falha cada resposta lenta. O guia de primeiros passos monta o plano no modo GUI e roda no modo CLI, e -e -o acrescenta o relatório HTML:

jmeter -n -t api-users.jmx -l results.jtl -e -o report/

As duas ferramentas conseguem gravar um primeiro rascunho a partir do navegador. O Recorder do Gatling funciona como proxy HTTP ou converte um arquivo HAR em simulação, e o HTTP(S) Test Script Recorder do JMeter captura o tráfego do navegador em um plano (conferido em 9 de outubro de 2026). A documentação do Gatling já trata esse Recorder como legado, e o mais novo Gatling Studio exige uma conta do Enterprise para fazer login (conferido em 10 de outubro de 2026).

Quais protocolos cada ferramenta consegue testar?

O JMeter cobre mais protocolos de fábrica. O Gatling traz os principais protocolos web mais JMS e deixa quase todo o resto para componentes separados ou plugins da comunidade.

O README do JMeter lista todos os protocolos da tabela acima, e-mail incluído. JDBC e JMS precisam dos JARs de driver do seu banco de dados ou do seu provedor JMS, e o Plugins Manager instala plugins da comunidade pela própria interface gráfica.

Segundo o README do Gatling, gRPC, MQTT e GraphQL são componentes separados sob a Gatling Enterprise Component License e, sem o Enterprise, ficam limitados a cinco usuários simultâneos e a testes de cinco minutos. Kafka, AMQP, SFTP, FTP e JDBC vêm de plugins de terceiros para o Gatling 3.13 que o Gatling não mantém (conferido em 9 de outubro de 2026).

Como o Gatling e o JMeter modelam a carga?

O Gatling faz você escolher entre um modelo aberto e um fechado no próprio script. O Thread Group clássico do JMeter é um grupo fechado de usuários, e carga baseada em chegadas exige o Open Model Thread Group, mais recente.

No Gatling, injectOpen recebe taxas de chegada como constantUsersPerSec e rampUsersPerSec, e injectClosed recebe metas de concorrência como constantConcurrentUsers. O JMeter 5.5 trouxe o Open Model Thread Group, que a referência ainda marca como experimental (conferido em 9 de outubro de 2026). Nosso guia sobre o modelo de carga aberto vs fechado explica por que essa escolha importa.

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

O JMeter tem um modo distribuído nativo. A edição open source do Gatling gera carga a partir de uma máquina, e a documentação exige uma conta do Gatling Enterprise para execuções distribuídas.

O modo de teste remoto do JMeter deixa um cliente controlar qualquer número de servidores. Cada servidor roda o plano inteiro, então 1.000 threads em seis servidores viram 6.000 threads. Todos os nós devem rodar a mesma versão do JMeter e do Java, o RMI precisa de um keystore a menos que o SSL esteja desativado, e os arquivos de dados precisam ser copiados para cada servidor.

Existe um terceiro caminho para planos de teste do JMeter. A LoadFocus, que publica este site, roda planos de teste JMeter existentes sem alterações a partir de 25 regiões de nuvem, sem servidores remotos para configurar. A LoadFocus não roda simulações do Gatling.

Como eles se encaixam na CI, e quais relatórios você recebe?

Os dois rodam sem interface. As assertions do Gatling podem derrubar o build diretamente, enquanto as do JMeter marcam amostras individuais e a integração com CI vem de bibliotecas de terceiros.

As assertions do Gatling são verificadas depois da execução, e uma única assertion com falha derruba a simulação e a tarefa de build. O relatório HTML mostra percentis do tempo de resposta, usuários iniciados por segundo, usuários simultâneos e requisições por segundo ao longo do tempo.

O modo CLI do JMeter não tem critérios de aprovação, então uma meta não atingida só derruba o build pelas bibliotecas para Maven, Gradle e Jenkins que o README dele lista, ou por uma checagem própria. O dashboard do JMeter traz uma tabela APDEX, uma tabela de estatísticas com três percentis configuráveis e resumos de erros, e um Backend Listener envia resultados ao vivo para InfluxDB ou Graphite.

Qual escolher?

Escolha o Gatling quando o seu time escreve Java, Kotlin, Scala ou TypeScript e quer revisar os testes de carga como o resto do código. Escolha o JMeter em vez do Gatling quando você precisa de protocolos além da web, quando seus testers preferem uma interface gráfica ou quando você já tem planos .jmx.

O Gatling combina com times que descrevem o tráfego como taxas de chegada e querem regras de aprovação ou falha ao lado do cenário, com um relatório legível sem configuração extra.

O JMeter é a melhor escolha para testar JDBC, LDAP, FTP ou e-mail, para testers que refinam visualmente um fluxo gravado e para execuções distribuídas nos seus próprios servidores sem licença comercial. Uma empresa que já usa o JMeter também mantém seus planos, plugins e conhecimento.

FAQ

O Gatling é mais rápido que o JMeter? Não medimos isso nós mesmos, então não vamos apontar um vencedor. O teste justo é o mesmo cenário nas duas ferramentas, no seu próprio hardware.

O Gatling consegue rodar arquivos .jmx do JMeter? Não diretamente. O Gatling roda simulações escritas com os SDKs dele, então um plano do JMeter precisa ser reescrito. O README do Gatling cita extensões de IA que convertem planos de teste do JMeter, e elas exigem um token de API do Gatling Enterprise.

A LoadFocus consegue rodar testes do Gatling? Não. A LoadFocus roda planos de teste JMeter e scripts k6. Para distribuir uma simulação do Gatling entre várias máquinas, use o Gatling Enterprise.

Leituras relacionadas

• Teste de carga com Gatling: análise da ferramenta JVM
• Gatling vs k6: simulações na JVM ou um único binário Go?
• Locust vs JMeter: scripts Python ou planos do JMeter?
• Modelo de carga aberto vs fechado: qual usar e quando
• k6 vs Artillery: qual ferramenta de teste de carga escolher
• Gatling vs Locust: simulações na JVM ou locustfiles Python?
• JMeter vs Postman: qual ferramenta para teste de carga?

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