autocannon: Pruebas de Carga HTTP con Node.js (Paso a Paso)

Usted escribió un endpoint HTTP. Funciona cuando lo llama una vez desde Postman. Pero, ¿qué sucede cuando 200 clientes lo llaman al mismo tiempo? Necesita números: solicitudes por segundo, percentiles de latencia y cuántas respuestas regresaron con un estado que no sea 2xx. autocannon le brinda esos números desde su terminal en unos diez segundos.

autocannon es una herramienta de benchmarking HTTP/1.1 escrita en Node.js. Dispara una avalancha controlada de solicitudes a una URL e informa el rendimiento y la latencia. Esta guía le guiará a través de la instalación, una ejecución básica, cada flag que realmente usará, la lectura de la salida y el uso de autocannon desde un script de Node. También traza una línea clara entre lo que una prueba de carga le dice y lo que no, para que sepa cuándo recurrir a una prueba funcional y de contrato en su lugar.

botón

Qué es autocannon

autocannon abre un número fijo de conexiones concurrentes a una URL y sigue enviando solicitudes durante una duración establecida (o un número establecido de solicitudes). Mientras se ejecuta, muestrea la latencia y cuenta las respuestas. Cuando termina, imprime una tabla de percentiles de latencia y un resumen del total de solicitudes y bytes leídos.

Mide una cosa: cuánta carga soporta su servidor y qué tan rápido responde bajo esa carga. No verifica si el cuerpo de la respuesta es correcto, si su API coincide con su especificación OpenAPI, o si un flujo de trabajo de varios pasos devuelve los datos correctos en cada paso. Tenga en cuenta esa distinción. Esto define dónde encaja autocannon en su pila de pruebas, lo cual se aborda al final.

Si ha usado wrk o Apache Bench, autocannon ocupa el mismo lugar con una instalación nativa de Node y una API programática que puede llamar desde JavaScript.

Instalación

autocannon se distribuye como un paquete npm. Instálelo globalmente para tener el comando autocannon en cualquier lugar:

npm i autocannon -g

Necesita tener Node.js instalado primero. Si prefiere no instalarlo globalmente, ejecútelo bajo demanda con npx:

npx autocannon http://localhost:3000

O agréguelo a un proyecto como una dependencia de desarrollo cuando planee crear scripts con él:

npm i autocannon --save-dev

Verifique la instalación:

autocannon --version

Ejecución básica

La forma más sencilla es el comando más una URL. Esto ejecuta el benchmark predeterminado: 10 conexiones durante 10 segundos.

autocannon http://localhost:3000

Ajuste los parámetros con tres flags que usará constantemente. -c establece el número de conexiones concurrentes, -d establece la duración en segundos y -p establece el pipelining (cuántas solicitudes envía cada conexión antes de esperar una respuesta).

autocannon -c 100 -d 30 -p 10 http://localhost:3000

Ese comando abre 100 conexiones, se ejecuta durante 30 segundos y realiza un pipelining de 10 solicitudes por conexión. Un mayor número de conexiones y pipelining generan más carga, que es como se encuentra el punto donde la latencia comienza a aumentar.

Para enviar un número fijo de solicitudes en lugar de ejecutar durante una duración, use -a (cantidad):

autocannon -c 10 -a 10000 http://localhost:3000

Eso se detiene después de 10,000 solicitudes, independientemente del tiempo.

Solicitudes POST, encabezados y un cuerpo

Cambie el método con -m, agregue encabezados con -H y pase un cuerpo de solicitud con -b. Aquí hay una solicitud POST a un endpoint JSON:

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

Observe el formato del encabezado: -H 'Key=Value', y repita -H para cada encabezado. Si su cuerpo es grande o reside en un archivo, use -i para leerlo desde el disco en lugar de incluirlo directamente:

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

Limitación de la tasa de la prueba

Por defecto, autocannon envía tan rápido como puede. A veces, se desea una tasa constante y realista en lugar de una avalancha de máxima presión. -R limita el total de solicitudes por segundo en todas las conexiones:

autocannon -c 50 -R 500 -d 60 http://localhost:3000

Eso mantiene la prueba en 500 solicitudes por segundo durante 60 segundos. Esto es útil cuando se desea medir la latencia con una carga de producción esperada en lugar de en el punto de ruptura.

Calentamiento e hilos de trabajo

