Herramientas de benchmark HTTP: wrk, hey, oha, ab y más

Las herramientas de benchmark HTTP de línea de comandos que usan la mayoría de los equipos son wrk, wrk2, hey, oha, ab (Apache Bench), bombardier, autocannon y h2load. Usa wrk2 cuando necesites un ritmo de peticiones constante y latencias de cola fiables, hey u oha para una comprobación rápida que también hable HTTP/2, h2load cuando lo que pruebas es el propio HTTP/2 o HTTP/3, y autocannon si tu equipo trabaja con Node.js.

No hemos enfrentado estas herramientas entre sí, así que aquí no hay cifras de velocidad ni veredictos sobre cuál es la más «rápida». Los datos salen del repositorio, el manual o la página de versiones de cada proyecto (comprobados el 9 de octubre de 2026); los consejos sobre cuándo elegir cada una son nuestra opinión.

¿Por qué importa que una herramienta fije el ritmo?

Una herramienta que mantiene un número fijo de conexiones envía menos en cuanto el servidor se ralentiza, y sus cifras de latencia dejan fuera el tiempo que las peticiones pasaron esperando. Una herramienta de ritmo fijo sigue enviando según lo previsto, y la ralentización aparece en los percentiles.

Casi todas las herramientas de esta lista trabajan con un número dado de conexiones o workers (-c), y cada uno espera una respuesta antes de enviar más. El README de wrk2 llama a este punto ciego Coordinated Omission y cronometra cada petición desde el momento en que debería haberse enviado. Vegeta también mantiene un ritmo constante; lo verás en nuestro repaso de herramientas de pruebas de carga open source. oha y autocannon pueden corregir su latencia por ese mismo efecto cuando fijas un ritmo, mientras que hey y bombardier documentan sus opciones de ritmo solo como límites.

¿Sigue valiendo la pena wrk?

Sí, para ver rápido cuánta carga puede lanzar una sola máquina contra un endpoint, siempre con la salvedad anterior. Su tag más reciente es de febrero de 2021.

wrk está escrito en C y mantiene un número fijo de conexiones abiertas repartidas entre varios hilos. Los scripts LuaJIT opcionales pueden construir peticiones, procesar respuestas y generar informes propios, y make lo compila junto con las versiones de LuaJIT y OpenSSL que incluye. Muestra la latencia media, la desviación estándar y el máximo; --latency añade los percentiles 50, 75, 90 y 99.

Elige wrk2 en su lugar si necesitas un ritmo de peticiones fijo o latencias de cola en las que puedas confiar durante una ralentización.

¿Cuándo necesitas wrk2 en lugar de wrk?

Cuando la pregunta es cómo se comporta la latencia a un ritmo de peticiones concreto. wrk2 mantiene ese ritmo constante y registra cada latencia en un HdrHistogram.

wrk2 añade a wrk un argumento de rendimiento (-R, peticiones por segundo). --latency muestra el espectro completo de percentiles y --u_latency añade las cifras sin corregir para comparar. Su README avisa de que las ejecuciones de menos de 10 a 20 segundos pueden no dar información útil por un periodo de calibración de 10 segundos, y describe el proyecto como experimental. No tiene versiones publicadas, y su Makefile genera un binario que también se llama wrk, así que conviene mantener los dos separados.

Elige oha o autocannon en su lugar si quieres un ajuste de ritmo con corrección de latencia en un proyecto que todavía se mantenga.

¿Son intercambiables hey y oha?

Para comprobaciones rápidas, en buena medida: las dos ejecutan un grupo de workers durante un número de peticiones o un tiempo, y las dos hablan HTTP/2. Se diferencian en cómo limitan el ritmo y en lo que ves mientras se ejecutan.

hey es un pequeño programa en Go con binarios listos para Linux, macOS y Windows y una fórmula de Homebrew. -q limita las peticiones por segundo de cada worker, -h2 activa HTTP/2, y el resumen incluye un histograma de tiempos de respuesta y una distribución de latencias, o CSV con -o csv.

oha está escrito en Rust, se inspira en hey y muestra una interfaz en directo en la terminal. Su -q fija un ritmo global, --latency-correction corrige la Coordinated Omission y --http-version acepta 1.1, 2 y, en una compilación experimental, 3. Se instala con cargo, Homebrew, winget o pacman, y puede escribir JSON o CSV.

Elige hey en su lugar si un límite por worker encaja con tu forma de pensar la carga; elige oha para HTTP/3, JSON o corrección de latencia.

¿Conviene seguir usando ab?

Para una comprobación rápida en una máquina donde ya está instalado, sí. ab viene con Apache HTTP Server, y su propio manual enumera limitaciones conocidas.

