Gatling vs Locust: simulações na JVM ou locustfiles Python?

Gatling e Locust são duas ferramentas open source gratuitas que guardam os testes de carga como código no seu repositório. Escolha o Gatling se o seu time trabalha na JVM ou se quer perfis de injeção abertos e fechados, assertions e um relatório HTML em um só pacote. Escolha o Locust se o seu time escreve Python, gosta de uma interface web para iniciar e acompanhar uma execução e precisa do modo distribuído sem uma edição comercial.

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

Qual é a diferença entre Gatling e Locust?

O Gatling executa simulações na JVM e o Locust executa programas Python comuns. O Gatling já traz um modelo de carga e um relatório, e no Locust você escreve a lógica do teste por conta própria.

O README do Gatling descreve um motor não bloqueante construído sobre o Netty e um SDK em cinco linguagens: Java, Kotlin e Scala rodam com Maven, Gradle ou sbt, e JavaScript e TypeScript com um SDK separado. Sua página de instalação pede um OpenJDK LTS de 64 bits da versão 11 à 25 e, para o SDK de JavaScript, Node.js 24 ou superior.

O README do Locust o apresenta como uma forma de escrever testes de carga escaláveis em Python puro, e os metadados do pacote exigem Python 3.11 ou superior. A página What is Locust diz que ele é baseado em eventos com gevent, de modo que um único processo consegue lidar com muitos milhares de usuários simultâneos (conferido em 13 de outubro de 2026).

Como escrever o mesmo teste em cada ferramenta?

No Gatling você encadeia requisições em um cenário e dá a ele um perfil de injeção. No Locust você escreve uma classe de usuário com tarefas e um tempo de espera entre elas.

Cinquenta usuários simultâneos que listam usuários e depois esperam de um a três segundos, por cinco minutos. No SDK Java do Gatling (imports omitidos):

public class ApiSimulation extends Simulation {
  HttpProtocolBuilder api =
      http.baseUrl("https://staging.example.com");

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

  {
    setUp(users.injectClosed(
        constantConcurrentUsers(50).during(300)))
      .protocols(api);
  }
}

O mesmo teste no Locust:

from locust import HttpUser, task, between


class ApiUser(HttpUser):
    wait_time = between(1, 3)

    @task
    def list_users(self):
        self.client.get("/api/users")

A referência de injeção do Gatling lista constantConcurrentUsers entre os passos do modelo fechado. O Locust recebe o número de usuários e a duração como flags (conferido em 13 de outubro de 2026):

locust -f locustfile.py --headless -u 50 -r 5 -t 5m \
  --host https://staging.example.com

Como Gatling e Locust modelam a carga?

O Gatling oferece modelos abertos e fechados, conforme o método que você chama. O Locust executa um pool de usuários, o que equivale a um modelo fechado.

A página de modelos de carga do Gatling define sistemas fechados como aqueles que limitam os usuários simultâneos e sistemas abertos como aqueles em que os usuários continuam chegando mesmo que a aplicação responda devagar. Ela acrescenta que a maioria dos sites é aberta. injectOpen recebe taxas de chegada e injectClosed recebe metas de concorrência.

O guia do locustfile diz que o tempo de espera só pode limitar a vazão e não inicia novos usuários para atingir uma taxa-alvo. Se uma volta demora mais do que a espera permite, a taxa fica abaixo da meta (conferido em 13 de outubro de 2026). Nosso guia sobre o modelo de carga aberto vs fechado explica por que isso importa.

Como rodar um teste maior do que uma máquina consegue gerar?

O Locust traz o modo distribuído embutido. A edição open source do Gatling gera carga a partir de uma única máquina, e execuções distribuídas exigem o Gatling Enterprise.

O Locust inicia um processo com --master e quantos processos --worker você quiser. Segundo a documentação de carga distribuída, um processo Python não usa mais de um núcleo, então roda-se um worker por núcleo, e --processes inicia vários em uma máquina. Um operador do Kubernetes gerencia execuções distribuídas dentro de um cluster.