Dos flags más ayudan en ejecuciones más pesadas. -W (calentamiento) envía tráfico durante un breve intervalo antes de que autocannon comience a muestrear, para que sus primeros números no se distorsionen por cachés frías o un JIT que no se ha calentado. -w (trabajadores) distribuye la carga entre varios hilos de trabajo de Node, lo cual es importante cuando un solo hilo no puede generar suficientes solicitudes para saturar un servidor rápido:

autocannon -c 200 -d 30 -w 4 http://localhost:3000

Recurra a -w solo cuando haya confirmado que el propio generador de carga es el cuello de botella. Si la latencia parece sospechosamente plana a medida que aumenta -c, su generador podría estar al máximo, y agregar trabajadores le dará una imagen más real del límite del servidor.

Interpretando los resultados

Cuando una ejecución finaliza, autocannon imprime una tabla de latencia y una línea de resumen. Un ejemplo recortado:

Ejecutando prueba de 10s @ http://localhost:3000
10 conexiones

┌─────────┬──────┬──────┬───────┬──────┬─────────┬─────────┬──────────┐
│ Estadística │ 2.5% │ 50%  │ 97.5% │ 99%  │ Prom    │ DesvEst │ Máx      │
├─────────┼──────┼──────┼───────┼──────┼─────────┼─────────┼──────────┤
│ Latencia │ 0 ms │ 1 ms │ 4 ms  │ 6 ms │ 1.2 ms  │ 0.9 ms  │ 24.1 ms  │
└─────────┴──────┴──────┴───────┴──────┴─────────┴─────────┴──────────┘

251k solicitudes en 10.05s, 27.9 MB leídos

Así es como se interpreta:

Las columnas de percentiles (2.5%, 50%, 97.5%, 99%) importan más que el promedio. La columna del 50% es la mediana. La columna del 99% le indica la latencia que experimenta el 1 por ciento más lento de sus usuarios. La latencia de cola es donde se esconden los problemas reales, así que observe los números del 97.5% y 99%.
Prom y DesvEst le dan la media y qué tan dispersas están las latencias. Una desviación estándar alta significa tiempos de respuesta inconsistentes.
La línea de resumen (“251k solicitudes en 10.05s”) es su rendimiento. Divida las solicitudes por segundos para obtener las solicitudes por segundo.

Dos flags hacen que la salida sea más útil. Agregue -l para imprimir el conjunto completo de percentiles de latencia (incluyendo p99.9 y más allá), y agregue --renderStatusCodes para ver un desglose por código de estado y así poder detectar una ola de errores 500 que se esconden detrás de un buen número de rendimiento:

autocannon -c 100 -d 20 -l --renderStatusCodes http://localhost:3000

Observe los errores, tiempos de espera y el recuento de no-2xx. Un servidor puede registrar una alta tasa de solicitudes mientras devuelve errores silenciosamente. Si el número de no-2xx no es cero, su número de rendimiento está midiendo fallas, no éxitos.

Uso programático en un script

autocannon expone una API de Node.js, para que pueda ejecutar benchmarks desde un script y actuar sobre los resultados. Aquí es donde se gana su lugar en la automatización: ejecute una prueba, lea los números y haga fallar una compilación si la latencia cruza un umbral.

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()

El objeto result contiene histogramas para latency, requests y throughput, cada uno con campos average, min, max y percentiles como p99. También contiene los recuentos de errors, timeouts y non2xx.

Para convertir eso en un control, agregue una verificación que salga con un código distinto de cero cuando se exceda un presupuesto:

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(`Latencia p99: ${p99} ms (presupuesto ${P99_BUDGET_MS} ms)`)

  if (p99 > P99_BUDGET_MS || result.non2xx > 0) {
    console.error('Presupuesto de rendimiento excedido')
    process.exit(1)
  }
}

run()

Si desea la barra de progreso en vivo y la tabla de resultados que muestra la CLI, pase la instancia a 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())

Para un escenario de múltiples solicitudes, pase un array requests para que cada conexión realice varios llamados:

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)

autocannon vs wrk y ab

Los tres responden a la misma pregunta (qué tan rápido, bajo qué carga), y la elección correcta depende de su pila.

