Vegeta Teste de Carga: Tutorial de HTTP com Taxa Constante

Você quer saber como sua API se comporta exatamente a 500 requisições por segundo, não “tão rápido quanto N threads puderem martelar”. A maioria das ferramentas de carga fixa a concorrência e deixa a taxa de requisições flutuar. Vegeta faz o oposto: você define a taxa, e ele envia essa quantidade de requisições por segundo independentemente de como o servidor responde. Essa diferença é importante quando você se importa com o número que a folha de respostas usa, o throughput em uma carga alvo e a latência que você realmente prometeria em um SLO.

botão

O que é Vegeta

Vegeta é uma ferramenta de teste de carga HTTP de linha de comando escrita em Go. Também pode ser usada como uma biblioteca Go, mas este tutorial foca na CLI. A ideia central é uma taxa de requisições constante. Você diz ao Vegeta “envie 100 requisições por segundo por 30 segundos,” e ele mantém esse ritmo adicionando workers conforme necessário. Se o servidor diminuir a velocidade, Vegeta continua emitindo novas requisições conforme o planejado, em vez de esperar que as antigas terminem.

Esse design oferece um teste de carga de modelo aberto. O tráfego real chega em seu próprio ritmo; os usuários não pausam e esperam por seu endpoint lento antes que o próximo usuário apareça. Uma ferramenta baseada em taxa corresponde a esse comportamento.

Carga baseada em taxa vs. baseada em concorrência

Aqui está a diferença que confunde as pessoas.

Uma ferramenta baseada em concorrência (um pool fixo de threads ou usuários virtuais, cada um repetindo requisição-resposta) usa um modelo fechado. Quando o servidor fica lento, o loop trava, então a taxa de requisições real cai. Você pediu por carga, mas a ferramenta recuou silenciosamente. Isso esconde o acúmulo que você veria em produção.

Uma ferramenta baseada em taxa como Vegeta usa um modelo aberto. Você fixa a taxa de chegada. Se o servidor não consegue acompanhar, as requisições se acumulam na fila, a latência aumenta e o relatório mostra isso. Você obtém uma imagem honesta do que acontece quando a demanda excede a capacidade.

Nenhum dos modelos está errado. Use a concorrência quando quiser saber “quantos usuários simultâneos consigo suportar”. Use um modelo de taxa quando quiser saber “o que acontece com 2.000 requisições por segundo”. Vegeta é do segundo tipo. Para um mapa mais amplo do espaço de ferramentas, veja as principais ferramentas de teste de carga de API.

Instalar Vegeta

Escolha o que melhor se adapta à sua configuração.

Homebrew no macOS:

brew update && brew install vegeta

Outros gerenciadores de pacotes:

# MacPorts
port install vegeta

# Arch Linux
pacman -S vegeta

# FreeBSD
pkg install vegeta

Do código-fonte com Go instalado:

git clone https://github.com/tsenart/vegeta
cd vegeta
make vegeta

Você também pode baixar um binário pré-construído da página de lançamentos do GitHub. Confirme a instalação:

vegeta --help

O pipeline principal

Vegeta é construído em torno de pipes Unix. Um alvo entra, um ataque é executado e um relatório sai. A execução útil mais simples é uma linha:

echo "GET http://localhost:8080/" | vegeta attack -duration=5s -rate=100 | vegeta report

Leia da esquerda para a direita:

echo escreve um alvo (um método e URL) na saída padrão.
vegeta attack lê esse alvo da entrada padrão e dispara 100 requisições por segundo por 5 segundos. Isso totaliza 500 requisições.
vegeta report lê o fluxo de resultados binários e imprime um resumo.

A flag -rate recebe requisições por unidade de tempo. -rate=100 e -rate=100/1s significam a mesma coisa. -rate=50/500ms significa 50 requisições a cada 500 milissegundos. Definir -rate=0 remove o limite e envia o mais rápido possível, o que é um teste completamente diferente.

Um relatório de texto se parece com isto:

Requests      [total, rate, throughput]  500, 100.20, 100.18
Duration      [total, attack, wait]      4.991s, 4.990s, 1.2ms
Latencies     [min, mean, 50, 90, 95, 99, max]  412us, 1.3ms, 1.1ms, 1.9ms, 2.4ms, 5.1ms, 12ms
Bytes In      [total, mean]              128500, 257.00
Bytes Out     [total, mean]              0, 0.00
Success       [ratio]                    100.00%
Status Codes  [code:count]               200:500
Error Set:

