Has implementado un endpoint. Devuelve el JSON correcto en Postman. Pero no tienes idea de qué sucede cuando 200 clientes lo acceden simultáneamente. ¿Soporta 500 solicitudes por segundo, o la latencia se desmorona a 50? ApacheBench responde a esa pregunta con un solo comando.
ApacheBench, invocado como ab, es una herramienta de línea de comandos que lanza un número fijo de solicitudes HTTP a una única URL e informa el rendimiento y la latencia. Se incluye con Apache HTTP Server y ha existido durante décadas. Es pequeña, se ejecuta rápidamente y te da una lectura veloz de cuánta carga puede soportar un endpoint.
Esta guía cubre la instalación de ab, la ejecución de una prueba básica, la prueba de endpoints POST, la lectura de la salida y el conocimiento de dónde ab deja de ser la herramienta adecuada. Cada comando aquí se corresponde con un indicador documentado en la referencia oficial de Apache ab.
Qué es ApacheBench y de dónde viene
ab es un cliente de benchmarking incluido con Apache HTTP Server. El nombre es la abreviatura de ApacheBench. Abre conexiones a una URL, envía solicitudes tan rápido como lo permite la configuración de concurrencia, mide el tiempo de cada respuesta e imprime un resumen.
Mide bien una cosa: cuántas solicitudes por segundo puede atender un único endpoint y cómo se distribuye el tiempo de respuesta bajo carga. Eso es rendimiento y latencia para una URL.
Lo que no hace es igual de importante. ab no comprueba si el cuerpo de la respuesta es correcto. No valida un esquema ni afirma sobre un campo. No sigue un flujo de varios pasos como iniciar sesión, luego obtener, luego actualizar. Accede a una URL y cuenta. Ten en cuenta ese alcance y ab seguirá siendo útil. Espera más y te decepcionarás.
Si deseas una visión más amplia de la disciplina en la que encaja ab, consulta qué es la prueba de carga de API y por qué importa el tiempo de respuesta de la API.
Instalación de ab
ab viene empaquetado con las utilidades de Apache. El nombre del paquete varía según la plataforma.
En Debian y Ubuntu, instala el paquete apache2-utils:
sudo apt-get update
sudo apt-get install -y apache2-utils
En CentOS, RHEL y Fedora, el paquete es httpd-tools:
# CentOS 7
sudo yum install -y httpd-tools
# Fedora and CentOS 8+
sudo dnf install -y httpd-tools
En macOS, ab ya está presente porque el sistema incluye Apache. Compruébalo:
ab -V
Deberías ver una línea de versión como Version 2.3. Si el comando no se encuentra en macOS, instálalo a través de la fórmula de Apache de Homebrew. Una vez que ab -V imprima una versión, estarás listo.
Ejecución de una prueba de carga básica
Los dos indicadores que usarás siempre son -n y -c.
-n solicitudesestablece el número total de solicitudes a realizar. El valor predeterminado es una sola solicitud, lo cual no te dice nada, así que siempre configura esto.-c concurrenciaestablece cuántas solicitudes se ejecutan a la vez. El valor predeterminado es uno, lo que significa completamente en serie.
Aquí hay 1000 solicitudes, 50 a la vez, contra un endpoint JSON:
ab -n 1000 -c 50 https://api.example.com/v1/users
Observa la barra diagonal final. ab necesita una URL completa con una ruta. Si lo diriges a un host sin ruta, dará un error. Para la raíz, usa una barra diagonal final: https://api.example.com/.
Los clientes reales reutilizan las conexiones TCP en lugar de abrir una nueva por cada solicitud. Agrega -k para habilitar HTTP KeepAlive y que ab reutilice las conexiones dentro de una sesión:
ab -n 1000 -c 50 -k https://api.example.com/v1/users
La ejecución con -k suele ser más parecida a cómo se comporta un navegador o un cliente de API bien diseñado, ya que evita pagar el costo de configuración de la conexión en cada solicitud. Compara los dos números para ver cuánta de tu latencia es sobrecarga de conexión.
También puedes limitar la ejecución por tiempo en lugar de por cantidad. -t establece un número máximo de segundos e implica -n 50000 internamente, por lo que la prueba se detiene en el límite que alcances primero:
ab -t 30 -c 50 -k https://api.example.com/v1/users
Esto se ejecuta durante un máximo de 30 segundos con una concurrencia de 50. Útil cuando deseas una lectura de duración fija en lugar de un conteo fijo.
Prueba de un endpoint POST
La mayoría del trabajo de las API no es GET. Para probar un POST, coloca el cuerpo de la solicitud en un archivo y pásalo con -p. También debes establecer el tipo de contenido con -T, o el servidor rechazará el cuerpo.
Crea la carga útil:
cat > payload.json <<'EOF'
{"name": "Ada Lovelace", "email": "ada@example.com"}
EOF
Luego envíala:
ab -n 500 -c 25 -k \
-p payload.json \
-T application/json \
https://api.example.com/v1/users
El indicador -p nombra el archivo que contiene el cuerpo POST. El indicador -T establece el encabezado Content-Type. El tipo de contenido predeterminado es text/plain, que casi nunca es lo que una API JSON desea, así que establece -T application/json explícitamente.
Si tu endpoint necesita autenticación u otros encabezados, agrégalos con -H. Repite el indicador para cada encabezado:
ab -n 500 -c 25 -k \
-p payload.json \
-T application/json \
-H "Authorization: Bearer YOUR_TOKEN" \
https://api.example.com/v1/users
Para un recordatorio sobre cómo construir cuerpos de solicitud JSON manualmente, consulta cómo enviar datos JSON con curl. El mismo cuerpo funciona como un archivo de carga útil de ab.
Lectura de la salida
Una ejecución imprime un bloque de números. Aquí tienes un ejemplo recortado:
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)
Lee estos campos primero:
- Solicitudes por segundo es tu titular de rendimiento. Es el recuento de solicitudes dividido por el tiempo total. Más alto es mejor.
- Solicitudes fallidas y Respuestas no 2xx te dicen si el servidor realmente manejó la carga o comenzó a generar errores. Un número alto de solicitudes por segundo no significa nada si la mitad de las respuestas son 500. Siempre verifica estos dos antes de confiar en la cifra de rendimiento.
- Tiempo por solicitud aparece dos veces. La primera línea es el tiempo medio que espera un solo usuario (concurrencia multiplicada por el tiempo total dividido por las solicitudes). La segunda línea, etiquetada como "en todas las solicitudes concurrentes", es la brecha promedio entre las solicitudes completadas. El primer número es el que sienten los usuarios.
La tabla de Porcentaje de las solicitudes atendidas dentro de un cierto tiempo es la parte más útil. Es un desglose por percentiles. La fila del 50% es tu mediana. Las filas del 95% y 99% muestran la cola lenta. En el ejemplo, la mitad de las solicitudes terminaron en 201ms, pero el 1% tardó 324ms o más. La latencia de cola es donde los usuarios reales se ven afectados, así que presta más atención a los percentiles 95 y 99 que a la media.
¿Quieres los números brutos por solicitud para un gráfico? Agrega -e results.csv para escribir un CSV de pares de percentil-a-tiempo, o -g results.tsv para un archivo compatible con gnuplot.
Donde ab deja de ser la herramienta adecuada
ab es deliberadamente limitado. Vale la pena establecer sus límites claramente para que no lo uses incorrectamente.
- Una URL por ejecución.
abbombardea un único endpoint. No puede programar una secuencia como autenticar, crear un recurso y luego leerlo. Los viajes de usuario reales tocan muchos endpoints en orden, yabno tiene concepto de eso. - Sin comprobaciones de corrección.
abcuenta códigos de estado y longitudes de bytes. No analiza tu JSON ni afirma que un campo es igual a un valor esperado. Una respuesta puede ser estructuralmente incorrecta y aun así contar como un éxito. Los números de carga no son un sustituto de una suite de pruebas que pase. - Manejo HTTP anticuado. La documentación oficial establece que
abno implementa HTTP/1.x completamente y solo acepta algunas formas esperadas de respuestas. No tiene soporte para HTTP/2. Para servidores que se comportan de manera diferente bajo HTTP/2,abno lo reflejará. - Carga de una sola máquina.
abse ejecuta desde una sola máquina y un solo proceso. Más allá de cierta concurrencia, mides los límites de tu propio cliente en lugar de los del servidor. La documentación incluso advierte que el propio análisis deabpuede aparecer como un cuello de botella en los perfiles.
Nada de esto hace que ab sea malo. Lo convierte en una herramienta específica: una sonda de rendimiento rápida para un único endpoint. Cuando necesites flujos programados, carga distribuida o HTTP/2, busca algo diseñado para eso. JMeter maneja escenarios de varios pasos y ejecuciones distribuidas, y hay un resumen más amplio de herramientas de prueba de carga si estás comparando opciones.
Dónde encaja la prueba funcional
El rendimiento es un eje. La corrección es otro, y ab no lo aborda. Antes de realizar una prueba de carga en un endpoint, quieres saber que devuelve los datos correctos con la forma adecuada bajo condiciones normales. Eso es prueba funcional y de contrato, y es un trabajo diferente.
Aquí es donde una plataforma API completa se gana su lugar junto a ab. Apidog te permite construir escenarios de prueba con aserciones visuales, encadenar solicitudes en flujos de varios pasos y validar respuestas contra tu esquema, las cosas que ab no puede hacer por diseño. Guardas esos escenarios una vez y los ejecutas en cualquier lugar.
Para la integración continua, la CLI de Apidog ejecuta tus escenarios guardados sin interfaz gráfica. Instálala con Node:
npm install -g apidog-cli
Luego ejecuta un escenario o suite guardado contra un entorno elegido, emitiendo informes que tu CI puede archivar:
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-t <scenarioOrSuiteId> \
-e <environmentId> \
-r cli,html,junit
El indicador -t selecciona un escenario, carpeta o suite guardado por ID. El indicador -e selecciona el entorno. El indicador -r elige uno o más reporteros de cli, html, json y junit. Para ejecuciones impulsadas por datos, agrega -d (o --iteration-data) con una ruta de archivo de datos o un ID de datos de prueba. La CLI no tiene interfaz gráfica y ejecuta escenarios guardados, por lo que se adapta a cualquier paso de CI que pueda ejecutar Node. No es un remitente de solicitudes ni un generador de carga, ejecuta las pruebas funcionales que ab nunca estuvo destinado a ejecutar.
Una configuración saludable utiliza ambos. Ejecuta escenarios de Apidog para probar que el endpoint es correcto. Ejecuta ab para probar que es lo suficientemente rápido. Para el lado de la corrección, 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. A pesar del nombre, ab envía solicitudes HTTP y HTTPS simples a cualquier servidor. Funciona con Nginx, Node, Go, Python o cualquier host que hable HTTP. La relación con Apache es solo que la herramienta se distribuye con Apache HTTP Server.
¿Qué concurrencia y recuento de solicitudes debo usar?
Comienza bajo y aumenta. Prueba -n 1000 -c 10, luego sube -c a 25, 50, 100 y observa dónde las solicitudes por segundo dejan de aumentar y comienzan a aparecer solicitudes fallidas. Ese punto de inflexión es aproximadamente donde el endpoint se satura. Ajusta tu concurrencia máxima al tráfico real esperado en lugar de elegir un número redondo grande.
¿Por qué mis solicitudes fallidas son altas cuando la API funciona bien?
ab marca una solicitud como fallida si la longitud de la respuesta varía entre solicitudes, lo cual es normal para JSON dinámico. Agrega el indicador -l para dejar de contar las diferencias de longitud como fallas. Luego, verifica la línea de respuestas no 2xx para ver si hay errores reales subyacentes.
¿Puede ab probar un endpoint que necesita un token de inicio de sesión?
Sí, si ya tienes un token. Pásalo con -H "Authorization: Bearer YOUR_TOKEN". Lo que ab no puede hacer es iniciar sesión primero para obtener un token nuevo y luego usarlo. Eso es un flujo de varios pasos, y para ello necesitas una herramienta basada en escenarios como Apidog.
¿ab soporta HTTP/2?
No. ab habla HTTP/1.x y, según la documentación oficial, ni siquiera lo implementa completamente. Si el comportamiento de tu servidor bajo HTTP/2 es importante, usa una herramienta de carga con soporte HTTP/2 en su lugar.