¿Qué es el benchmarking continuo?
El Benchmarking Continuo es una práctica de desarrollo de software en la cual los miembros de un equipo ejecutan benchmarks sobre su trabajo con frecuencia, normalmente cada persona realiza al menos un benchmark al día, lo que se traduce en múltiples benchmarks diarios. Cada benchmark es verificado por una construcción automatizada para detectar regresiones de rendimiento lo más rápido posible. Muchos equipos descubren que este enfoque lleva a una reducción significativa de las regresiones de rendimiento y le permite al equipo desarrollar software de alto rendimiento con mayor rapidez.
A estas alturas, todo el mundo en la industria del software conoce la Integración Continua (CI). En un nivel fundamental, CI consiste en detectar y prevenir regresiones de funcionalidades de software antes de que lleguen a producción. De manera similar, el Benchmarking Continuo (CB) consiste en detectar y prevenir regresiones de rendimiento del software antes de que lleguen a producción. Por las mismas razones por las que las pruebas unitarias se ejecutan en CI ante cada cambio de código, las pruebas de rendimiento deberían ejecutarse en CB ante cada cambio de código. Esta analogía es tan acertada que, de hecho, el primer párrafo de esta sección no es más que una versión Mad Libs de la introducción a la Integración Continua de Martin Fowler de 2006.
🐰 ¡Los bugs de rendimiento son bugs!
Benchmarking en CI
Mito: No puedes ejecutar benchmarks en CI
La mayoría de los arneses de benchmarks usan el reloj del sistema para medir la latencia o el rendimiento. Esto es muy útil, ya que son precisamente las métricas que más nos importan como desarrolladores. Sin embargo, los entornos de CI de propósito general suelen ser ruidosos e inconsistentes a la hora de medir el tiempo de reloj. Al hacer Benchmarking Continuo, esa volatilidad agrega ruido no deseado a los resultados.
Existen varias opciones para lidiar con esto:
- Runners en Hardware Dedicado
- Benchmarking Continuo Relativo
- Cambiar a un arnés de benchmarks que cuente instrucciones en lugar de tiempo de reloj
Con diferencia, los Runners en Hardware Dedicado son la mejor opción en prácticamente todos los casos. Bencher ofrece Runners en Hardware Dedicado con menos del 2% de variación. Compáralo con los Runners de GitHub Actions, que pueden presentar más del 30% de variación entre ejecuciones. Reducir la volatilidad, y por lo tanto el ruido, en tu entorno de Benchmarking Continuo te permitirá detectar regresiones de rendimiento cada vez más finas.
El Rendimiento Importa
Mito: No puedes notar 100ms de latencia
Es común escuchar a la gente afirmar que los humanos no pueden percibir 100ms de latencia. A menudo se cita un artículo del Nielsen Group sobre tiempos de respuesta para respaldar esta afirmación.
0.1 segundos es aproximadamente el límite para que el usuario sienta que el sistema está reaccionando de forma instantánea, lo que significa que no es necesaria ninguna retroalimentación especial aparte de mostrar el resultado.
- Jakob Nielsen, 1 de enero de 1993
Pero eso simplemente no es verdad.
En algunas tareas, las personas pueden percibir tan solo 2ms de latencia.
Una manera fácil de comprobarlo es un experimento de Dan Luu: abre tu terminal y ejecuta sleep 0; echo "ping" y después ejecuta sleep 0.1; echo "pong". ¿Notaste la diferencia verdad‽
Otro punto común de confusión es la distinción entre la percepción de la latencia y los tiempos de reacción humanos. A pesar de que tarda alrededor de 200ms en responder a un estímulo visual, eso es independiente de la percepción del evento en sí. Por analogía, puedes darte cuenta de que tu tren lleva dos minutos de retraso (latencia percibida) aunque el viaje en tren dure dos horas (tiempo de reacción).
¡El rendimiento importa! ¡El rendimiento es una característica!
- Cada 100ms más rápido → 1% más de conversiones (Mobify, generando +$380,000 al año)
- 50% más rápido → 12% más de ventas (AutoAnything)
- 20% más rápido → 10% más de conversiones (Furniture Village)
- 40% más rápido → 15% más de registros (Pinterest)
- 850ms más rápido → 7% más de conversiones (COOK)
- Cada 1 segundo más lento → 10% menos usuarios (BBC)
Con la muerte de la Ley de Moore, las cargas de trabajo que se pueden ejecutar en paralelo tendrán que paralelizarse. Sin embargo, la mayoría de las cargas de trabajo necesitan ejecutarse en serie, y simplemente lanzar más cómputo al problema se está convirtiendo rápidamente en una solución intratable y costosa.
El Benchmarking Continuo es un componente clave para desarrollar y mantener software moderno de alto rendimiento frente a este cambio.
Herramientas de Benchmarking Continuo
Antes de crear Bencher, nos propusimos encontrar una herramienta que pudiera:
- Ejecutar benchmarks sobre el exacto mismo hardware dedicado tanto localmente como en CI
- Rastrear benchmarks en múltiples lenguajes
- Ingerir sin fricción la salida estándar de los arneses de benchmarks de cada lenguaje
- Ser extensible para salidas de arneses de benchmarks personalizados
- Ser de código abierto y permitir el auto-hospedaje
- Funcionar con múltiples proveedores de CI
- Autenticación y autorización de usuarios
Lamentablemente, no existía nada que cumpliera todos estos criterios. Consulta el trabajo previo para ver una lista completa de las herramientas de benchmarking existentes en las que nos inspiramos.
Benchmarking Continuo Fuera de CI
CI está pensado como una verificación final, no como el único lugar donde se realizan las pruebas. Bencher es la primera herramienta de Benchmarking Continuo que te permite ejecutar tus benchmarks sobre el exacto mismo hardware dedicado tanto localmente como en CI. Esto permite que tanto desarrolladores como agentes comparen su trabajo local en curso contra cualquier punto del historial de rendimiento del proyecto.
Al ejecutarse en hardware local, Bencher Bare Metal te permite seguir haciendo otras tareas en paralelo. No necesitas detener todo lo demás en tu sistema, traer una rama antigua y ejecutar una comparación.
Al ejecutarse en un entorno en la nube, Bencher Bare Metal te permite confiar en los resultados. No tienes que preocuparte por vecinos ruidosos, limitaciones de recursos, ni por cambios de host a mitad de la ejecución.
El Benchmarking Continuo en las Grandes Empresas de Tecnología
Herramientas como Bencher se han desarrollado internamente en Microsoft, Facebook (ahora Meta), Apple, Amazon, Netflix y Google, entre incontables otras. Como titanes de la industria, entienden la importancia de monitorear el rendimiento durante el desarrollo e integrar esos conocimientos en el proceso de desarrollo mediante el Benchmarking Continuo. Construimos Bencher para llevar el Benchmarking Continuo desde detrás de los muros de las Grandes Empresas de Tecnología a la comunidad de código abierto. Para ver enlaces a publicaciones relacionadas con el Benchmarking Continuo en las Grandes Empresas de Tecnología, consulta el trabajo previo.
Bencher: Benchmarking continuo
Bencher es un conjunto de herramientas de benchmarking continuo. ¿Alguna vez has tenido un impacto de regresión de rendimiento en tus usuarios? Bencher podría haber evitado que eso sucediera. Bencher te permite detectar y prevenir las regresiones de rendimiento antes de que se fusionen.
- Ejecutar: Ejecute sus benchmarks localmente o en CI usando exactamente los mismos runners bare metal y sus herramientas de benchmarking favoritas. La CLI
bencherorquesta la ejecución de sus benchmarks en bare metal y almacena sus resultados. - Seguir: Sigue los resultados de tus benchmarks con el tiempo. Monitoriza, realiza consultas y representa gráficamente los resultados utilizando la consola web de Bencher basándose en la rama de origen, el banco de pruebas y la medida.
- Capturar: Captura las regresiones de rendimiento localmente o en CI usando exactamente el mismo hardware bare metal. Bencher utiliza analíticas de vanguardia y personalizables para detectar regresiones de rendimiento antes de que se fusionen.
Por las mismas razones que las pruebas unitarias se ejecutan para prevenir regresiones funcionales, los benchmarks deberían ejecutarse con Bencher para prevenir regresiones de rendimiento. ¡Los errores de rendimiento son errores!
Empiece a capturar regresiones de rendimiento — prueba Bencher Cloud gratis.
Benchmarking Continuo vs Comparación Local de Benchmarks
Hay varios arneses de benchmarks que te permiten comparar resultados localmente. La comparación local es excelente para iterar rápidamente cuando se ajusta el rendimiento. Sin embargo, no debería ser la vía en la que se confíe para detectar regresiones de rendimiento de forma continua. Al igual que poder ejecutar pruebas unitarias localmente no elimina la necesidad de CI, poder ejecutar y comparar benchmarks localmente no elimina la necesidad del Benchmarking Continuo.
Existen varias características que Bencher ofrece y que las herramientas de comparación local de benchmarks no pueden ofrecer:
- Comparación del mismo benchmark entre distintos bancos de pruebas
- Comparación de benchmarks entre lenguajes y arneses
- Colaboración y compartición de resultados de benchmarks
- Ejecución de benchmarks en bancos de pruebas dedicados para minimizar el ruido
- Adiós al copia y pega
Benchmarking Continuo vs Gestión del Rendimiento de las Aplicaciones (APM)
La Gestión del Rendimiento de las Aplicaciones (APM) es una herramienta vital para los servicios de software modernos. Sin embargo, APM está diseñada para usarse en producción. Para cuando se detecta una regresión de rendimiento, ya está afectando a tus clientes.
La mayoría de los defectos terminan costando más de lo que habría costado prevenirlos. Los defectos son costosos cuando ocurren, tanto por los costos directos de arreglarlos como por los costos indirectos derivados de relaciones dañadas, pérdida de negocio y pérdida de tiempo de desarrollo.
— Kent Beck, Extreme Programming Explained
Existen varias características que Bencher ofrece y que las herramientas APM no pueden ofrecer:
- Detectar regresiones de rendimiento antes de que se fusionen
- Cambios e impactos de rendimiento incluidos en la revisión de código
- Sin sobrecarga en los entornos de producción
- Efectivo para despliegues on-premise
- Sin cambios en el código fuente de producción
Benchmarking Continuo vs Observabilidad
Una rosa con cualquier otro nombre olería igual de dulce. Consulta Benchmarking Continuo vs Gestión del Rendimiento de las Aplicaciones más arriba.
Benchmarking Continuo vs Integración Continua (CI)
El Benchmarking Continuo (CB) es complementario a la Integración Continua (CI). Por las mismas razones por las que las pruebas unitarias se ejecutan en CI ante cada cambio de código, las pruebas de rendimiento deberían ejecutarse en CB ante cada cambio de código.
Mientras que las pruebas unitarias y de aceptación son ampliamente adoptadas como prácticas de desarrollo estándar, esta tendencia no ha continuado en el ámbito de las pruebas de rendimiento. Actualmente, las herramientas habituales empujan a los testers hacia la creación de código desechable y una mentalidad de clic y script. Tratar las pruebas de rendimiento como un ciudadano de primera clase permite la creación de mejores pruebas que cubren más funcionalidad, dando lugar a mejores herramientas para crear y ejecutar pruebas de rendimiento, lo que resulta en una suite de pruebas mantenible y que puede ser probada a sí misma.
Benchmarking Continuo vs Pruebas de Carga Continuas
Para entender la diferencia entre el Benchmarking Continuo y las Pruebas de Carga Continuas, necesitas entender la diferencia entre benchmarking y pruebas de carga.
| Tipo de Prueba | Alcance de la Prueba | Usuarios de la Prueba |
|---|---|---|
| Benchmarking | Función - Servicio | Uno - Muchos |
| Pruebas de Carga | Servicio | Muchos |
El benchmarking puede probar el rendimiento del software desde el nivel de función (micro-benchmarks) hasta el nivel de servicio (macro-benchmarks). Los benchmarks son excelentes para probar el rendimiento de una parte concreta de tu código de manera aislada. Las pruebas de carga solo prueban el rendimiento del software a nivel de servicio y simulan múltiples usuarios concurrentes. Las pruebas de carga son excelentes para probar el rendimiento de todo el servicio bajo una carga específica.
🍦 Imagina que queremos seguir el rendimiento de un camión de helados. El benchmarking podría usarse para medir cuánto se tarda en servir un cono de helado (micro-benchmark), y el benchmarking también podría usarse para medir cuánto tarda un único cliente en pedir, recibir su helado y pagar (macro-benchmark). Las pruebas de carga podrían usarse para ver cómo atiende el camión de helados a 100 clientes en un caluroso día de verano.