Teste de carga com Locust: análise da ferramenta Python

O Locust é uma ferramenta de teste de carga em Python, gratuita e sob licença MIT, em que cada teste é um programa Python, executado por usuários leves a partir de uma interface web ou da linha de comando. O teste de carga com Locust combina com equipes que escrevem Python e testam principalmente serviços HTTP. Quem precisa de muitos protocolos prontos para uso ou de um editor gráfico de testes fica mais bem servido pelo JMeter, e quem escreve JavaScript, pelo k6.

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

Quem desenvolve o Locust, e ele ainda é mantido?

Lars Holmberg mantém o Locust, e a Microsoft patrocina esse trabalho. As versões saem com frequência: 17 até agora em 2026.

O README do Locust cita os dois. O PyPI mostra a 2.46.7, publicada em 4 de outubro de 2026, como a versão mais recente, e exige Python 3.11 ou mais recente (conferido em 9 de outubro de 2026).

Como funciona um locustfile?

Um locustfile é um módulo Python comum com pelo menos uma classe de usuário. Cada usuário simulado executa suas tarefas uma após a outra e faz uma pausa entre elas, conforme o seu wait_time.

Segundo o guia do locustfile, o HttpUser dá a cada usuário um client que encapsula o python-requests, mantém os cookies e registra cada requisição. Os métodos marcados com @task são sorteados, com peso dado pelo número no decorator, e o on_start roda uma vez por usuário. Este usuário faz login, navega pelo catálogo quatro vezes mais do que finaliza compras e inicia no máximo uma tarefa a cada 10 segundos:

from locust import HttpUser, task, constant_pacing


class Shopper(HttpUser):
    wait_time = constant_pacing(10)

    def on_start(self):
        self.client.post("/login", json={"user": "demo"})

    @task(4)
    def browse(self):
        self.client.get("/products?page=2", name="/products")

    @task
    def checkout(self):
        with self.client.post(
            "/checkout", catch_response=True
        ) as resp:
            if "order_id" not in resp.text:
                resp.failure("no order id")

O catch_response permite marcar uma requisição como falha pelo conteúdo, e o name agrupa URLs variáveis em uma única linha das estatísticas. As outras funções de espera são constant, between, constant_throughput e, desde a versão 2.46.6, poisson; nosso guia sobre tempo de pensamento em teste de carga explica como essas pausas moldam a carga. A documentação acrescenta que o tempo de espera só consegue limitar a vazão e não inicia novos usuários para atingir uma taxa-alvo. Um teste do Locust é, portanto, um grupo fixo de usuários: um modelo de carga fechado.

É melhor usar a interface web ou o modo headless?

Use a interface web enquanto explora e o modo headless para execuções repetíveis.

O comando locust sobe uma interface web na porta 8089. Nela você define o host, os usuários e a rampa de subida, acompanha gráficos ao vivo e muda a carga no meio do teste. O modo headless recebe as mesmas configurações como opções:

locust -f locustfile.py --headless -u 200 -r 10 -t 10m \
  --host https://staging.example.com \
  --csv results --html report.html

-u define os usuários, -r quantos começam por segundo e -t a duração, já contando a rampa de subida. As mesmas opções também funcionam em locust.conf ou pyproject.toml.

Como funciona o modo distribuído?

Um processo master cuida da interface web e coordena, enquanto processos worker executam os usuários e devolvem as estatísticas. Você precisa de um worker por núcleo de CPU, porque um processo Python não consegue aproveitar totalmente mais de um núcleo.

Segundo a documentação de carga distribuída, um único processo passa de mil requisições por segundo com um plano de teste simples, então testes maiores são distribuídos:

# na máquina master
locust -f locustfile.py --master
# em cada máquina worker, um worker por núcleo
locust -f - --worker --master-host 10.0.0.5 --processes -1

-f - busca o locustfile no master. O --processes depende de fork() e por isso não funciona no Windows, e toda mudança no locustfile exige reiniciar todos os processos. A documentação também cobre um operador para Kubernetes e o Azure Load Testing (conferido em 9 de outubro de 2026).

A LoadFocus, que publica este site, não roda testes do Locust. Ela roda planos de teste JMeter e scripts k6 a partir de 25 regiões na nuvem, então para o Locust os caminhos acima continuam sendo as formas de escalar.

O Locust consegue testar protocolos além de HTTP?

Sim, desde que você traga um cliente Python para o protocolo. Só HTTP e HTTPS vêm embutidos.

A página sobre outros protocolos mostra como encapsular um cliente para que cada chamada seja registrada, com exemplos para XML-RPC e gRPC e classes de usuário experimentais para MQTT, Socket.IO e OpenAI. O projeto separado locust-plugins adiciona usuários para Kafka, FTP, Selenium e Playwright (conferido em 9 de outubro de 2026).