ab recibe un número de peticiones (-n) y un nivel de concurrencia (-c), no tiene opción de ritmo ni de HTTP/2, y solo usa KeepAlive con -k. Su salida termina con el porcentaje de peticiones servidas dentro de un tiempo dado, y puede escribir esos porcentajes en CSV (-e) o cada medición en un archivo para gnuplot (-g). La sección de errores del manual dice que ab no implementa HTTP/1.x por completo y advierte de que su análisis intensivo de cadenas puede hacer que acabes midiendo el rendimiento del propio ab.

Elige hey u oha en su lugar si necesitas HTTP/2, un límite de ritmo o keep-alive por defecto.

¿Para qué sirven bombardier y autocannon?

bombardier es una herramienta en Go con HTTP/2 opcional y límite de ritmo. autocannon encaja con equipos de Node.js, porque también funciona como biblioteca dentro de un script de Node.

bombardier usa por defecto el cliente fasthttp y cambia al cliente net/http de Go con --http1 o --http2. -r fija un límite de ritmo, -l muestra los percentiles 50, 75, 90 y 99, y -o json deja el resultado listo para procesarlo con otras herramientas.

autocannon se describe como una herramienta HTTP/1.1 con pipelining y HTTPS, y se instala con npm i autocannon -g. -R limita el ritmo global y -r el de cada conexión, y en cuanto fijas uno de los dos, la latencia se corrige por Coordinated Omission. Su tabla muestra los percentiles 2,5, 50, 97,5 y 99, -l los muestra todos y -j escribe JSON.

Elige autocannon en lugar de bombardier si tus benchmarks viven en una suite de pruebas de Node.js, y bombardier si necesitas HTTP/2.

¿Qué herramienta está pensada para HTTP/2 y HTTP/3?

h2load. Viene del proyecto nghttp2, prefiere HTTP/2 y puede forzar HTTP/1.1 o, si se compiló con soporte, HTTP/3.

h2load se compila junto con nghttp2 pasando --enable-app a ./configure. Además del número de clientes (-c), fija los flujos simultáneos por cliente (-m) para poner a prueba la multiplexación bajo carga, y --rps fija las peticiones por segundo de cada cliente. El manual da el mínimo, el máximo, la media, la mediana, el p95 y el p99 del tiempo de petición, del tiempo de conexión y del tiempo hasta el primer byte. El soporte de HTTP/3 figura como experimental.

Elige oha en su lugar si quieres HTTP/2 con menos opciones y una vista en directo.

¿Cuándo pasar de un benchmark a una prueba de carga de verdad?

Cuando la pregunta tiene que ver con recorridos de usuario, con más carga de la que puede generar una máquina o con tráfico que llegue desde donde están tus usuarios.

Todas estas herramientas envían peticiones sencillas desde una sola máquina, y la guía de h2load recuerda que el propio cliente puede convertirse en el cuello de botella. Pasa a una herramienta de pruebas de carga si necesitas inicios de sesión, recorridos de varios pasos o tiempo de reflexión, si el tráfico tiene que llegar desde varias regiones o si una prueba debe aprobar o fallar en la CI. Nuestra guía Cómo hacer una prueba de carga lo explica paso a paso, y k6 vs Artillery compara dos herramientas con scripts.

LoadFocus, el editor de este sitio, ejecuta pruebas de carga para webs y API desde 25 regiones en la nube, con JMeter, k6 o pruebas sin código. Si tu benchmark es una petición que ya envías con curl, su conversor de cURL a k6 gratuito la convierte en un script de k6 en tu propio navegador.

FAQ

¿Qué diferencia hay entre wrk y wrk2? wrk2 es un fork de wrk que envía peticiones a un ritmo constante fijado con -R y cronometra cada petición desde el momento en que debería haberse enviado. wrk mantiene ocupado un número fijo de conexiones y no tiene ajuste de ritmo.

¿Qué herramientas de benchmark HTTP admiten HTTP/2? Según su documentación, hey, oha, bombardier, h2load y Vegeta. wrk y wrk2 no lo documentan, autocannon se describe como una herramienta HTTP/1.1 y ab no tiene opción de HTTP/2.

Lecturas relacionadas

• Herramientas de pruebas de carga open source: seis opciones
• Coordinated omission: qué es y cómo evitarla
• Herramientas de pruebas de carga WebSocket: seis opciones
• Latencia de cola: qué es y cómo medirla
• redis-benchmark: cómo usarlo y leer sus resultados

Las afirmaciones técnicas de este artículo no se han revisado de forma independiente.