Você quer saber o que acontece com sua API quando 80 pessoas acessam o checkout ao mesmo tempo. Então você abre o Locust, e a primeira coisa que ele pede para você fazer é escrever uma classe Python. Defina um HttpUser. Decore métodos com @task. Crie um locustfile.py, configure um ambiente virtual, fixe algumas dependências e, em seguida, descubra por que seu token de autenticação não está sendo reutilizado em todas as requisições. Nada disso é o teste. É o custo de admissão antes do teste começar.
Locust é uma ótima ferramenta, e esse design "code-first" (primeiro o código) é o seu objetivo. Mas se seu objetivo é uma resposta direta para “meu endpoint de login aguenta 100 usuários concorrentes?”, escrever e manter um harness Python é muita 'yak-shaving' (esforço desnecessário) para um único número. Existe um caminho mais rápido quando as requisições de API que você quer testar já estão em um cliente de API. Com o Apidog, você aponta um teste de desempenho para um cenário de teste existente, define o número de usuários virtuais e uma duração, e lê a taxa de transferência (throughput), tempo de resposta e taxa de erros em um gráfico ao vivo. Sem locustfile, sem pip install, sem Python algum.
O que o Locust realmente faz bem
Locust é uma ferramenta de teste de carga de código aberto escrita em Python, e é boa no que foi construída para fazer. Você descreve o comportamento do usuário como código. Um usuário virtual é uma classe Python, e as coisas que esse usuário faz são métodos que você marca como tarefas. Aqui está a estrutura canônica de um locustfile.py:
from locust import HttpUser, task, between
class CheckoutUser(HttpUser):
wait_time = between(1, 3)
@task(3)
def browse_products(self):
self.client.get("/api/products")
@task(1)
def add_to_cart(self):
self.client.post("/api/cart", json={"sku": "AK-204", "qty": 1})
Você o executa com locust -f locustfile.py, abre a interface web em localhost:8089, define a contagem de usuários e a taxa de spawn, e observa os números subirem. Como o comportamento é código, você obtém um poder expressivo real. Lógica condicional, distribuições de tarefas ponderadas, jornadas de usuário sequenciais, clientes personalizados para protocolos além de HTTP, estado compartilhado entre requisições. A ponderação @task(3) versus @task(1) acima significa que a navegação acontece três vezes mais frequentemente do que adicionar ao carrinho, o que é o tipo de realismo que uma lista de requisições simples não consegue capturar.
Locust também escala horizontalmente. Execute-o distribuído por múltiplos processos ou máquinas de worker e um único mestre os coordena, para que você possa ir além do que uma única máquina pode gerar. Ele é baseado em eventos ('event-driven') nos bastidores, então cada worker suporta milhares de usuários concorrentes sem que uma thread por usuário consuma memória. Para uma equipe que já trabalha com Python, trata seus testes de carga como código versionado e precisa modelar comportamentos complexos de usuário em várias etapas, o Locust é uma excelente escolha. Nada disso está em discussão.
O custo é o código. Cada teste é um programa que você escreve, depura e mantém. Se sua API muda, o locustfile muda. Se um novo engenheiro precisa executar o teste, ele precisa de um ambiente Python compatível. E se você já não escreve Python, a própria linguagem se torna um pré-requisito para responder a uma pergunta que não tem nada a ver com Python.
Onde o modelo 'code-first' se torna fricção
A fricção aparece em três lugares.
Primeiro, a configuração. Antes de medir qualquer coisa, você instala o Python, cria um ambiente virtual, pip install locust e escreve o harness. Para uma verificação rápida de "este endpoint aguenta 50 usuários?", isso é mais encanamento do que carga útil.
Segundo, a duplicação. Você provavelmente já tem essas requisições definidas em algum lugar. Talvez no Postman, talvez em um arquivo .http, talvez em um cliente de API que sua equipe usa todos os dias. O locustfile redescreve requisições que já existem, incluindo o fluxo de autenticação, os cabeçalhos, os corpos das requisições. Agora você mantém duas cópias do mesmo conhecimento da API, e elas se desviam.
Terceiro, as pessoas que precisam da resposta. Um engenheiro de QA, um gerente de produto ansioso com um lançamento, ou um desenvolvedor frontend que apenas quer saber se a API aguenta o e-mail de marketing, todos precisam do resultado do teste de carga. Eles não precisam necessariamente ler ou escrever Python para merecer isso. Quando o teste está bloqueado por um locustfile, a resposta está bloqueada por um conjunto de habilidades.
Se seus testes de carga realmente precisam de lógica de ramificação e clientes de protocolo personalizados, essa fricção vale a pena e o Locust é a ferramenta certa. Para o caso comum de “executar minhas requisições reais de API sob carga concorrente e mostrar os números”, vale a pena questionar se a camada Python está te trazendo algum benefício.
A abordagem Apidog: teste de carga das requisições que você já tem
Apidog aborda o teste de carga de outra direção. Você não escreve um script que descreve requisições. Você pega requisições que já construiu e as executa sob carga. A unidade de um teste de carga é um cenário de teste, que é apenas um conjunto ordenado de requisições de API com seus ambientes, variáveis e asserções já anexados. Se você usou o Apidog para testar ou depurar um endpoint, a requisição já está lá. O teste de desempenho o reutiliza.
Aqui está o fluxo completo.
- Abra o cenário de teste que você deseja testar sob carga. Este é o mesmo cenário que você executaria como um teste funcional normal, com as mesmas requisições e as mesmas variáveis de ambiente.
- Escolha executá-lo como um teste de desempenho em vez de uma única passagem.
- Defina o número de usuários virtuais. O Apidog suporta até 100 usuários virtuais, cada um repetindo todas as requisições no cenário em paralelo durante todo o teste.
- Defina a duração do teste. É por quanto tempo os usuários virtuais continuarão em loop.
- Defina uma duração de ramp-up se desejar uma subida gradual. Nos primeiros X minutos, o Apidog coloca os usuários online incrementalmente, em vez de todos de uma vez; defina para 0 e cada usuário virtual iniciará imediatamente.
- Se o seu cenário é 'data-driven' (orientado por dados), escolha um modo de correspondência. “Random Match” faz com que cada usuário virtual puxe uma linha aleatória dos seus dados de teste em cada loop; “Sequential Match” percorre as linhas em ordem.
- Inicie o teste e observe o painel ao vivo.
O gráfico é atualizado em tempo real. Para cada API no cenário, você obtém Requisições Totais, Taxa de Transferência Média (Throughput), Tempo Médio de Resposta, Tempo Máximo e Mínimo de Resposta e Erros. Passe o mouse sobre o gráfico para ver os números de um determinado período de tempo. Uma aba 'Erro' detalha as requisições com falha para que você possa ver qual endpoint começou a falhar e quando. Quando a execução termina, a aba 'Relatórios de Teste' mantém o histórico para que você possa comparar a execução de hoje com a da semana passada após o envio de uma alteração.
O ponto principal é que não há locustfile para escrever e nenhum ambiente Python para gerenciar. A mesma requisição que passou no seu teste funcional é a requisição que está gerando carga. Essa é a diferença entre descrever um teste de carga e executar um. Apidog é uma plataforma de API tudo-em-um, então o design, depuração, teste funcional e teste de carga de um endpoint acontecem a partir de uma única definição desse endpoint.
Uma comparação concreta
Digamos que você queira confirmar se um endpoint de login aguenta 100 usuários concorrentes por dois minutos, com um ramp-up de 30 segundos.
No Locust, você escreve uma classe de usuário com uma tarefa que envia credenciais, lida com o token que a resposta retorna, o armazena para quaisquer chamadas subsequentes, salva o arquivo, inicia locust -f login_test.py, abre a interface web e insere 100 usuários, uma taxa de spawn e um tempo de execução. Se o tratamento do token estiver errado, você depura o Python antes de depurar sua API.
No Apidog, você abre o cenário de teste de login que você já construiu, muda para um teste de desempenho, digita 100 para usuários virtuais, 2 minutos para duração, 30 segundos para ramp-up e o inicia. A autenticação que já funcionava no seu teste funcional ainda funciona, porque é o mesmo cenário. Você lê a curva de tempo de resposta e a taxa de erros conforme eles acontecem.
Ambos chegam ao mesmo tipo de resposta. Um pede para você escrever e manter um programa primeiro. O outro reutiliza o que você já tem. Para jornadas de usuário complexas e modeladas em código, o programa vale a pena. Para "meu endpoint é rápido e estável sob carga?", a reutilização ganha em tempo.
Limites honestos de ambos os lados
Seja claro sobre os trade-offs, porque escolher a ferramenta errada desperdiça um dia de qualquer forma.
O teste de desempenho do Apidog atinge o máximo de 100 usuários virtuais em uma única execução, e a carga é gerada a partir da sua máquina executando o aplicativo. Se você precisa simular dezenas de milhares de usuários ou gerar carga de várias regiões geográficas ao mesmo tempo, isso está além do que o teste de desempenho no aplicativo visa, e uma configuração distribuída como workers do Locust ou um cluster de geração de carga dedicado é a escolha certa. O Apidog também registra requisições com falha estatisticamente, em vez de capturar o corpo completo da requisição e resposta para cada falha, então a depuração forense aprofundada de uma chamada específica com falha durante o carregamento não é seu ponto forte.
O trade-off do Locust é o que este artigo inteiro aborda. O poder vem do código, e o código é um custo permanente. Você mantém um locustfile por cenário, mantém um ambiente Python e aceita que qualquer pessoa que queira executar o teste precisa ler Python para entendê-lo. Para contagens muito altas de usuários virtuais e lógica de protocolo personalizada, esse custo lhe traz algo real. Para a verificação diária de carga de API, é uma sobrecarga.
Uma regra razoável: se você pode descrever o teste como “execute estas requisições com esta concorrência por este tempo”, use o teste de desempenho no aplicativo. Se você precisa de ramificação condicional, gráficos de tarefas ponderadas, clientes personalizados ou contagens de usuários na casa das centenas de milhares, use o código. Para uma visão mais ampla de onde cada opção se encaixa, veja nosso resumo das principais ferramentas de teste de carga e a comparação de ferramentas de teste de carga específicas para API.
Interpretando os números que você recebe
Um teste de carga só é útil se você souber o que a saída significa. Quatro métricas carregam a maior parte do peso.
Taxa de Transferência (RPS/TPS) são requisições ou transações por segundo, a taxa que sua API realmente atendeu. É o limite do que seu sistema pode suportar. Se a taxa de transferência se estabiliza enquanto você continua adicionando usuários virtuais, você encontrou um ponto de saturação.
Tempo de resposta (latência) é o tempo que cada requisição levou. Observe a média, mas observe o máximo com mais atenção. Uma média saudável com um máximo feio significa que alguns usuários estão tendo uma experiência ruim, mesmo que a maioria esteja bem. A latência de cauda é onde os usuários reais sentem dor.
Taxa de erro é a porcentagem de requisições que falharam. Um teste limpo com baixa carga que começa a lançar 500s ou timeouts conforme os usuários virtuais aumentam está te dizendo exatamente onde o sistema falha. O ponto onde os erros começam é frequentemente mais interessante do que o número bruto da taxa de transferência.
Concorrência é quantos usuários virtuais estão ativos. No Apidog, esta é a contagem de usuários virtuais que você define, e o ramp-up controla a rapidez com que você chega lá. O ramp-up importa porque um sistema que suporta 100 usuários atingidos gradualmente ainda pode falhar se todos os 100 chegarem no mesmo segundo.
Se você quiser a versão mais aprofundada disso, nosso guia de teste de desempenho de API explora métricas, tipos de teste e como ler as curvas, e o artigo sobre fundamentos de teste de desempenho cobre a disciplina mais ampla.
Como isso se encaixa nas ferramentas com as quais você já compara
Se você já usou o JMeter, o modelo mental é similar ao do Apidog, já que ambos permitem configurar um teste de carga através de uma interface de usuário em vez de código. O JMeter troca isso por um plano de teste mais pesado baseado em XML e uma curva de aprendizado mais íngreme; nosso tutorial de teste de carga com JMeter cobre isso em detalhes. Se você executou carga através do collection runner do Postman, você viu uma versão mais leve da mesma ideia, abordada em teste de carga com Postman, e o Apidog adiciona relatórios de desempenho dedicados sobre requisições que você também pode usar para teste de API sem Postman. O Apidog se posiciona entre a simplicidade sem código que as pessoas desejam e a reutilização de requisições que impede você de manter um harness separado.
O fio condutor em todos eles é que seu teste de carga deve reutilizar o conhecimento da API que você já codificou, e não duplicá-lo em uma nova linguagem. O Locust o duplica em Python porque Python é sua força. O Apidog reutiliza seus cenários porque a reutilização é sua força.
Começando
Se suas requisições já estão no Apidog, você pode executar um teste de desempenho nos próximos cinco minutos. Abra um cenário de teste, mude para um teste de desempenho, defina usuários virtuais e duração, e inicie-o. Se você vem de um locustfile e está cansado de manter a camada Python, reconstrua o cenário uma vez no aplicativo e você não precisará escrever código de teste de carga novamente para aquele endpoint.
Baixe o Apidog e aponte um teste de desempenho para um endpoint que você já testa. Você terá curvas de taxa de transferência (throughput), latência e taxa de erros antes mesmo de terminar de escrever o locustfile equivalente. O Locust continua sendo a resposta certa para carga distribuída e modelada em código em grande escala. Para a pergunta que a maioria dos desenvolvedores realmente faz, execute as requisições que você já tem.
Perguntas Frequentes
O Apidog é um substituto direto para o Locust?
Não para todo trabalho. Para testes de carga de requisições de API com até 100 usuários virtuais sem escrever código, o Apidog substitui todo o fluxo de trabalho do Locust porque executa diretamente seus cenários de teste existentes. Para carga distribuída com contagens muito altas de usuários ou protocolos não-HTTP personalizados modelados em código, o Locust ainda é a melhor opção.
Preciso escrever algum código para fazer teste de carga no Apidog?
Não. Você configura usuários virtuais, duração do teste e tempo de ramp-up na interface do usuário, e o teste executa as requisições de um cenário de teste que você já construiu. Não há locustfile e nenhum ambiente Python para configurar.
Quantos usuários virtuais o Apidog pode simular?
Até 100 usuários virtuais em um único teste de desempenho. Cada um repete todas as APIs no cenário em paralelo pela duração que você definir. Se você precisa de muito mais do que isso ou carga de múltiplas regiões, uma ferramenta distribuída baseada em código como o Locust é a escolha certa.
Quais métricas o teste de desempenho do Apidog reporta?
Para cada API no cenário, você obtém Requisições Totais, Taxa de Transferência Média (Throughput), Tempo Médio de Resposta, Tempo Máximo e Mínimo de Resposta e Erros, atualizados ao vivo em um gráfico. Uma aba de Erro detalha as requisições com falha, e a aba Relatórios de Teste mantém o histórico de execuções para que você possa comparar entre as alterações.
Posso fazer teste de carga com requisições data-driven?
Sim. Se o seu cenário é baseado em dados de teste, escolha “Random Match” para que cada usuário virtual puxe uma linha aleatória a cada loop, ou “Sequential Match” para percorrer as linhas em ordem.
Ainda devo usar o Locust para alguma coisa?
Sim, quando suas forças correspondem à sua necessidade: comportamento do usuário definido por código com ramificação e tarefas ponderadas, clientes de protocolo personalizados e geração de carga distribuída que supera bem os 100 usuários virtuais. Use a ferramenta certa para o formato do teste.