Apache Bench (ab) es la herramienta clásica de binario único. Está en todas partes y es simple, pero de un solo hilo y anticuada.
wrk es rápido y puede generar una carga pesada con scripting Lua para solicitudes personalizadas. Es una herramienta C compilada, por lo que se instala fuera de npm.
autocannon iguala a wrk en rendimiento para la mayoría de las cargas de trabajo y gana en ergonomía si ya trabaja en Node: npm i para instalar, una API de JavaScript para scripting y soporte para pipelining, archivos HAR y escenarios por solicitud de forma predeterminada.

Si Node es su entorno de ejecución, autocannon es la opción de baja fricción. ¿Prefiere las herramientas de Python? Consulte cómo realizar pruebas de carga sin Python. ¿Quiere una opción programable con un gran conjunto de características? Compare las pruebas de carga con k6.

Dónde encajan las pruebas funcionales y Apidog

autocannon le dice que su endpoint sirve 12,000 solicitudes por segundo con un p99 de 40 ms. No le dice si el endpoint devuelve los datos correctos. Una prueba de carga puede pasar con éxito mientras la API devuelve JSON malformado, ignora un encabezado de autenticación o se desvía de su contrato OpenAPI. El rendimiento no es la corrección.

Esa es la brecha que llenan las pruebas funcionales y de contrato, y es donde Apidog complementa una herramienta de carga en lugar de reemplazarla. Apidog no es un generador de carga. Ejecuta escenarios de prueba guardados que verifican códigos de estado, esquemas de respuesta y valores en flujos de varios pasos, para que pueda detectar los errores que un benchmark no puede ver.

Ambos se ejecutan en CI, y responden preguntas diferentes. Use autocannon (o wrk) para responder “¿es lo suficientemente rápido bajo carga?” Use la CLI de Apidog para responder “¿es correcto?” La CLI de Apidog es sin interfaz gráfica y ejecuta escenarios de prueba o suites guardados desde cualquier paso de CI que tenga Node:

npm install -g apidog-cli

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

El flag -t apunta a un escenario, carpeta o suite guardado por ID, -e selecciona el entorno y -r elige uno o más reportadores (cli, html, json, junit) para que la ejecución produzca artefactos que su pipeline pueda archivar. Para una guía completa, consulte cómo ejecutar pruebas de API desde la CLI de Apidog, el pipeline de CI/CD de copiar y pegar y el flujo de trabajo de GitHub Actions.

Un pipeline saludable ejecuta verificaciones funcionales y de contrato en cada push (¿funciona?), luego ejecuta una prueba de carga antes del lanzamiento (¿resiste?). autocannon se encarga de la segunda pregunta. Apidog se encarga de la primera.

Preguntas frecuentes

¿Es autocannon preciso para pruebas de carga en producción?

autocannon produce números fiables de rendimiento y latencia para endpoints HTTP/1.1, y cuando se establece una tasa objetivo con -R, corrige la omisión coordinada, un paso que muchas herramientas más simples omiten. Para obtener resultados precisos, ejecútelo desde una máquina cercana a su servidor (de lo contrario, la latencia de la red dominará) y use suficientes conexiones para saturar el endpoint. Ejecútelo contra un entorno de staging que refleje la producción, no contra el servidor de desarrollo de su portátil.

¿autocannon es compatible con HTTP/2 o WebSockets?

No. autocannon realiza benchmarks de HTTP/1.1. Para pruebas de carga de HTTP/2 o WebSockets necesita una herramienta diferente. Esta es la principal limitación a verificar antes de elegirlo.

¿Cuántas conexiones debería usar?

Comience con el valor predeterminado de 10, luego aumente -c hasta que las solicitudes por segundo dejen de aumentar y la latencia comience a escalar. Ese punto de inflexión es aproximadamente la capacidad de su servidor. Superarlo con creces mide más los límites de su generador de carga que los de su servidor.

¿Puedo ejecutar autocannon en CI?

Sí. La API programática está diseñada para ello: ejecute un benchmark, lea result.latency.p99 y result.non2xx, y llame a process.exit(1) cuando se exceda un presupuesto. Eso convierte un benchmark en una puerta de paso/falla que puede integrar en cualquier paso de CI compatible con Node.

¿Cuál es la diferencia entre -a y -d?

-d se ejecuta durante un número de segundos. -a se ejecuta hasta que se completa un número de solicitudes, luego se detiene. Use -d para una prueba de carga en estado estable y -a cuando desee enviar un número exacto de solicitudes.