Leia a linha de latência primeiro. A coluna 50 é a mediana. A coluna 99 é a cauda: 1 por cento das requisições foram mais lentas que isso. As caudas são onde os usuários sentem dor, então uma média saudável com um 99º percentil problemático ainda é um problema. Verifique Success [ratio] e Status Codes em seguida. Uma taxa de sucesso de 100 por cento com todos os códigos 200 significa que o servidor suportou a carga. Qualquer código 5xx ou um Error Set não vazio significa que ele começou a falhar.

Salve os resultados, depois relate de várias maneiras

Enviar diretamente para o report é bom para uma análise rápida. Para qualquer coisa que você revisitará, salve os resultados brutos em um arquivo primeiro e, em seguida, gere todos os relatórios que desejar a partir desse arquivo.

echo "GET http://localhost:8080/" | \
  vegeta attack -duration=10s -rate=200 -output=results.bin

Agora a execução está capturada em results.bin. Produza um relatório de texto:

vegeta report results.bin

Produza JSON estruturado para um dashboard ou uma diferença entre execuções:

vegeta report -type=json results.bin > metrics.json

Produza um histograma de latência com intervalos que você escolher:

vegeta report -type='hist[0,2ms,5ms,10ms,25ms,100ms]' results.bin

O histograma conta quantas requisições caíram em cada faixa de latência. É uma maneira rápida de ver se a latência está fortemente agrupada ou espalhada por uma ampla gama.

O formato do arquivo de alvos

APIs reais precisam de mais do que um GET. Mova seus alvos para um arquivo e passe-o com -targets. O formato HTTP padrão é baseado em linhas e legível.

Crie targets.txt:

GET http://localhost:8080/api/users

POST http://localhost:8080/api/users
Content-Type: application/json
@./payload.json

GET http://localhost:8080/api/users/42

Algumas regras fazem isso funcionar:

A primeira linha de cada alvo é MÉTODO URL.
As linhas de cabeçalho seguem diretamente abaixo da linha do método, um Chave: Valor por linha.
Uma linha começando com @ nomeia um arquivo cujo conteúdo se torna o corpo da requisição.
Uma linha em branco separa um alvo do próximo.
Linhas começando com # são comentários.

Coloque seu corpo JSON em payload.json:

{ "name": "Ada", "role": "engineer" }

Execute o ataque contra o arquivo:

vegeta attack -targets=targets.txt -rate=50 -duration=30s | vegeta report

Vegeta percorre os alvos em ordem e continua em loop até que a duração termine. Você também pode adicionar cabeçalhos globais na linha de comando com -header, o que é útil para autenticação:

vegeta attack -targets=targets.txt -rate=50 -duration=30s \
  -header="Authorization: Bearer $TOKEN" | vegeta report

Para execuções programáticas ou de alto volume, Vegeta também lê um formato de alvo JSON. Cada linha é um objeto JSON, e você o seleciona com -format=json:

{"method": "GET", "url": "http://localhost:8080/api/users"}
{"method": "POST", "url": "http://localhost:8080/api/users", "header": {"Content-Type": ["application/json"]}, "body": "eyJuYW1lIjoiQWRhIn0="}

O campo body é codificado em base64. Este formato funciona bem em streaming, então você pode gerar alvos em tempo real e passá-los diretamente com -lazy para eficiência de memória.

Gráficos e histogramas

Um único número esconde tendências. Se a latência se degrada no meio de uma execução, você quer ver a curva. O comando plot do Vegeta transforma um fluxo de resultados em uma página HTML interativa:

vegeta attack -targets=targets.txt -rate=100 -duration=60s | \
  vegeta plot > plot.html

Abra plot.html em um navegador. Você obterá um gráfico de série temporal da latência ao longo da execução, então uma rampa lenta ou um pico no meio do teste é óbvio. Você pode plotar várias execuções juntas para comparar os níveis de carga:

vegeta attack -rate=50  -duration=30s -targets=targets.txt -output=50qps.bin
vegeta attack -rate=100 -duration=30s -targets=targets.txt -output=100qps.bin
vegeta plot 50qps.bin 100qps.bin > compare.html

Para ambientes sem interface gráfica (headless), pule o gráfico e exporte um histograma ou o CSV bruto com encode:

vegeta encode -to=csv results.bin > results.csv

Quando usar o Vegeta

Recorra ao Vegeta quando a questão for sobre taxa e capacidade:

