DEV Community

Cover image for ApacheBench (ab): Cómo hacer una prueba de carga de una API desde la terminal
Roobia
Roobia

Posted on • Originally published at apidog.com

ApacheBench (ab): Cómo hacer una prueba de carga de una API desde la terminal

Has implementado un endpoint y en Postman devuelve el JSON esperado. El problema empieza cuando 200 clientes lo llaman al mismo tiempo: ¿aguanta 500 solicitudes por segundo o la latencia se dispara? ApacheBench responde esa pregunta con un comando.

Prueba Apidog hoy

ApacheBench, ejecutado como ab, es una herramienta de línea de comandos que envía un número fijo de solicitudes HTTP a una URL y reporta rendimiento, latencia y errores. Viene con Apache HTTP Server, es pequeña, rápida y útil para obtener una primera lectura de carga sobre un endpoint específico.

En esta guía verás cómo instalar ab, ejecutar pruebas GET y POST, interpretar la salida y detectar cuándo necesitas otra herramienta. Todos los comandos usan opciones documentadas en la referencia oficial de Apache ab.

Qué es ApacheBench y cuándo usarlo

ab es un cliente de benchmarking incluido con Apache HTTP Server. Abre conexiones contra una URL, envía solicitudes según la concurrencia configurada, mide los tiempos de respuesta y genera un resumen.

ApacheBench

Úsalo para responder preguntas como:

  • ¿Cuántas solicitudes por segundo soporta este endpoint?
  • ¿Cuál es la latencia media bajo concurrencia?
  • ¿Qué pasa con los percentiles 95 y 99?
  • ¿A partir de qué concurrencia aparecen errores?

No lo uses para validar lógica de negocio. ab no comprueba esquemas JSON, no valida campos, no ejecuta flujos de varios pasos y no simula usuarios reales navegando por una API. Solo golpea una URL y mide.

Si necesitas contexto sobre la disciplina completa, revisa qué es la prueba de carga de API y por qué importa el tiempo de respuesta de la API.

Instalar ab

ab viene en los paquetes de utilidades de Apache. El nombre depende del sistema operativo.

Debian y Ubuntu 

sudo apt-get update
sudo apt-get install -y apache2-utils
Enter fullscreen mode Exit fullscreen mode

CentOS, RHEL y Fedora 

# CentOS 7
sudo yum install -y httpd-tools

# Fedora y CentOS 8+
sudo dnf install -y httpd-tools
Enter fullscreen mode Exit fullscreen mode

macOS

En macOS suele venir incluido con Apache. Verifica la instalación:

ab -V
Enter fullscreen mode Exit fullscreen mode

Deberías ver algo como:

This is ApacheBench, Version 2.3
Enter fullscreen mode Exit fullscreen mode

Si el comando no existe, instálalo mediante Homebrew usando la fórmula de Apache. Cuando ab -V imprima una versión, ya puedes ejecutar pruebas.

Ejecutar una prueba GET básica

Las dos opciones principales son:

  • -n: número total de solicitudes.
  • -c: número de solicitudes concurrentes.

Ejemplo: 1000 solicitudes, con 50 en paralelo:

ab -n 1000 -c 50 https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Importante: usa una URL completa con ruta. Si quieres probar la raíz, incluye la barra final:

ab -n 1000 -c 50 https://api.example.com/
Enter fullscreen mode Exit fullscreen mode

Probar con KeepAlive

Por defecto, ab puede abrir conexiones nuevas con frecuencia. Para simular mejor clientes HTTP reales que reutilizan conexiones TCP, agrega -k:

ab -n 1000 -c 50 -k https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Compara ambos resultados:

ab -n 1000 -c 50 https://api.example.com/v1/users
ab -n 1000 -c 50 -k https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Si la latencia baja mucho con -k, parte del costo venía de abrir conexiones, no necesariamente del procesamiento del endpoint.

Ejecutar por tiempo en lugar de cantidad

Si quieres una prueba de duración fija, usa -t:

ab -t 30 -c 50 -k https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Esto ejecuta la prueba durante un máximo de 30 segundos con concurrencia 50. -t implica internamente -n 50000, así que la prueba termina cuando alcanza el límite de tiempo o el máximo de solicitudes.

Probar un endpoint POST

Para probar un POST, guarda el cuerpo de la solicitud en un archivo y pásalo con -p. También define el Content-Type con -T.

Crea el payload:

