DEV Community

Cover image for autocannon: Teste de Carga HTTP com Node.js (Passo a Passo)
Lucas
Lucas

Posted on • Originally published at apidog.com

autocannon: Teste de Carga HTTP com Node.js (Passo a Passo)

Você escreveu um endpoint HTTP. Ele responde corretamente quando você chama uma vez pelo Postman. Mas o que acontece quando 200 clientes acessam esse endpoint ao mesmo tempo? Para responder, você precisa medir requisições por segundo, percentis de latência e quantas respostas retornam status diferente de 2xx. O autocannon entrega esses números direto no terminal em poucos segundos.

Experimente o Apidog hoje

autocannon é uma ferramenta de benchmark HTTP/1.1 escrita em Node.js. Ela dispara um fluxo controlado de requisições para uma URL e retorna métricas de throughput, latência e erros. Neste guia, você vai instalar a ferramenta, executar testes básicos, usar flags úteis, interpretar a saída e automatizar benchmarks em scripts Node.js.

O que é o autocannon

autocannon abre um número definido de conexões concorrentes para uma URL e envia requisições por uma duração configurada ou até atingir uma quantidade total de requisições. Durante a execução, ele coleta amostras de latência, conta respostas e exibe um resumo no final.

Ele responde a uma pergunta específica:

Quanta carga meu servidor suporta e qual é a latência sob essa carga?

Ele não valida se o corpo da resposta está correto, se a API segue sua especificação OpenAPI ou se um fluxo de várias etapas retorna os dados esperados. Para isso, você ainda precisa de testes funcionais e de contrato.

Se você já usou wrk ou Apache Bench, o autocannon ocupa o mesmo espaço, mas com instalação via npm e API programática para uso em JavaScript.

Instalação

Instale globalmente para usar o comando autocannon em qualquer diretório:

npm i autocannon -g
Enter fullscreen mode Exit fullscreen mode

Você precisa ter o Node.js instalado.

Se preferir não instalar globalmente, use com npx:

npx autocannon http://localhost:3000
Enter fullscreen mode Exit fullscreen mode

Para adicionar ao projeto como dependência de desenvolvimento:

npm i autocannon --save-dev
Enter fullscreen mode Exit fullscreen mode

Verifique a instalação:

autocannon --version
Enter fullscreen mode Exit fullscreen mode

Execução básica

A forma mínima é passar uma URL:

autocannon http://localhost:3000
Enter fullscreen mode Exit fullscreen mode

Por padrão, o autocannon executa:

  • 10 conexões concorrentes
  • 10 segundos de duração
  • HTTP/1.1

Na prática, você quase sempre vai ajustar três flags:

  • -c: número de conexões concorrentes
  • -d: duração do teste em segundos
  • -p: pipelining, ou seja, quantas requisições cada conexão envia antes de aguardar resposta

Exemplo:

autocannon -c 100 -d 30 -p 10 http://localhost:3000
Enter fullscreen mode Exit fullscreen mode

Esse comando:

  • abre 100 conexões
  • executa por 30 segundos
  • envia até 10 requisições em pipeline por conexão

Use isso para aumentar gradualmente a carga e identificar o ponto em que a latência começa a subir.

Enviar quantidade fixa de requisições

Se você não quer testar por duração, mas por volume total, use -a:

autocannon -c 10 -a 10000 http://localhost:3000
Enter fullscreen mode Exit fullscreen mode

Esse teste para após concluir 10.000 requisições, independentemente do tempo necessário.

Use:

  • -d para testes de carga em estado estável
  • -a para enviar uma quantidade exata de requisições

Testar endpoints POST com headers e body

Para testar um endpoint POST, combine:

  • -m para método HTTP
  • -H para headers
  • -b para body inline

Exemplo:

autocannon -c 50 -d 20 \
  -m POST \
  -H 'Content-Type=application/json' \
  -H 'Authorization=Bearer YOUR_TOKEN' \
  -b '{"name":"load-test","active":true}' \
  http://localhost:3000/api/users
Enter fullscreen mode Exit fullscreen mode

O formato do header é:

-H 'Chave=Valor'
Enter fullscreen mode Exit fullscreen mode

Repita -H para múltiplos headers.

Se o payload for grande, salve em um arquivo e use -i:

autocannon -m POST \
  -H 'Content-Type=application/json' \
  -i payload.json \
  http://localhost:3000/api/users
Enter fullscreen mode Exit fullscreen mode

Limitar a taxa de requisições

Por padrão, o autocannon envia requisições o mais rápido possível. Para simular uma carga mais realista, limite o total de requisições por segundo com -R:

autocannon -c 50 -R 500 -d 60 http://localhost:3000
Enter fullscreen mode Exit fullscreen mode

