Ferramentas de benchmark HTTP: wrk, hey, oha, ab e mais
8 min de leitura
As ferramentas de benchmark HTTP de linha de comando que a maioria dos times usa são wrk, wrk2, hey, oha, ab (Apache Bench), bombardier, autocannon e h2load. Use wrk2 quando precisar de uma taxa de requisições constante e de latências de cauda confiáveis, hey ou oha para uma checagem rápida que também fale HTTP/2, h2load quando o próprio HTTP/2 ou HTTP/3 estiver em teste, e autocannon se o seu time trabalha com Node.js.
Não colocamos essas ferramentas umas contra as outras, então aqui não há números de velocidade nem veredito sobre a mais “rápida”. Os dados vêm do repositório, do manual ou da página de versões de cada projeto (conferidos em 9 de outubro de 2026); as dicas de quando escolher cada uma são a nossa avaliação.
| Ferramenta | Escrita em | Licença | Controle de taxa | HTTP/2 | Última versão |
|---|---|---|---|---|---|
| wrk | C, scripts LuaJIT | Modified Apache 2.0 | Nenhum | Não documentado | Tag 4.2.0, fev. 2021 |
| wrk2 | C | Apache 2.0 | Taxa fixa (-R) | Não documentado | Nenhuma, último commit set. 2019 |
| hey | Go | Apache 2.0 | Limite por worker (-q) | Sim | v0.1.5, jan. 2026 |
| oha | Rust | MIT | Limite global (-q) | Sim, e HTTP/3 | v1.16.0, ago. 2026 |
| ab | C (Apache httpd) | Apache 2.0 | Nenhum | Não | httpd 2.4.69, out. 2026 |
| bombardier | Go | MIT | Limite (-r) | Sim | v2.0.2, mar. 2025 |
| autocannon | Node.js | MIT | Limite (-R) | Não | v8.0.0, out. 2024 |
| h2load | C++ (nghttp2) | MIT | Por cliente (--rps) | Sim, e HTTP/3 | nghttp2 v1.70.0, jul. 2026 |
| Vegeta | Go | MIT | Taxa fixa (-rate) | Sim | v12.13.0, out. 2025 |
Por que importa se a ferramenta fixa a taxa?
Uma ferramenta que mantém um número fixo de conexões envia menos assim que o servidor fica lento, e os números de latência dela deixam de fora o tempo que as requisições passaram esperando. Uma ferramenta de taxa fixa continua enviando no ritmo planejado, e a lentidão aparece nos percentis.
A maioria das ferramentas desta lista roda um número definido de conexões ou workers (-c), e cada um espera uma resposta antes de enviar mais. O README do wrk2 chama esse ponto cego de Coordinated Omission e cronometra cada requisição a partir do momento em que ela deveria ter sido enviada. O Vegeta também mantém uma taxa constante; veja o nosso panorama de ferramentas de teste de carga open source. oha e autocannon conseguem corrigir a latência desse mesmo efeito quando você define uma taxa, enquanto hey e bombardier documentam suas opções de taxa apenas como limites.
O wrk ainda vale a pena?
Sim, para ver rapidamente quanta carga uma única máquina consegue mandar para um endpoint, lendo os números com a ressalva acima. A tag mais recente é de fevereiro de 2021.
O wrk é escrito em C e mantém um número fixo de conexões abertas distribuídas em várias threads. Scripts LuaJIT opcionais podem montar requisições, processar respostas e gerar relatórios próprios, e o make compila a ferramenta junto com o LuaJIT e o OpenSSL que vêm no pacote. Ele mostra a latência média, o desvio padrão e o máximo; --latency acrescenta os percentis 50, 75, 90 e 99.
Escolha o wrk2 no lugar dele quando precisar de uma taxa de requisições fixa ou de latências de cauda confiáveis durante uma lentidão.
Quando você precisa do wrk2 em vez do wrk?
Quando a pergunta é como a latência se comporta a uma determinada taxa de requisições. O wrk2 mantém essa taxa constante e registra cada latência em um HdrHistogram.
O wrk2 acrescenta ao wrk um argumento de vazão (-R, em requisições por segundo). --latency mostra o espectro completo de percentis e --u_latency acrescenta os números sem correção para comparar. O README avisa que execuções com menos de 10 a 20 segundos podem não trazer informação útil por causa de um período de calibração de 10 segundos, e descreve o projeto como experimental. Não há versões publicadas, e o Makefile gera um binário que também se chama wrk, então mantenha os dois separados.
Escolha oha ou autocannon no lugar dele quando quiser um ajuste de taxa com correção de latência em um projeto que ainda é mantido.
hey e oha são intercambiáveis?
Para checagens rápidas, em boa parte: os dois rodam um grupo de workers por um número de requisições ou por um tempo, e os dois falam HTTP/2. A diferença está em como limitam a taxa e no que você vê durante a execução.
O hey é um pequeno programa em Go com binários prontos para Linux, macOS e Windows e uma fórmula do Homebrew. -q limita as requisições por segundo de cada worker, -h2 ativa o HTTP/2, e o resumo traz um histograma de tempo de resposta e uma distribuição de latência, ou CSV com -o csv.
O oha é escrito em Rust, foi inspirado no hey e mostra uma interface ao vivo no terminal. O -q dele define uma taxa global, --latency-correction corrige a Coordinated Omission e --http-version aceita 1.1, 2 e, em uma compilação experimental, 3. Ele é instalado com cargo, Homebrew, winget ou pacman e pode gravar JSON ou CSV.
Escolha o hey no lugar dele quando um limite por worker combinar com o seu jeito de pensar a carga; escolha o oha para HTTP/3, JSON ou correção de latência.
Ainda vale usar o ab?
Para uma checagem rápida em uma máquina onde ele já está instalado, sim. O ab vem com o Apache HTTP Server, e o próprio manual lista limitações conhecidas.
O ab recebe um número de requisições (-n) e um nível de concorrência (-c), não tem opção de taxa nem de HTTP/2 e só usa KeepAlive com -k. A saída termina com a porcentagem de requisições atendidas dentro de um tempo, e ele pode gravar essas porcentagens em CSV (-e) ou cada medição em um arquivo para o gnuplot (-g). A seção de bugs do manual diz que o ab não implementa o HTTP/1.x por completo e avisa que o parsing pesado de strings pode fazer você medir o desempenho do próprio ab.
Escolha hey ou oha no lugar dele quando precisar de HTTP/2, de um limite de taxa ou de keep-alive por padrão.
Para que servem o bombardier e o autocannon?
O bombardier é uma ferramenta em Go com HTTP/2 opcional e limite de taxa. O autocannon combina com times de Node.js, porque também roda como biblioteca dentro de um script Node.
O bombardier usa por padrão o cliente fasthttp e passa para o cliente net/http do Go com --http1 ou --http2. -r define um limite de taxa, -l mostra os percentis 50, 75, 90 e 99, e -o json deixa o resultado pronto para ser lido por outras ferramentas.
O autocannon se descreve como uma ferramenta HTTP/1.1 com pipelining e HTTPS e é instalado com npm i autocannon -g. -R limita a taxa global e -r a de cada conexão, e quando qualquer um dos dois está definido a latência é corrigida da Coordinated Omission. A tabela dele mostra os percentis 2,5, 50, 97,5 e 99, -l mostra todos e -j grava JSON.
Escolha o autocannon em vez do bombardier quando seus benchmarks morarem em uma suíte de testes Node.js, e o bombardier quando precisar de HTTP/2.
Qual ferramenta foi feita para HTTP/2 e HTTP/3?
O h2load. Ele vem do projeto nghttp2, prefere HTTP/2 e consegue forçar HTTP/1.1 ou, quando compilado com suporte, HTTP/3.
O h2load é compilado junto com o nghttp2 passando --enable-app para o ./configure. Além do número de clientes (-c), ele define os streams simultâneos por cliente (-m) para colocar a multiplexação sob carga, e --rps define as requisições por segundo de cada cliente. O manual traz mínimo, máximo, média, mediana, p95 e p99 para o tempo de requisição, o tempo de conexão e o tempo até o primeiro byte. O suporte a HTTP/3 aparece como experimental.
Escolha o oha no lugar dele quando quiser HTTP/2 com menos opções e uma visão ao vivo.
Quando passar de um benchmark para um teste de carga de verdade?
Quando a pergunta envolve jornadas de usuário, mais carga do que uma máquina consegue gerar ou tráfego vindo de onde os seus usuários estão.
Todas essas ferramentas disparam requisições simples a partir de uma única máquina, e o guia do h2load lembra que o próprio cliente pode virar o gargalo. Passe para uma ferramenta de teste de carga quando precisar de login, jornadas com várias etapas ou tempo de pensamento, quando o tráfego tiver de vir de várias regiões ou quando um teste precisar passar ou falhar na CI. O nosso guia Como fazer um teste de carga mostra isso passo a passo, e k6 vs Artillery compara duas ferramentas baseadas em scripts.
A LoadFocus, que publica este site, roda testes de carga para sites e APIs a partir de 25 regiões na nuvem, com JMeter, k6 ou testes sem código. Se o seu benchmark é uma requisição que você já manda com curl, o conversor de cURL para k6 gratuito dela transforma esse comando em um script k6 no próprio navegador.
FAQ
Qual é a diferença entre wrk e wrk2?
O wrk2 é um fork do wrk que envia requisições a uma taxa constante definida com -R e cronometra cada requisição a partir do momento em que ela deveria ter sido enviada. O wrk mantém ocupado um número fixo de conexões e não tem ajuste de taxa.
Quais ferramentas de benchmark HTTP suportam HTTP/2? Segundo a documentação delas, hey, oha, bombardier, h2load e Vegeta. wrk e wrk2 não documentam o suporte, o autocannon se descreve como ferramenta HTTP/1.1 e o ab não tem opção de HTTP/2.
Leituras relacionadas
- Ferramentas de teste de carga open source: seis opções
- Coordinated omission: o que é e como evitar
- Ferramentas de teste de carga WebSocket: seis opções
- Latência de cauda: o que é e como medir
- redis-benchmark: como usar e ler os resultados
As afirmações técnicas deste artigo não foram revisadas de forma independente.