Teste de carga com Gatling: análise da ferramenta JVM

O Gatling é uma ferramenta gratuita de teste de carga sob licença Apache 2.0, em que cada teste é uma simulação escrita como código, executada na JVM e seguida de um relatório HTML. O teste de carga com Gatling combina com equipes de desenvolvimento que querem os testes no repositório, modelos de carga abertos ou fechados e asserções que façam o build falhar. Quem quer um editor gráfico de testes ou muitos protocolos fica mais bem servido pelo JMeter, e quem quer um único binário sem JVM, pelo k6.

Não rodamos o Gatling para esta análise. Os fatos vêm da documentação, do repositório e das páginas de versões do Gatling, conferidos em 9 de outubro de 2026, e as avaliações são nossas.

Quem desenvolve o Gatling, e ele ainda é mantido?

A Gatling Corp, uma empresa francesa, desenvolve o Gatling e detém seus direitos autorais. O projeto é mantido ativamente, com três versões para a JVM até agora em 2026.

A página de licenças atribui os direitos autorais à Gatling Corp. O Maven Central lista a 3.15.0 em fevereiro, a 3.15.1 em maio e a 3.16.0 em 29 de setembro de 2026, e o SDK de JavaScript chegou à 3.16.1 em 6 de outubro. As notas da versão 3.16 trazem GraphQL e filas compartilhadas entre usuários virtuais. O README apresenta o repositório como a Community Edition, de uso livre inclusive comercial (conferido em 9 de outubro de 2026).

Do que você precisa para rodar o Gatling?

De uma JVM de 64 bits para Java, Kotlin ou Scala, ou de Node.js para JavaScript e TypeScript. Nos dois casos, a simulação em si roda numa JVM.

A página de instalação suporta as versões LTS do OpenJDK do 11 ao 25 e exclui JVMs de 32 bits e o OpenJ9. A CLI de JavaScript exige Node.js 24 ou mais recente e baixa um pacote de execução do Gatling e, segundo o README do gatling-js, o GraalVM (conferido em 9 de outubro de 2026).

Como uma simulação do Gatling é estruturada?

Uma simulação define cenários, dá a cada um um perfil de injeção e anexa uma configuração de protocolo, tudo registrado numa única chamada a setUp.

Na referência de simulações, um cenário encadeia requisições com pausas, laços e condições. Esta simulação em Java guarda o id de um produto vindo de uma busca, pausa de um a três segundos e abre o produto, enquanto as chegadas sobem para 20 usuários por segundo e se mantêm por dez minutos:

public class ShopSimulation extends Simulation {

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

  ScenarioBuilder shoppers = scenario("Shoppers")
      .exec(http("search").get("/api/products?q=lamp")
          .check(jsonPath("$[0].id").saveAs("id")))
      .pause(1, 3)
      .exec(http("product").get("/api/products/#{id}"));

  {
    setUp(shoppers.injectOpen(
        rampUsersPerSec(1).to(20).during(120),
        constantUsersPerSec(20).during(600)))
      .protocols(api)
      .assertions(
          global().responseTime().percentile(95.0).lt(800));
  }
}

Os imports foram omitidos, e #{id} lê o valor guardado pela Expression Language do Gatling. Gatling vs k6 mostra uma simulação em JavaScript.

Você deve injetar usuários no modelo aberto ou fechado?

Aberto, para a maioria dos sites e APIs, onde novos usuários continuam chegando por mais lento que o sistema fique. O fechado serve para sistemas que limitam a concorrência, como uma fila de venda de ingressos.

A referência de injeção divide a API: injectOpen recebe taxas de chegada como rampUsersPerSec, e injectClosed, metas de concorrência como constantConcurrentUsers. A página sobre modelos de carga diz que a maioria dos sites se comporta como sistema aberto e que um perfil não pode misturar os dois (conferido em 9 de outubro de 2026). Nosso guia sobre o modelo de carga aberto vs fechado explica como escolher.

Como funcionam os checks, as asserções e o relatório?

Os checks verificam cada resposta e podem guardar valores dela, enquanto as asserções julgam a execução inteira quando ela termina. Depois, cada execução gera um relatório HTML.

Sem um check de status explícito, o Gatling verifica se cada resposta HTTP é 2XX ou 304. As asserções avaliam tempos de resposta, número de requisições ou requisições por segundo, no total ou por requisição, e uma única asserção com falha faz a simulação falhar. O relatório HTML mostra faixas de tempo de resposta e percentis, usuários iniciados por segundo, usuários simultâneos e requisições por segundo; seus percentis ao longo do tempo contam só as requisições bem-sucedidas (conferido em 9 de outubro de 2026).

Como o Gatling se encaixa no build e na CI?

Pelo plugin para Maven, Gradle, sbt ou npm, que roda em qualquer sistema de CI. Uma asserção com falha faz o build falhar.

