¿Qué es el benchmarking continuo?
La Evaluación Continua es una práctica de desarrollo de software en la cual los miembros de un equipo evalúan su trabajo frecuentemente, generalmente cada persona realiza al menos una evaluación diariamente, lo que resulta en múltiples evaluaciones por día. Cada evaluación es verificada por una construcción automatizada para detectar regresiones del desempeño tan rápidamente como sea posible. Muchos equipos descubren que este enfoque conduce a una reducción significativa de las regresiones de desempeño y permite a un equipo desarrollar software de alto rendimiento más rápidamente.
Hasta ahora, todo el mundo en la industria de software conoce la integración continua (CI). A nivel fundamental, CI tiene que ver con la detección y prevención de regresiones de funciones de software antes de que lleguen a la producción. De manera similar, el benchmarking continuo (CB) tiene como objetivo detectar y prevenir las regresiones en el desempeño del software antes de que lleguen a la producción. Por las mismas razones que las pruebas unitarias se ejecutan en CI para cada cambio de código, las pruebas de rendimiento deben ejecutarse en CB para cada cambio de código. Esta analogía es tan precisa en realidad, que el primer párrafo de esta sección es solo una versión Mad Libs de la introducción de Martin Fowler a la Integración Continua en 2006.
🐰 ¡Los errores de rendimiento son errores!
Evaluación en CI
Mito: No puedes ejecutar evaluaciones en CI
La mayoría de los arneses de evaluación utilizan el reloj del sistema para medir la latencia o el rendimiento. Esto es muy útil, ya que estas son las métricas exactas que a nosotros, como desarrolladores, más nos importan. Sin embargo, los entornos de CI de propósito general son a menudo ruidosos e inconsistentes al medir el tiempo de reloj. Al realizar evaluaciones continuas, esta volatilidad agrega ruido no deseado a los resultados.
Existen algunas opciones para manejar esto:
- Evaluación relativa
- Corredores de CI dedicados
- Cambiar de arneses de evaluación a uno que cuente las instrucciones en lugar del tiempo de reloj
¡O simplemente abraza el caos! La evaluación continua no tiene que ser perfecta. Sí, reducir la volatilidad y, por lo tanto, el ruido en tu entorno de evaluación continua te permitirá detectar regresiones de rendimiento cada vez más finas. Sin embargo, ¡no dejes que lo perfecto sea enemigo de lo bueno aquí!
Puedes mirar este gráfico y pensar, “¡Vaya, eso es una locura!” Pero pregúntate a ti mismo, ¿puede tu proceso de desarrollo actual detectar un factor de dos o incluso un factor de diez de regresión de rendimiento antes de que afecte a tus usuarios? ¡Probablemente no! ¡Ahora eso es una locura!
Incluso con todo el ruido de un entorno de CI, seguir las evaluaciones de tiempo de reloj puede seguir ofreciendo grandes dividendos en la detección de regresiones de rendimiento antes de que lleguen a tus clientes en producción. Con el tiempo, a medida que tu gestión de rendimiento de software madure, puedes partir de ahí. Mientras tanto, simplemente usa tu CI regular.
El Rendimiento Importa
Mito: No puedes notar 100ms de latencia
Es común escuchar a las personas afirmar que los humanos no pueden percibir 100ms de latencia. Un artículo del Grupo Nielsen sobre tiempos de respuesta es a menudo citado para esta afirmación.
0.1 segundo es aproximadamente el límite para que el usuario sienta que el sistema está respondiendo instantáneamente, lo que significa que no es necesario ningún feedback especial excepto para mostrar el resultado.
- Jakob Nielsen, 1 Ene 1993
Pero eso simplemente no es verdad.
En algunas tareas, las personas pueden percibir hasta 2ms de latencia.
Una manera fácil de probar esto es un experimento de Dan Luu: abre tu termial y ejecuta sleep 0; echo "ping" y luego 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 toma alrededor de 200ms 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 llega dos minutos tarde (latencia percibida) aunque el viaje en tren tarde 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, ganando +$380,000/yr)
- 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 inscripciones (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 pueden ejecutarse en paralelo necesitarán ser paralelizadas. Sin embargo, la mayoría de las cargas de trabajo necesitan ejecutarse en serie, y simplemente lanzar más cálculo al problema se está convirtiendo rápidamente en una solución intratable y costosa.
La Evaluación Continua es un componente clave para desarrollar y mantener software de alto rendimiento moderno ante este cambio.
Herramientas de Evaluación Continua
Antes de crear Bencher, nos propusimos encontrar una herramienta que pudiera:
- Seguir evaluaciones a través de múltiples lenguajes
- Ingerir sin problemas la salida estándar de los arneses de evaluación de los lenguajes
- Extensible para salida personalizada de los arneses de evaluación
- De código abierto y capaz de auto-alojarse
- Trabajar con múltiples hosts de CI
- Autenticación y autorización de usuarios
Desafortunadamente, no existía nada que cumpliera todos estos criterios. Ver arte previo para una lista completa de las herramientas de evaluación existentes de las que nos inspiramos.
Evaluación Continua en las Grandes Empresas de Tecnología
Herramientas como Bencher han sido desarrolladas internamente en Microsoft, Facebook (ahora Meta), Apple, Amazon, Netflix, y Google entre innumerables otras. Como los titanes de la industria, comprenden la importancia de monitorear el rendimiento durante el desarrollo e integrar estos conocimientos en el proceso de desarrollo a través de la evaluación continua. Construimos Bencher para llevar la evaluación continua desde detrás de las paredes de las grandes empresas de tecnología a la comunidad de código abierto. Para enlaces a publicaciones relacionadas con la evaluación continua de las grandes empresas de tecnología, consulte arte 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 lleguen a producción.
- Ejecutar: Ejecute sus benchmarks localmente o en CI usando sus herramientas de benchmarking favoritas. La CLI
benchersimplemente envuelve su arnés de benchmarks existente 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 en CI. Bencher utiliza analíticas de vanguardia y personalizables para detectar regresiones de rendimiento antes de que lleguen a producción.
Por las mismas razones que las pruebas unitarias se ejecutan en CI para prevenir regresiones funcionales, los benchmarks deberían ejecutarse en CI con Bencher para prevenir regresiones de rendimiento. ¡Los errores de rendimiento son errores!
Empiece a capturar regresiones de rendimiento en CI — prueba Bencher Cloud gratis.
Comparación Continua de Rendimiento vs Comparación Local de Benchmarks
Hay varios arneses de benchmark que te permiten comparar resultados localmente. La comparación local es excelente para iterar rápidamente mientras se ajusta el rendimiento. Sin embargo, no debe ser la única fuente para detectar regresiones de rendimiento de forma continua. Al igual que el poder ejecutar pruebas unitarias localmente no elimina la necesidad de CI, el poder ejecutar y comparar benchmarks localmente no elimina la necesidad de CB.
Bencher ofrece varias características que las herramientas de comparación local de benchmark no pueden ofrecer:
- Comparación del mismo benchmark entre diferentes laboratorios de pruebas
- Comparación de benchmarks a través de lenguajes y arneses
- Colaboración y compartición de resultados de benchmarks
- Ejecución de benchmarks en laboratorios de pruebas dedicados para minimizar el ruido
- Adiós al copia y pega
Comparación Continua de Rendimiento 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ñado para ser utilizado en producción. 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 los costos directos de corregir los defectos como los costos indirectos debido a relaciones dañadas, pérdida de negocios y pérdida de tiempo de desarrollo.
— Kent Beck, Extreme Programming Explained
Bencher ofrece varias características que las herramientas APM no pueden ofrecer:
- Detectar y prevenir regresiones de rendimiento antes de que lleguen a producción
- Cambios de rendimiento e impactos incluidos en la revisión de código
- Sin sobrecarga en ambientes de producción
- Efectivo para implementaciones locales
- Sin cambios en el código fuente de producción
Comparación Continua de Rendimiento vs Observabilidad
Una rosa con cualquier otro nombre olería igual de dulce. Ver Comparación Continua de Rendimiento vs Gestión de Rendimiento de Aplicaciones arriba.
Comparación Continua de Rendimiento vs Integración Continua (CI)
La Comparación Continua de Rendimiento (CB) es complementaria a la Integración Continua (CI). Por las mismas razones que las pruebas unitarias se ejecutan en CI para cada cambio de código, las pruebas de rendimiento deberían ejecutarse en CB para 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 comunes impulsan a los probadores a crear 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, conduciendo a mejores herramientas para crear y ejecutar pruebas de rendimiento, resultado en un conjunto de pruebas que es mantenible y puede ser probado.
Comparación Continua de Rendimiento vs Pruebas Continuas de Carga
Para entender la diferencia entre la Comparación Continua de Rendimiento y las Pruebas Continuas de Carga, 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 |
| Prueba 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 específica de tu código de manera aislada. Las pruebas de carga sólo prueban el rendimiento del software a nivel de servicio y simula 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 ser utilizado para medir cuánto tiempo se necesita para sacar un cono de helado (micro-benchmark), y el benchmarking también podría ser utilizado para medir cuánto tiempo tarda un solo cliente en pedir, obtener su helado y pagar (macro-benchmark). Las pruebas de carga podrían ser utilizadas para ver cómo el camión de helados atiende a 100 clientes en un día caluroso de verano.