Esse comando mantém o teste em aproximadamente 500 requisições por segundo durante 60 segundos.

Use -R quando você quiser medir a latência em uma carga esperada de produção, e não apenas encontrar o ponto de ruptura.

Aquecimento e workers

Em testes mais pesados, duas flags ajudam:

  • -W: faz aquecimento antes de coletar métricas
  • -w: distribui a geração de carga em múltiplas worker threads

Exemplo com workers:

autocannon -c 200 -d 30 -w 4 http://localhost:3000
Enter fullscreen mode Exit fullscreen mode

Use -W para evitar que caches frios ou inicialização de JIT distorçam os primeiros resultados.

Use -w apenas quando o próprio gerador de carga for o gargalo. Um sinal comum é a latência continuar estável mesmo aumentando muito -c, enquanto o throughput não cresce.

Como ler os resultados

Uma saída resumida do autocannon se parece com isto:

Running 10s test @ http://localhost:3000
10 connections

┌─────────┬──────┬──────┬───────┬──────┬─────────┬─────────┬──────────┐
│ Stat    │ 2.5% │ 50%  │ 97.5% │ 99%  │ Avg     │ Stdev   │ Max      │
├─────────┼──────┼──────┼───────┼──────┼─────────┼─────────┼──────────┤
│ Latency │ 0 ms │ 1 ms │ 4 ms  │ 6 ms │ 1.2 ms  │ 0.9 ms  │ 24.1 ms  │
└─────────┴──────┴──────┴───────┴──────┴─────────┴─────────┴──────────┘

251k requests in 10.05s, 27.9 MB read
Enter fullscreen mode Exit fullscreen mode

Interprete assim:

  • 50%: mediana da latência
  • 97.5% e 99%: latência de cauda, onde problemas reais costumam aparecer
  • Avg: média
  • Stdev: dispersão; valores altos indicam respostas inconsistentes
  • Resumo final: total de requisições e bytes lidos

Para calcular requisições por segundo:

requisições / segundos
Enter fullscreen mode Exit fullscreen mode

No exemplo:

251000 / 10.05 ≈ 24975 req/s
Enter fullscreen mode Exit fullscreen mode

Para ver mais percentis e status codes, rode:

autocannon -c 100 -d 20 -l --renderStatusCodes http://localhost:3000
Enter fullscreen mode Exit fullscreen mode

Preste atenção em:

  • non2xx
  • timeouts
  • erros
  • respostas 4xx e 5xx

Um servidor pode ter throughput alto enquanto retorna falhas. Se respostas não-2xx aparecerem, seu throughput está medindo erro, não sucesso.

Uso programático em Node.js

O autocannon também expõe uma API Node.js. Isso permite executar benchmarks em scripts, pipelines de CI e verificações automatizadas.

Exemplo básico:

const autocannon = require('autocannon')

async function run() {
  const result = await autocannon({
    url: 'http://localhost:3000',
    connections: 100,
    duration: 20,
    pipelining: 1
  })

  console.log(`Avg latency: ${result.latency.average} ms`)
  console.log(`Req/sec: ${result.requests.average}`)
  console.log(`Non-2xx: ${result.non2xx}`)
}

run()
Enter fullscreen mode Exit fullscreen mode

O objeto result contém métricas como:

  • result.latency.average
  • result.latency.p99
  • result.requests.average
  • result.throughput.average
  • result.errors
  • result.timeouts
  • result.non2xx

Criar um budget de performance na CI

Você pode transformar o benchmark em um gate de qualidade. Por exemplo: falhar a build se o p99 passar de 250 ms ou se houver resposta não-2xx.

const autocannon = require('autocannon')

const P99_BUDGET_MS = 250

async function run() {
  const result = await autocannon({
    url: 'http://localhost:3000/api/health',
    connections: 100,
    duration: 30
  })

  const p99 = result.latency.p99

  console.log(`p99 latency: ${p99} ms (budget ${P99_BUDGET_MS} ms)`)
  console.log(`Non-2xx: ${result.non2xx}`)

  if (p99 > P99_BUDGET_MS || result.non2xx > 0) {
    console.error('Performance budget exceeded')
    process.exit(1)
  }
}

run()
Enter fullscreen mode Exit fullscreen mode

Esse padrão funciona bem em pipelines CI/CD compatíveis com Node.js.

Exibir progresso em tempo real

Para obter barra de progresso e tabela de resultados como no CLI, use autocannon.track:

const autocannon = require('autocannon')

const instance = autocannon({
  url: 'http://localhost:3000',
  connections: 10,
  duration: 10
}, console.log)

autocannon.track(instance, { renderProgressBar: true })

process.once('SIGINT', () => instance.stop())
Enter fullscreen mode Exit fullscreen mode

