¿Qué es Benchmark Testing?

¿Qué es benchmark testing?

Benchmark testing mide la performance de un sistema contra una referencia fija: un build previo, un producto competidor, una baseline de industria publicada o un SLO objetivo. El output es un número comparable (este build hace 1.800 RPS a p95 de 220 ms versus el build previo de 1.500 RPS a 240 ms) sobre el que engineering, product y leadership pueden actuar. La referencia es todo el punto: un solo número sin comparador es no informativo.

Los benchmarks son reproducibles por construcción. Mismo hardware, mismo dataset, mismo workload mix, mismo warm-up, misma ventana de medición. Un run que no puede reproducirse no es un benchmark, es una sola observación.

Benchmark testing vs load testing

Disciplinas adyacentes, preguntas distintas:

• Benchmark testing: responde "¿cómo se compara este build con aquel?" Workload fijo, environment fijo, comparable entre runs.
• Load testing: responde "¿qué le pasa a este sistema bajo N usuarios concurrentes?" El workload escala, la meta es encontrar el breaking point o validar contra un target. Ver load testing.

Usas load testing para descubrir capacidad y encontrar bottlenecks. Usas benchmark testing para trackear regresión en el tiempo y posicionar contra alternativas. Un load test produce una curva. Un benchmark produce un número.

Cuándo correr benchmark tests

• Antes/después de un refactor mayor: medir el mismo workload antes del rewrite y después, confirmar que no regresaste en throughput o latencia.
• Antes/después de un upgrade de runtime: Node 18 a Node 22, JDK 17 a JDK 21, Python 3.10 a 3.12. Los claims de vendor de "30% más rápido" casi nunca matchean tu workload.
• Antes/después de un version bump de base de datos: Postgres 14 a 16, MySQL 5.7 a 8.0. Cambios del query planner pueden mover la latencia per-endpoint en cualquier dirección.
• Al elegir entre tecnologías: Redis vs Memcached, Kafka vs NATS, Postgres vs MySQL. Los benchmarks de vendor son herramientas de ventas; construye un benchmark con tu workload y córrelo.
• Como gate de CI: un benchmark slim en cada PR atrapa regresiones multi-porcentuales antes del merge. No gatear sobre p99 (muy noisy) pero la latencia p50 y el throughput total son usables.
• Para positioning competitivo: "nuestra API responde en p95 80 ms; la suya en 180 ms" es un claim de marketing defendible solo si tu metodología de benchmark está publicada.

Características clave de benchmark

1. Workload mix fijo: mismo porcentaje de read vs write, misma distribución de parámetros, mismo flow de authentication.
2. Environment fijo: mismo instance type, misma región, misma red. Números cross-environment no son comparables.
3. Período de warm-up: los runtimes JIT-compiled (JVM, V8, .NET) y las bases de datos cold-cache producen números lentos en los primeros N requests; descartarlos.
4. Medición de steady-state: medir durante el plateau, no durante ramp-up o ramp-down.
5. Múltiples runs e intervalos de confianza: un solo run puede ser noisy; reportar mediana más intervalo de confianza sobre 5+ runs.
6. Metodología publicada: si el próximo engineer no puede correr tu benchmark desde el README, no es reproducible.

Cómo correr benchmark tests

Elegir una herramienta que encaje con tu protocolo: JMeter para amplia cobertura HTTP y de protocolos, k6 para scenarios scriptables e integración CI, wrk o wrk2 para throughput HTTP crudo, sysbench para microbenchmarks de bases de datos. Scriptear el mismo workload mix que producción (o una simplificación controlada).

Almacenar el output del run: requests/sec, latencia p50/p95/p99, error rate, CPU, memoria, más el git SHA y config. El benchmark solo es útil cuando puedes graficarlo en el tiempo y notar la regresión en el commit X. Combinar benchmarks con regression testing y gatear releases en ambos.

Correr scenarios de benchmark desde LoadFocus contra múltiples regiones cloud y almacenar los runs junto con metadata. Para trackear performance release-a-release con rigor de engineering, LoadFocus ofrece servicios de load testing donde ingenieros diseñan la metodología.