¿Qué es el benchmark testing?

¿Qué es el benchmark testing?

El benchmark testing mide el rendimiento de un sistema frente a un estándar definido para que el resultado sea comparable. Ese estándar puede ser una versión anterior, un producto de la competencia, un benchmark de industria publicado o una baseline interna acordada. Todo el valor está en la comparación: un número solo dice poco, pero junto a una referencia muestra si el rendimiento mejoró, empeoró o se mantuvo. Así, "la app se siente rápida" pasa a ser "esta versión soporta más throughput con la misma latencia que la anterior", algo sobre lo que ingeniería, producto y dirección pueden actuar.

Un benchmark es repetible por construcción. Cada vez se usan el mismo hardware, el mismo conjunto de datos, la misma mezcla de carga, el mismo calentamiento y la misma ventana de medición. Una ejecución que no se puede reproducir no es un benchmark, sino una observación aislada. Los benchmarks públicos conocidos especifican su metodología hasta el último detalle de configuración precisamente para que equipos distintos obtengan cifras comparables.

Para qué sirve y cuándo usarlo

Haces un benchmark cuando necesitas una cifra defendible y comparable en lugar de una medición puntual. Casos habituales:

• Antes y después de un refactor: mide la misma carga antes y después de la reescritura para confirmar que no hay retroceso en throughput ni en latencia.
• Actualizaciones de runtime o dependencias: una nueva versión de un lenguaje, la JVM, una base de datos o un framework puede mover el rendimiento en cualquier dirección. Lo que dice el proveedor rara vez coincide con tu carga, así que mídelo.
• Elección de tecnología: al decidir entre dos bases de datos, cachés o brokers de mensajes, construye un benchmark con tu propia carga en lugar de fiarte de una comparativa del proveedor.
• Barreras en la integración continua: un benchmark reducido en cada pull request detecta regresiones de rendimiento antes de fusionar.
• Planificación de capacidad y coste: una baseline de rendimiento fiable permite dimensionar la infraestructura y prever el coste según crece el tráfico, véase pruebas de capacidad.
• Posicionamiento frente a la competencia: una metodología publicada y reproducible es lo que da credibilidad a un "más rápido que".

Qué son un benchmark y una baseline

Una baseline es el punto de referencia con el que mides. Suele ser la versión actual de producción o la última versión aceptada, capturada en condiciones controladas y guardada con todo su contexto. Un benchmark es la prueba estandarizada que se ejecuta para obtener un resultado comparable. En la práctica fijas la baseline una vez, ejecutas el benchmark repetidamente y comparas cada resultado con ella. Cuando una versión nueva pasa a ser el estándar aceptado, se convierte en la nueva baseline. Sin baseline, un resultado de benchmark es solo un número sin nada con lo que compararlo. Hay un resumen paso a paso en How to establish a performance baseline (en inglés).

Métricas clave que capturar

Un benchmark es tan útil como las métricas que registra. El conjunto básico:

• Throughput: peticiones o transacciones por segundo que el sistema mantiene. A menudo es la cifra principal del benchmark.
• Tiempo de respuesta y latencia: cuánto tarda una petición, expresado en percentiles y no como media. La media esconde la cola lenta.
• Percentiles de latencia (p50, p95, p99): el p50 es la experiencia típica; el p95 y el p99 describen la cola lenta que los usuarios reales notan bajo carga.
• Tasa de errores: la proporción de peticiones fallidas o con timeout. Un throughput alto no vale nada si los errores suben con él.
• Uso de recursos: CPU, memoria, disco y red del sistema probado. Indica cuánto margen queda y dónde está el cuello de botella.

Registra siempre throughput y latencia juntos. Un throughput medido mientras la tasa de errores sube o la latencia se dispara no es un punto de comparación válido.

Benchmark frente a pruebas de carga, estrés y rendimiento

Estas disciplinas se solapan, pero responden a preguntas distintas. El benchmark testing pregunta: "¿cómo se compara con una referencia?" Las pruebas de carga preguntan: "¿qué pasa con la concurrencia esperada?" Las pruebas de estrés preguntan: "¿dónde se rompe?" Las pruebas de rendimiento son el término general para todas.

En resumen: una prueba de carga produce una curva, una de estrés encuentra un límite y un benchmark produce un único número comparable que sigues de versión en versión.

Cómo ejecutar un benchmark

Un benchmark fiable sale de controlar todo lo que no es lo que mides:

1. Define la baseline: decide con qué comparas y captúrala en las mismas condiciones que usarás en cada ejecución futura.
2. Fija el entorno: mismo tipo de instancia, región, red y conjunto de datos. Las cifras de entornos distintos no son comparables.
3. Fija la mezcla de carga: la misma proporción de lecturas y escrituras, la misma distribución de parámetros y el mismo flujo de autenticación.
4. Calienta y luego mide: los runtimes con JIT y las cachés frías son lentos en las primeras peticiones. Descarta la ventana de calentamiento y mide solo la meseta estable.
5. Repite para ganar confianza: una sola ejecución puede tener ruido. Haz varias y presenta la mediana con su dispersión, no el mejor caso afortunado.
6. Registra todo: guarda throughput, percentiles de latencia, tasa de errores, uso de recursos, además del identificador de la versión y la configuración, para que cualquiera pueda reproducir la ejecución.

Benchmarks de industria frente a internos