Testar múltiplas requisições em sequência

Para simular um fluxo com mais de uma chamada, use requests:

const autocannon = require('autocannon')

autocannon({
  url: 'http://localhost:3000',
  connections: 20,
  duration: 15,
  requests: [
    {
      method: 'GET',
      path: '/api/users'
    },
    {
      method: 'POST',
      path: '/api/data',
      body: '{"x":1}',
      headers: {
        'Content-Type': 'application/json'
      }
    }
  ]
}, console.log)
Enter fullscreen mode Exit fullscreen mode

Esse recurso é útil quando cada conexão precisa executar uma sequência simples de chamadas.

autocannon vs wrk vs ab

As três ferramentas respondem à mesma pergunta: quão rápido o servidor responde sob carga.

  • Apache Bench (ab): clássico, simples e disponível em muitos ambientes, mas single-threaded e mais antigo.
  • wrk: rápido, gera cargas altas e permite scripts Lua para requisições personalizadas.
  • autocannon: boa opção para projetos Node.js, com instalação via npm, API JavaScript, suporte a pipelining, arquivos HAR e cenários por requisição.

Se Node.js já faz parte do seu stack, autocannon tende a ser a opção de menor atrito.

Também vale comparar com outras abordagens:

Onde testes funcionais e Apidog entram

autocannon pode dizer que seu endpoint atende 12.000 requisições por segundo com p99 de 40 ms. Mas ele não diz se o endpoint retorna os dados corretos.

Um teste de carga pode passar mesmo se a API:

  • retornar JSON inválido
  • ignorar autenticação
  • violar o contrato OpenAPI
  • retornar campos incorretos
  • quebrar um fluxo de múltiplas etapas

Throughput não é correção.

É aí que testes funcionais e de contrato entram. O Apidog complementa ferramentas de carga: ele executa cenários salvos que validam status codes, schemas, valores de resposta e fluxos de várias etapas.

Use os dois tipos de teste:

  • autocannon: “a API é rápida o suficiente sob carga?”
  • Apidog CLI: “a API está correta?”

Exemplo de execução do Apidog CLI:

npm install -g apidog-cli

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

Onde:

  • -t seleciona cenário, pasta ou suíte por ID
  • -e seleciona o ambiente
  • -r define relatórios como cli, html, json ou junit

Para configurar em CI/CD, veja:

Uma pipeline saudável normalmente executa:

  1. testes funcionais e de contrato em cada push
  2. teste de carga antes de release ou em janelas programadas

O autocannon responde à segunda pergunta. O Apidog responde à primeira.

Perguntas frequentes

O autocannon é preciso para testes de carga em produção?

Sim, para endpoints HTTP/1.1, desde que o ambiente de teste seja adequado.

Para resultados melhores:

  • execute de uma máquina próxima ao servidor
  • use um ambiente de staging parecido com produção
  • aumente conexões gradualmente
  • monitore CPU, memória, banco de dados e rede do servidor
  • evite usar o servidor de desenvolvimento local como referência de produção

Com -R, o autocannon também permite trabalhar com uma taxa alvo de requisições por segundo.

O autocannon suporta HTTP/2 ou WebSockets?

Não. O autocannon faz benchmark de HTTP/1.1.

Para HTTP/2 ou WebSockets, escolha outra ferramenta.

Quantas conexões devo usar?

Comece com o padrão:

autocannon http://localhost:3000
Enter fullscreen mode Exit fullscreen mode

Depois aumente -c progressivamente:

autocannon -c 50 -d 20 http://localhost:3000
autocannon -c 100 -d 20 http://localhost:3000
autocannon -c 200 -d 20 http://localhost:3000
Enter fullscreen mode Exit fullscreen mode

Pare quando:

  • requisições por segundo pararem de subir
  • p99 começar a crescer muito
  • erros ou timeouts aparecerem

Esse ponto indica aproximadamente o limite prático do endpoint naquele ambiente.

Posso executar o autocannon na CI?

Sim. Use a API programática, leia métricas como result.latency.p99 e result.non2xx, e finalize com process.exit(1) quando um limite for excedido.

Exemplo de critério:

if (result.latency.p99 > 250 || result.non2xx > 0) {
  process.exit(1)
}
Enter fullscreen mode Exit fullscreen mode

Isso transforma o benchmark em um gate automatizado.

Qual a diferença entre -a e -d?

-d executa por tempo:

autocannon -d 30 http://localhost:3000
Enter fullscreen mode Exit fullscreen mode

-a executa até completar uma quantidade de requisições:

autocannon -a 10000 http://localhost:3000
Enter fullscreen mode Exit fullscreen mode

Use -d para medir comportamento sob carga contínua. Use -a quando precisar enviar um volume exato de requisições.

Top comments (0)