Para HTTP existe ainda o FastHttpUser, que usa o geventhttpclient e consome bem menos CPU. No melhor caso, segundo a documentação, um processo chega a cerca de 16.000 requisições por segundo, contra 4.000 com o HttpUser. O FastHttpUser não deixa cada requisição mais rápida e, por padrão, não verifica certificados TLS.

Que relatórios o Locust entrega, e como ele entra na CI?

Você recebe gráficos ao vivo na interface web e, se pedir, arquivos de resultados. Na CI, o Locust sai com código 1 se alguma requisição falhou.

Pela referência de configuração, --csv grava arquivos de estatísticas, histórico e falhas, --html salva um relatório e --json imprime as estatísticas finais. O --otel exporta para um backend OpenTelemetry. A documentação do modo headless mostra um listener que reprova a execução pela taxa de falhas, pelo tempo de resposta médio ou pelo percentil 95, e nosso guia de teste de carga no GitHub Actions o coloca em um workflow.

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

Ele se destaca na lógica dos testes e com muitos usuários simultâneos que passam a maior parte do tempo esperando. Fica mais fraco na taxa de requisições por processo e nos protocolos que você precisa conectar por conta própria.

Como os testes são Python puro, laços, condições, dados gerados e o seu próprio cliente de API funcionam normalmente, e os testes ficam no controle de versão. A página What is Locust diz que o baixo custo de cada usuário combina com cargas muito concorrentes, mas admite que outras ferramentas podem enviar mais requisições por segundo no mesmo hardware.

Os limites que a própria documentação reconhece:

• Um processo Python usa um único núcleo de CPU.
• Bibliotecas que fazem E/S em C bloqueiam o processo, a menos que o gevent consiga aplicar patch nelas.
• O HttpUser não interpreta HTML nem carrega os recursos da página.
• O tempo de espera não consegue adicionar usuários para manter uma taxa de requisições.

Que outras ferramentas Python existem para teste de carga?

O Locust é o motor Python em desenvolvimento ativo. O Molotov, a principal alternativa, não lança nenhuma versão no PyPI desde 2022, e o Taurus roda o Locust por um de seus executores.

O Molotov é uma ferramenta para Python 3.8+ construída sobre asyncio e aiohttp; a versão mais recente no PyPI é a 2.6, de 21 de outubro de 2022, e o último commit do branch principal é de novembro de 2023 (conferido em 21 de outubro de 2026). O Taurus roda um locustfile, ou requisições GET e POST simples escritas em YAML, pelo executor locust. Você instala o Locust por conta própria, em modo distribuído o Taurus inicia só o master e a configuração throughput não tem efeito nesse executor (conferido em 21 de outubro de 2026).

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

Escolha outra ferramenta quando a linguagem, os protocolos ou o modelo de carga dela combinarem melhor com a sua equipe.

Nosso panorama de ferramentas de teste de carga open source coloca o Locust ao lado de outras cinco.

Prefira o k6 quando sua equipe escreve JavaScript, quer critérios de aprovação como thresholds no próprio script ou precisa de um modelo de carga aberto, que é o que os executores arrival-rate do k6 oferecem (conferido em 9 de outubro de 2026). A LoadFocus roda scripts k6 a partir de 25 regiões na nuvem, mas executa cenários arrival-rate com um número fixo de usuários; para manter uma taxa de requisições, rode-os com o próprio k6.

Prefira o JMeter quando você precisa de JDBC, JMS, LDAP ou FTP prontos para uso, como lista o README dele, ou quando seus testadores montam os testes em uma interface gráfica. Locust vs JMeter compara os dois em detalhe.

Prefira o Gatling quando sua equipe trabalha na JVM e quer perfis de injeção abertos e fechados em uma mesma API (conferido em 9 de outubro de 2026). Gatling vs JMeter trata disso com mais detalhe.

FAQ

O Locust é gratuito para uso comercial? Sim. O Locust é distribuído sob a licença MIT, que permite uso comercial, modificação e redistribuição.

Qual versão do Python o Locust exige? Python 3.11 ou mais recente, segundo os metadados no PyPI. Instale com pip install locust, ou rode em um ambiente temporário com uvx locust.

A LoadFocus consegue rodar testes do Locust? Não. A LoadFocus roda planos de teste JMeter e scripts k6. Para escalar um teste do Locust, use o modo master e workers, o operador para Kubernetes ou o Azure Load Testing.

Leituras relacionadas

• Locust vs JMeter: scripts Python ou planos do JMeter?
• Ferramentas de teste de carga open source: seis opções
• k6 vs Locust: scripts JavaScript ou usuários Python?
• Gatling vs Locust: simulações na JVM ou locustfiles Python?

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