Los benchmarks de industria son pruebas estandarizadas y publicadas que permiten comparar equipos distintos en una escala común. Valen para comparar proveedores, pero rara vez reflejan tu carga exacta. Los benchmarks internos se construyen con tus propios patrones de tráfico e importan más en el día a día, porque miden lo que hacen tus usuarios de verdad. Usa los de industria para contrastar una decisión tecnológica y los internos para detectar regresiones y orientar la optimización. Tomar el benchmark de un proveedor como una promesa sobre tu carga es la forma más común de que un benchmark engañe.

Benchmark de APIs y aplicaciones web

En una API, haz el benchmark de cada endpoint crítico por separado, con un payload y una autenticación realistas, y sigue el throughput y los percentiles de latencia por endpoint. Un cambio en una consulta compartida o en un índice puede mover un endpoint y dejar otros intactos, así que una cifra agregada puede ocultar una regresión real.

En una aplicación web, mide tanto el lado servidor (throughput y latencia con concurrencia) como la experiencia en el cliente (lo rápido que las páginas se vuelven utilizables). Están relacionados pero son distintos: un backend rápido puede entregar una página lenta, y una página puede parecer rápida mientras el backend está cerca de saturarse. Mídelos por separado para saber qué lado se movió.

Interpretar y seguir los resultados en el tiempo

Un resultado de benchmark solo importa en contexto. Compáralo con la baseline, no con un objetivo absoluto sacado de la nada. Una pequeña variación entre ejecuciones es normal, así que decide de antemano qué tamaño de cambio cuenta como regresión real y no como ruido. El verdadero beneficio llega al guardar cada ejecución y representar la tendencia: una deriva lenta a lo largo de varias versiones es invisible en una comparación aislada, pero evidente en un gráfico, y un salto brusco apunta directamente al commit que lo causó. Combina el benchmarking con las pruebas de regresión y condiciona los releases a ambos, para que una regresión de rendimiento se detecte igual que un fallo funcional.

Para seguir un benchmark en LoadFocus, ejecútalo como prueba de carga en la nube, guarda una buena ejecución como baseline y usa la comparación con la baseline para ver cada ejecución posterior a su lado. Combínalo con pruebas de regresión para que una versión más lenta falle antes del release, y lee los resultados como percentiles en vez de promedios (artículo en inglés).

Errores comunes

• Entornos con ruido: los runners de CI compartidos, los procesos en segundo plano y una red ocupada añaden variación que tapa la señal. Aísla el sistema probado.
• Comparaciones injustas: cambiar dos cosas a la vez o comparar entre hardware o datos distintos deja el resultado sin sentido.
• Saltarse el calentamiento: incluir peticiones de arranque en frío subestima el rendimiento real y añade ruido.
• Medias en lugar de percentiles: una buena media puede esconder una cola terrible que los usuarios sufren cada día.
• Una ejecución y listo: una sola medición no tiene confianza asociada y puede ser pura suerte.
• Cargas poco realistas: un benchmark que machaca un endpoint trivial no dice nada del comportamiento en producción.

Buenas prácticas

• Publica tu metodología para que cualquiera pueda reproducir la ejecución a partir de una descripción escrita.
• Cambia una sola variable cada vez y mantén todo lo demás fijo.
• Informa siempre del throughput junto con los percentiles de latencia y la tasa de errores.
• Automatiza un benchmark ligero en CI para detectar regresiones pronto y barato.
• Guarda los resultados con el identificador de la versión y la configuración, y sigue la tendencia, no solo el último valor.
• Haz el benchmark en condiciones cercanas a tus usuarios, con geografía y red realistas, cuando importe la experiencia del cliente.

Preguntas frecuentes sobre el benchmark testing

¿Es lo mismo benchmark testing que prueba de carga?

No. El benchmark testing compara un sistema con una referencia fija en condiciones idénticas y controladas para obtener un número comparable. La prueba de carga aumenta la carga hasta la demanda esperada para ver cómo se comporta el sistema y dónde se vuelve lento. Se complementan: la prueba de carga encuentra la capacidad y el benchmark sigue el cambio en el tiempo.

¿Qué hace válido a un benchmark?

La repetibilidad. Si otra persona no puede volver a ejecutar tu benchmark y obtener un resultado comparable, es una observación aislada. Un benchmark válido fija el entorno, los datos y la mezcla de carga, descarta el calentamiento, mide el estado estable y está documentado lo bastante bien como para reproducirse.

¿Qué métricas debe capturar un benchmark?

Como mínimo, throughput, percentiles del tiempo de respuesta como p50, p95 y p99, tasa de errores y uso de recursos. Throughput y latencia deben leerse juntos, porque un throughput alto no es una mejora real si para lograrlo subieron la tasa de errores o la latencia de la cola.

¿Por qué usar percentiles y no el tiempo de respuesta medio?

Una media mezcla peticiones rápidas y lentas en una sola cifra y esconde la cola lenta. Los percentiles muestran la distribución: el p50 es la experiencia típica, mientras que el p95 y el p99 describen las peores peticiones, las que los usuarios reales notan, y donde a menudo aparece primero una regresión.

¿Con qué frecuencia debo ejecutar benchmarks?

Ejecuta un benchmark ligero de forma continua, idealmente en cada pull request o candidato a release, para que las regresiones salgan pronto. Haz uno más completo antes de cambios grandes como refactors, actualizaciones de runtime o cambios de tecnología, y siempre que necesites una cifra defendible para planificar capacidad o comparar.

¿Puedo fiarme del benchmark publicado por un proveedor?

Tómalo como punto de partida, no como promesa. Los benchmarks de proveedores suelen ejecutarse con cargas y configuraciones que favorecen su producto. Solo un benchmark con tu propia carga en tu propio entorno refleja tu realidad, por eso los benchmarks internos pesan más en las decisiones técnicas.