O plugin do Maven liga gatling:test à fase integration-test, então mvn verify o executa, e com CI=true ele deixa de perguntar qual simulação rodar (a execução então falha se o projeto tiver mais de uma simulação e nenhuma for indicada). O plugin do Gradle usa gatlingRun, e o plugin do sbt aceita só simulações em Scala. As integrações de CI prontas do Gatling, como a sua GitHub Action, disparam execuções no Gatling Enterprise (conferido em 9 de outubro de 2026). Nosso guia de GitHub Actions cobre o lado do workflow.

Quais protocolos o Gatling suporta?

HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events e JMS vêm sem limites. gRPC, MQTT e GraphQL são plugins à parte, limitados a 5 usuários e 5 minutos fora do Gatling Enterprise.

O README coloca os cinco primeiros sob Apache 2.0. As páginas de configuração de gRPC, MQTT e GraphQL põem cada plugin sob a Gatling Enterprise Component License: sem limites no Gatling Enterprise, enquanto um teste com a Community Edition para em 5 usuários ou 5 minutos. Essa licença concede uso gratuito por até um ano, apenas para testar internamente as suas próprias aplicações web; ela termina assim que um limite é atingido, e a Gatling Corp pode mudar esses limites. O GraphQL exige a 3.16.0 ou mais recente. As notas da versão e o README dizem que o SDK de JavaScript ainda não tem suporte a ele, embora a página de configuração já mostre um pacote npm, então confira antes de planejar um teste de GraphQL em JavaScript (conferido em 9 de outubro de 2026). Nosso guia sobre teste de carga em uma API GraphQL contorna o limite com requisições HTTP comuns.

O que o Gatling Enterprise acrescenta?

O Gatling Enterprise é a edição comercial sobre o mesmo motor. Ele gera carga a partir de infraestrutura gerenciada ou privada, coisa que a edição gratuita não faz.

Segundo o README, o Enterprise roda os testes em geradores de carga gerenciados ou nas suas próprias contas de AWS, Azure, GCP ou Kubernetes, e acrescenta painéis ao vivo, tendências, equipes com SSO e integrações de CI/CD. O FAQ diz que a Community Edition não suporta testes distribuídos e que as simulações passam para o Enterprise sem alterações (conferido em 9 de outubro de 2026).

A LoadFocus, que publica este site, não roda simulações do Gatling. Ela roda planos de teste JMeter e scripts k6 a partir de 25 regiões de nuvem, então para o Gatling o caminho para mais máquinas é o Gatling Enterprise.

O que o Gatling faz bem, e onde estão seus limites?

Ele se destaca em testes como código revisável, em modelos de carga e em relatórios sem configuração. É mais fraco em protocolos além da web e de mensageria, e em escalar de graça além de uma máquina.

O README destaca o motor: não bloqueante, construído sobre o Netty, com cada usuário virtual sendo uma mensagem leve. Limites que a própria documentação aponta (conferido em 9 de outubro de 2026):

• O Gatling não é um navegador: segundo a página do protocolo HTTP, ele não executa JavaScript.
• O SDK de JavaScript não tem JMS e não pode usar bibliotecas npm que precisem de binários nativos ou de APIs próprias do Node.js.
• O cache HTTP vem ligado por padrão, o que pode reduzir a contagem de requisições.
• O formato do simulation.log não é documentado e pode mudar a qualquer momento.

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

Escolha outra ferramenta quando a linguagem, os protocolos ou o caminho gratuito para escalar dela combinarem melhor com a sua equipe.

Nossa visão geral de ferramentas de teste de carga open source coloca o Gatling ao lado de outras cinco.

Escolha o k6 se você quer na CI um único binário sem JVM, thresholds capazes de parar cedo uma execução com falha ou gRPC entre os seus protocolos embutidos (conferido em 9 de outubro de 2026). Gatling vs k6 compara os dois.

Escolha o JMeter se os seus testadores montam testes numa interface gráfica, ou se você precisa de JDBC, LDAP ou FTP no núcleo (conferido em 9 de outubro de 2026). A LoadFocus roda planos de teste JMeter existentes a partir de 25 regiões de nuvem, e Gatling vs JMeter se aprofunda.

Escolha o Locust se a sua equipe escreve Python e quer um modo distribuído na ferramenta gratuita (conferido em 9 de outubro de 2026). Nossa análise do Locust trata dele.

FAQ

O Gatling é gratuito para uso comercial? Sim. A Community Edition está sob Apache 2.0. Os plugins de gRPC, MQTT e GraphQL têm licença própria e param em 5 usuários e 5 minutos fora do Gatling Enterprise.

É preciso ter Java para usar o Gatling? Para Java, Kotlin ou Scala, sim: um OpenJDK LTS de 64 bits do 11 ao 25. O SDK de JavaScript precisa do Node.js 24 ou mais recente, e a CLI dele baixa sozinha o ambiente JVM.

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 por várias máquinas, use o Gatling Enterprise.

Leituras relacionadas

• Gatling vs JMeter: testes como código ou plano na GUI?
• Gatling vs k6: simulações na JVM ou um único binário Go?
• Ferramentas de teste de carga open source: seis opções
• Gatling vs Locust: simulações na JVM ou locustfiles Python?
• Teste de carga com NBomber: análise do framework .NET

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