驴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, como BuildJet
  • 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铆!

隆Abraza el Caos! para Bencher - Bencher

Puedes mirar este gr谩fico y pensar, 鈥溌aya, 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.

La Ley de Moore desde https://davidwells.io/blog/rise-of-embarrassingly-parallel-serverless-compute

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.

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.

Thoughworks Technology Radar, 22 de mayo de 2013

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 PruebaAlcance de la PruebaUsuarios de la Prueba
BenchmarkingFunci贸n - ServicioUno - Muchos
Prueba de CargaServicioMuchos

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.



Contin煤a: Inicio R谩pido 鉃

馃 Este documento fue generado autom谩ticamente por OpenAI GPT-4. Puede que no sea exacto y contenga errores. Si encuentra alg煤n error, abra un problema en GitHub.