Um teste de carga só é útil quando representa uma pergunta real. “Quantas requisições a API suporta?” costuma ser vago demais. Uma pergunta melhor seria: “O sistema sustenta a combinação esperada de operações no pico mantendo p95 e taxa de erros dentro dos objetivos do serviço?”
O Locust facilita a expressão de workloads em Python. O trabalho mais valioso é projetar um modelo realista e interpretar como o sistema se comporta sob pressão.
Comece por um modelo de workload
Defina usuários pelo comportamento, não apenas pela quantidade. Um fluxo de comércio pode combinar navegação, busca, carrinho, autenticação e checkout com frequências diferentes. Use tempos de espera e pesos próximos de produção, em vez de executar tudo o mais rápido possível.
Separe os formatos de carga:
- baseline valida capacidade normal;
- ramp revela onde o desempenho começa a degradar;
- spike exercita demanda repentina;
- soak expõe vazamentos e acúmulo de recursos;
- stress identifica o limite de falha e a recuperação.
Dados sintéticos gerados com Faker evitam colisões, mas a aleatoriedade precisa ser reproduzível. Use seeds ao investigar regressões e não gere valores que a validação real rejeitaria.
Meça a distribuição
A média esconde requisições lentas. Acompanhe p50, p95 e p99 junto com throughput e taxa de erro. Correlacione esses sinais com saturação: CPU, memória, conexões do banco, profundidade de filas, cache, rede e latência das dependências.
O teste passa porque atende limites explícitos, não porque o dashboard “parece bom”. Critérios devem declarar workload, taxa, latência, erro e duração. Esses números vêm das expectativas do produto e dos objetivos de serviço, não de um template genérico.
Evite conclusões falsas
O gerador de carga pode virar o gargalo. Monitore CPU, rede e conexões e distribua workers quando necessário. Confirme que dados, caches e autenticação funcionam como esperado. Períodos de aquecimento devem permanecer visíveis.
O ambiente também importa. Um banco pequeno em stage não prevê capacidade de produção; testar diretamente em produção pode afetar clientes. Documente diferenças de topologia, dataset, autoscaling, dependências e quotas para deixar claro o que o resultado prova.
Diagnostique, altere e repita
Ao encontrar um limite, preserve a evidência: versão do workload, aplicação, infraestrutura, métricas, traces e erros representativos. Altere uma variável importante por vez e repita o mesmo cenário.
Engenharia de performance não é uma competição pelo maior número de requests por segundo. É um processo controlado para descobrir como o sistema se comporta, onde satura e se consegue se recuperar.
O Locust oferece um motor acessível. A qualidade ainda depende da pergunta, do realismo do workload e da disciplina usada para interpretar o resultado.
Referência
O guia oficial para escrever um workload do Locust documenta usuários simulados, tarefas ponderadas, tempos de espera e validação de respostas.