Você precisa de throughput e latência em um alvo específico de requisições por segundo.
Você quer encontrar a taxa na qual a latência ou a taxa de erros começa a subir.
Você está comparando duas builds ou duas configurações de infraestrutura sob carga idêntica e repetível.
Você quer uma ferramenta scriptável que se encaixe em um pipeline de shell e em um trabalho de CI sem GUI.

É um instrumento focado. Ele envia requisições HTTP a uma determinada taxa e mede como o servidor responde. Ele não roteiriza jornadas de usuário com múltiplos passos e lógica de ramificação, e não valida corpos de resposta além dos códigos de status. Esse foco é uma característica; ele mantém a ferramenta pequena e os resultados limpos.

Se você o estiver comparando com outras ferramentas, as comparações em teste de carga k6 e teste de carga JMeter cobrem as alternativas de modelo de concorrência. Para os conceitos e métricas subjacentes, o tutorial de teste de desempenho de API é um bom ponto de partida.

Onde o teste funcional se encaixa

O teste de carga responde “é rápido o suficiente”. Ele não responde “está correto”. Uma execução do Vegeta pode relatar 100 por cento de 200s enquanto o endpoint retorna o usuário errado, um preço desatualizado ou um campo JSON malformado. Cada uma dessas respostas é um 200 rápido e bem-sucedido no que diz respeito a uma ferramenta de carga.

A correção precisa de uma verificação diferente: asserções no corpo da resposta, no esquema e nas regras de negócio. Isso é teste funcional, e ele deve ser feito antes e em conjunto com suas execuções de carga. O padrão saudável é validar se a API está correta e, em seguida, medir como ela se comporta sob carga.

É aqui que o Apidog complementa uma ferramenta como o Vegeta, em vez de competir com ela. No Apidog, você constrói cenários de teste com asserções visuais sobre status, cabeçalhos e campos JSON, encadeia requisições e as conduz a partir de arquivos de dados. Você confirma que a API retorna os dados corretos. Vegeta então confirma que ela permanece rápida quando esse caminho correto é acessado centenas de vezes por segundo. Duas ferramentas, duas perguntas.

Apidog também oferece uma CLI headless para que esses cenários funcionais sejam executados no mesmo pipeline de CI que sua etapa de carga. Instale-o com Node:

npm install -g apidog-cli

Então execute um cenário ou suíte salvo por ID, com relatórios para o seu pipeline:

apidog run --access-token "$APIDOG_ACCESS_TOKEN" \
  -t <scenarioOrSuiteId> \
  -e <environmentId> \
  -r cli,html,junit

A flag -t recebe o ID do cenário, pasta ou suíte, -e recebe o ID do ambiente, e -r escolhe um ou mais relatórios (cli, html, json, junit). A saída junit se encaixa na maioria dos dashboards de CI. Veja o tutorial da linha de comando da CLI do Apidog para uma execução passo a passo, e o guia de pipeline CI/CD para um fluxo de trabalho de copiar e colar. Execute o gate funcional primeiro, depois deixe Vegeta medir os endpoints que passaram.

Perguntas Frequentes

Vegeta suporta requisições POST com corpo?

Sim. No arquivo de alvos HTTP, coloque o método e a URL na primeira linha, adicione um cabeçalho Content-Type e referencie um arquivo de corpo com @./payload.json. No formato JSON, defina o method, url e um campo body codificado em base64.

O que -rate=0 faz?

Ele remove o limite de taxa e envia requisições tão rápido quanto os workers e as conexões permitirem. Esse é um teste de throughput máximo, que é diferente de um teste de taxa constante controlada. Para medições de capacidade repetíveis, defina uma taxa explícita.

Como leio os percentis de latência?

A linha de latência do relatório mostra os percentis mínimo, médio e 50º, 90º, 95º, 99º e máximo. Concentre-se nos 95º e 99º. Eles descrevem a cauda lenta que os usuários reais experimentam, que uma média sozinha pode esconder.

Vegeta pode verificar se minha API retorna dados corretos?

Não. Ele mede throughput, latência e códigos de status. Ele não faz asserções sobre corpos de resposta ou esquemas. Combine-o com uma ferramenta de teste funcional para correção, e então use Vegeta para taxa e latência.

Como executo Vegeta em CI?

É um binário único que lê da entrada padrão e escreve resultados, então ele se encaixa em qualquer etapa de shell. Salve os resultados com -output e, em seguida, gere um relatório de texto ou JSON como um artefato de build. Adicione um gate funcional, como a CLI do Apidog, antes da etapa de carga para que você meça apenas os endpoints que já passaram em suas asserções.