HTTP Benchmark con wrk

Últimamente he estado explorando Bun, el toolkit todo-en-uno para JavaScript/TypeScript que integra Runtime, Package Manager, Test Runner y Bundler en una sola herramienta. Lo he combinado con ElysiaJS, un framework backend diseñado específicamente para Bun.

Sus cifras son llamativas: 2x más rápido que esbuild y 4x más rápido en runtime que Node.js. Pero como desarrollador, me interesa saber como realizar y comprobar un benchmark.

Esto me llevó a preguntarme algo que, siendo honesto, nunca había profundizado del todo: ¿cómo se mide correctamente el rendimiento de una Web API sobre HTTP?

Conozco las pruebas de carga con Postman, los scripts con curl y las herramientas de gestión de APIs. Sin embargo, quería algo más inicial antes de adentrarme a software más especializado. Ahí fue donde encontré wrk.

¿Qué es wrk?

wrk es una herramienta moderna de benchmarking HTTP capaz de generar una carga significativa desde una sola CPU multinúcleo. Es ligera, precisa y perfecta para pruebas iniciales de rendimiento.

Lo que mide:

Requests por segundo (RPS)
Latencia promedio
Latencia alta (p95 / p99)
Errores de respuesta
Comportamiento de CPU y memoria

Pre-configuración del entorno de prueba

Para mantener el benchmark controlado y reproducible, utilicé dos endpoints de mi aplicación con las siguientes características:

Persistencia in-memory (sin base de datos)
Sin autenticación JWT
Enrutamiento directo sin lógica pesada en el lado del controlador

Esto no simula un entorno de producción real, pero es exactamente el punto: necesitamos una línea base limpia antes de añadir complejidad.

Instalación de wrk

# macOS / Linux con Homebrew
brew install wrk

# Alternativa: clonar y compilar desde el repositorio oficial
# https://github.com/wg/wrk

Ejecución del benchmark

wrk -t2 -c10 -d30s http://localhost:4001/api/endpoint1

Parámetros utilizados:

Parámetro	Valor	Significado
’-t2’	2	Threads de prueba
’-c10’	10	Conexiones concurrentes
’-d30s’	30s	Duración de la prueba

Resultados obtenidos

Running 30s test @ http://localhost:4001/api/endpoint1
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max    +/- Stdev
    Latency     57.10us   56.26us   3.80ms  97.62%
    Req/Sec     87.48k    7.07k    99.66k   76.41%
  5,239,206 requests in 30.10s, 654.54MB read

Requests/sec: 174,060.34
Transfer/sec:  21.75MB

Interpretando los resultados

174,060 RPS — ¿Es bueno?

Para un endpoint sin base de datos ni autenticación, sí es un excelente punto de partida. Establece el techo teórico de rendimiento antes de que la lógica de negocio entre en juego.

El contexto importa

Sin embargo, hay que ser cuidadosos: este resultado no representa un escenario de producción real. Los factores que realmente rompen las métricas en producción son:

Consultas a base de datos (el principal cuello de botella)
ORM y capas de abstracción de datos
Llamadas a servicios externos o microservicios
Lógica de autenticación y autorización
Logging excesivo o no estructurado

Latencia: el indicador que más importa

Una latencia promedio de 57µs (microsegundos) en local es extraordinaria. Como referencia práctica:

< 20ms en local → condición óptima para continuar
p95 / p99 altos → señal de inconsistencia bajo carga

Siempre presta más atención a los percentiles altos (p95, p99) que al promedio. El promedio oculta los casos extremos que tus usuarios reales sí van a experimentar.

¿Cuándo usar este tipo de benchmark?

wrk con endpoints simples es ideal para:

Establecer una línea base de rendimiento
Comparar dos implementaciones bajo las mismas condiciones
Detectar regresiones de rendimiento entre versiones
Validar que el runtime no es el cuello de botella

No es adecuado para:

Simular tráfico de producción complejo
Medir el rendimiento con carga de base de datos real
Tomar decisiones de arquitectura definitivas

Conclusión: Mide antes de optimizar

Este ejercicio me confirmó algo que ya sabía en teoría pero que siempre vale la pena recordar:

Lo que no se mide no se puede mejorar.

Bun + ElysiaJS ofrece un rendimiento impresionante en condiciones controladas. Pero el runtime rara vez es el problema real en producción. Antes de asumir que necesitas cambiar de tecnología, mide.

Checklist para hacer benchmarks responsables

Mide primero, optimiza después
No te quedes solo con el RPS; analiza la latencia
Revisa los percentiles altos (p95, p99)
Observa el uso de CPU durante la prueba
Realiza pruebas sostenidas (30–60 segundos mínimo)