O FAQ do Gatling diz que a Community Edition não suporta testes distribuídos, e o README descreve o Enterprise como rodando em geradores de carga gerenciados ou em infraestrutura privada (conferido em 13 de outubro de 2026).

Há uma saída para os dois casos. A LoadFocus, que publica este site, não roda simulações do Gatling nem testes do Locust. Se você prefere não rodar nenhum dos dois em grande escala, ela executa scripts k6 e planos de teste JMeter a partir de 25 regiões na nuvem. O validador de k6 dela avisa que cenários de taxa de chegada rodam ali com um número fixo de usuários e, por isso, não mantêm uma taxa de requisições. Migrar de qualquer uma das duas ferramentas significa reescrever o teste.

Como decidem se um teste passou, e que relatórios você recebe?

O Gatling avalia as assertions depois da execução e escreve um relatório HTML todas as vezes. O Locust termina com o código 1 se alguma requisição falhou, e outras verificações você acrescenta como listener.

As assertions do Gatling são avaliadas depois da simulação, e uma única assertion que falha faz a simulação falhar. O relatório HTML traz percentis do tempo de resposta, usuários iniciados por segundo, usuários simultâneos e requisições por segundo.

De acordo com a documentação headless do Locust, a execução termina com o código 1 se alguma amostra falhou, e um exemplo de listener faz a execução falhar pela taxa de falhas, pelo tempo de resposta médio ou pelo percentil 95. A referência de configuração cita --csv para arquivos de estatísticas e --html para um relatório (conferido em 13 de outubro de 2026).

Quais protocolos cada ferramenta consegue testar?

O Gatling traz mais protocolos, com limites nos mais novos. O Locust traz HTTP e HTTPS e espera um cliente Python para o resto.

O README do Gatling lista HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events e JMS sob Apache 2.0, sem limites. gRPC, MQTT e GraphQL ficam sob a Gatling Enterprise Component License, e testes com eles são limitados a 5 usuários simultâneos e 5 minutos na Community Edition.

A página sobre outros sistemas do Locust mostra como envolver uma biblioteca de protocolo e reportar cada chamada, com exemplos de gRPC e MQTT. A biblioteca precisa funcionar com o gevent, que não consegue aplicar patch em E/S feita em código C compilado, e o locust-plugins acrescenta usuários para Kafka, Selenium e Playwright (conferido em 13 de outubro de 2026).

Qual você deve escolher?

Escolha pela linguagem e pela forma de carregar o sistema. O Gatling combina com times JVM e testes em modelo aberto, e o Locust com times Python e testes com lógica própria.

Escolha o Gatling em vez do Locust se o seu time vive na JVM e quer testes em Java, Kotlin ou Scala construídos com Maven, Gradle ou sbt, se você precisa de um modelo aberto, como uma taxa de chegada fixa, se precisa de JMS ou Server-Sent Events, ou se quer assertions e um relatório sem código extra.

Escolha o Locust em vez do Gatling se o seu time escreve Python e quer que os testes reutilizem um cliente Python interno, se quer uma interface web para iniciar uma execução e mudar a carga enquanto ela roda, se precisa do modo distribuído na ferramenta gratuita, ou se o sistema recebe principalmente usuários que esperam e o seu protocolo tem uma biblioteca Python compatível com o gevent.

Para um construtor de testes com interface gráfica, olhe o JMeter, e para um único binário sem JVM nem Python, olhe o k6.

FAQ

O Gatling é mais rápido que o Locust? Não medimos isso por conta própria, então não vamos apontar um vencedor. A comparação justa é rodar o mesmo cenário com as duas ferramentas no seu próprio hardware.

O Locust consegue rodar simulações do Gatling? Não segundo a documentação do Locust, que descreve os testes apenas como código Python. Uma simulação do Gatling precisa ser reescrita como locustfile, e o inverso também vale.

A LoadFocus consegue rodar testes do Gatling ou do Locust? 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, e para o Locust use o modo master e workers ou o operador do Kubernetes.

Leituras relacionadas

• Teste de carga com Gatling: análise da ferramenta JVM
• Teste de carga com Locust: análise da ferramenta Python
• 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

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