cat > payload.json <<'EOF'
{"name": "Ada Lovelace", "email": "ada@example.com"}
EOF
Enter fullscreen mode Exit fullscreen mode

Ejecuta la prueba:

ab -n 500 -c 25 -k \
  -p payload.json \
  -T application/json \
  https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Qué hace cada opción:

  • -p payload.json: usa ese archivo como cuerpo del POST.
  • -T application/json: envía el encabezado Content-Type: application/json.
  • -n 500: envía 500 solicitudes en total.
  • -c 25: mantiene hasta 25 solicitudes concurrentes.
  • -k: reutiliza conexiones HTTP.

Si tu API requiere autenticación, agrega encabezados con -H:

ab -n 500 -c 25 -k \
  -p payload.json \
  -T application/json \
  -H "Authorization: Bearer YOUR_TOKEN" \
  https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Puedes repetir -H para varios encabezados:

ab -n 500 -c 25 -k \
  -p payload.json \
  -T application/json \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "X-Request-Source: load-test" \
  https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Para repasar cómo construir cuerpos JSON manualmente, consulta cómo enviar datos JSON con curl. El mismo JSON puede usarse como archivo de payload para ab.

Leer la salida de ApacheBench

Una ejecución típica imprime algo así:

Concurrency Level:      50
Time taken for tests:   4.212 seconds
Complete requests:      1000
Failed requests:        0
Non-2xx responses:      0
Requests per second:    237.42 [#/sec] (mean)
Time per request:       210.598 [ms] (mean)
Time per request:       4.212 [ms] (mean, across all concurrent requests)
Transfer rate:          142.31 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        5   18   9.4     16      64
Processing:    22  189  41.2    182     310
Waiting:       21  177  39.8    171     295
Total:         31  207  42.7    201     338

Percentage of the requests served within a certain time (ms)
  50%    201
  66%    221
  75%    236
  90%    268
  95%    291
  99%    324
 100%    338 (longest request)
Enter fullscreen mode Exit fullscreen mode

Métricas que debes revisar primero

Requests per second 

Requests per second: 237.42 [#/sec] (mean)
Enter fullscreen mode Exit fullscreen mode

Es el throughput: cuántas solicitudes procesa el endpoint por segundo. Más alto suele ser mejor, pero no sirve de nada si hay muchos errores.

Failed requests 

Failed requests: 0
Enter fullscreen mode Exit fullscreen mode

Indica solicitudes fallidas según ab. Verifica este valor antes de confiar en el rendimiento.

Non-2xx responses 

Non-2xx responses: 0
Enter fullscreen mode Exit fullscreen mode

Muestra respuestas fuera del rango 2xx. Si este número sube, el servidor está respondiendo con errores, redirecciones u otros estados inesperados.

Time per request

Aparece dos veces:

Time per request: 210.598 [ms] (mean)
Time per request: 4.212 [ms] (mean, across all concurrent requests)
Enter fullscreen mode Exit fullscreen mode

La primera línea es la más relevante para la experiencia de usuario: el tiempo medio observado por una solicitud.

La segunda es el tiempo medio por solicitud considerando la concurrencia total. Úsala para entender throughput, no latencia percibida.

Analizar percentiles

La sección más útil suele ser esta:

Percentage of the requests served within a certain time (ms)
  50%    201
  66%    221
  75%    236
  90%    268
  95%    291
  99%    324
 100%    338 (longest request)
Enter fullscreen mode Exit fullscreen mode

Cómo leerla:

  • 50%: mediana. La mitad de las solicitudes terminó en 201 ms o menos.
  • 95%: el 95% terminó en 291 ms o menos.
  • 99%: el 99% terminó en 324 ms o menos.
  • 100%: la solicitud más lenta tardó 338 ms.

Para APIs en producción, no mires solo la media. Los percentiles 95 y 99 muestran la latencia de cola, que suele ser la que afecta a usuarios reales.

Exportar resultados

Si quieres graficar o guardar resultados, usa:

ab -n 1000 -c 50 -k \
  -e results.csv \
  https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

-e results.csv genera un CSV con percentiles.

Para gnuplot:

ab -n 1000 -c 50 -k \
  -g results.tsv \
  https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

-g results.tsv escribe datos compatibles con gnuplot.

Cuándo ab deja de ser suficiente

ab es útil, pero limitado. Ten claros estos límites antes de usar sus resultados para tomar decisiones.

Una sola URL por ejecución

ab prueba un endpoint por ejecución. No puede modelar flujos como:

  1. Iniciar sesión.
  2. Obtener un token.
  3. Crear un recurso.
  4. Consultar ese recurso.
  5. Actualizarlo.

Para escenarios de usuario reales, necesitas una herramienta basada en flujos.

Sin validación funcional

ab cuenta códigos de estado y tamaños de respuesta. No valida que el JSON sea correcto.

Una respuesta puede tener código 200 y aun así devolver datos incorrectos. Por eso una prueba de carga no reemplaza una suite funcional o de contrato.

Sin soporte HTTP/2

La documentación oficial indica que ab no implementa HTTP/1.x completamente y no soporta HTTP/2. Si tu servidor cambia su comportamiento bajo HTTP/2, ab no lo mostrará.

Carga desde una sola máquina

ab corre desde una máquina y un proceso. Si subes mucho la concurrencia, puedes terminar midiendo límites del cliente que ejecuta ab, no del servidor.

Si necesitas flujos de varios pasos, carga distribuida o escenarios más complejos, considera herramientas diseñadas para eso. JMeter soporta escenarios más completos y ejecuciones distribuidas. También puedes revisar este resumen de herramientas de prueba de carga.

Dónde encaja la prueba funcional

El rendimiento responde: “¿qué tan rápido responde?”.

La prueba funcional responde: “¿responde correctamente?”.

ab solo cubre la primera parte. Antes de cargar un endpoint, conviene validar que el endpoint devuelve el contrato esperado en condiciones normales.

Aquí es donde una plataforma API complementa a ab. Apidog permite crear escenarios con aserciones visuales, encadenar solicitudes en flujos de varios pasos y validar respuestas contra esquemas. Es el tipo de verificación que ab no intenta resolver.

Para CI, puedes ejecutar escenarios guardados con la CLI de Apidog.

Instálala con Node:

npm install -g apidog-cli
Enter fullscreen mode Exit fullscreen mode

Ejecuta un escenario o suite:

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

Opciones principales:

  • -t: selecciona un escenario, carpeta o suite guardado por ID.
  • -e: selecciona el entorno.
  • -r: define reporteros como cli, html, json o junit.
  • -d o --iteration-data: ejecuta pruebas con datos externos o un ID de datos de prueba.

La CLI no genera carga. Ejecuta pruebas funcionales guardadas. Por eso encaja bien antes de una prueba con ab:

  1. Ejecuta pruebas funcionales con Apidog.
  2. Si pasan, ejecuta ab para medir rendimiento.
  3. Revisa errores, throughput y percentiles.
  4. Ajusta la API y repite.

Para más contexto, consulta la guía de pruebas de rendimiento de Apidog y el tutorial general de pruebas de rendimiento de API.

Preguntas frecuentes

¿ApacheBench es solo para servidores Apache?

No. Aunque viene con Apache HTTP Server, ab puede enviar solicitudes HTTP y HTTPS a cualquier servidor: Nginx, Node.js, Go, Python o cualquier backend que hable HTTP.

¿Qué concurrencia y número de solicitudes debo usar?

Empieza bajo y sube gradualmente:

ab -n 1000 -c 10 -k https://api.example.com/v1/users
ab -n 1000 -c 25 -k https://api.example.com/v1/users
ab -n 1000 -c 50 -k https://api.example.com/v1/users
ab -n 1000 -c 100 -k https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Observa dónde las solicitudes por segundo dejan de subir y empiezan los errores. Ese punto suele indicar saturación del endpoint o de algún componente intermedio.

¿Por qué tengo muchas solicitudes fallidas si la API funciona?

ab puede marcar como fallidas las respuestas cuya longitud varía entre solicitudes. Eso es común en JSON dinámico.

Para ignorar diferencias de longitud, agrega -l:

ab -n 1000 -c 50 -k -l https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Luego revisa Non-2xx responses para detectar errores reales.

¿Puede ab probar un endpoint con token?

Sí, si ya tienes el token:

ab -n 500 -c 25 -k \
  -H "Authorization: Bearer YOUR_TOKEN" \
  https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Lo que ab no puede hacer es iniciar sesión primero, extraer un token y reutilizarlo en otra solicitud. Para eso necesitas una herramienta de escenarios como Apidog.

¿ab soporta HTTP/2?

No. ab trabaja con HTTP/1.x y la propia documentación oficial indica que no implementa HTTP/1.x completamente. Si necesitas medir comportamiento bajo HTTP/2, usa una herramienta de carga con soporte HTTP/2.

Top comments (0)