Cómo seguir los benchmarks en CI con Bencher
La mayoría de los resultados de los benchmarks son efímeros. Desaparecen tan pronto como su terminal alcanza su límite de desplazamiento. Algunos sistemas de benchmark permiten cachear los resultados, pero la mayoría solo lo hacen localmente. Bencher le permite rastrear sus benchmarks tanto de ejecuciones locales como de CI y comparar los resultados, mientras sigue utilizando su sistema de benchmark favorito.
Hay dos maneras populares de comparar resultados de benchmarks cuando se hace Benchmarking Continuo, es decir, benchmarking en CI:
- Benchmarking Continuo Estadístico
- Rastrear los resultados de los benchmarks a lo largo del tiempo para crear una línea base
- Usar esta línea base junto con Umbrales Estadísticos para crear un límite estadístico
- Comparar los nuevos resultados contra este límite estadístico para detectar regresiones de rendimiento
- Benchmarking Continuo Relativo
- Ejecutar los benchmarks para el código base actual
- Usar Umbrales Porcentuales para crear un límite para el código base
- Cambiar a la nueva versión del código
- Ejecutar los benchmarks para la nueva versión del código
- Comparar los resultados de la nueva versión del código contra los resultados del código base para detectar regresiones de rendimiento
Benchmarking Continuo Estadístico
Retomando donde lo dejamos en los tutoriales de
Inicio Rápido y Docker Autohospedado,
agreguemos Benchmarking Continuo Estadístico a nuestro proyecto Save Walter White
.
🐰 Asegúrate de haber creado un token API y establecido como variable de entorno
BENCHER_API_TOKEN
antes de continuar.
Primero, necesitamos crear un nuevo Banco de Pruebas para representar nuestros runners de CI, llamado apropiadamente ci-runner
.
- Usa el subcomando CLI
bencher testbed create
. Consulta la documentación detestbed create
para más detalles. (ej:bencher testbed create
) - Establece la opción
--name
al nombre deseado del Banco de Pruebas. (ej:--name ci-runner
) - Especifica el argumento del proyecto como el slug del proyecto
Save Walter White
. (ej:save-walter-white-1234abcd
)
A continuación, necesitamos crear un nuevo Umbral para nuestro banco de pruebas ci-runner
:
- Usa el subcomando CLI
bencher threshold create
. Consulta la documentación dethreshold create
para más detalles. (ej:bencher threshold create
) - Establece la opción
--branch
a la Rama predeterminadamain
. (ej:--branch main
) - Establece la opción
--branch
al nuevo banco de pruebasci-runner
. (ej:--testbed ci-runner
) - Establece la opción
--measure
a la MedidaLatency
incorporada que es generada porbencher mock
. Consulta la definición de Medida para más detalles. (ej:--measure Latency
) - Establece la opción
--test
a un Umbralt-test
. Consulta Umbrales y Alertas para una visión completa. (ej:--test t-test
) - Establece la opción
--upper-boundary
a un Límite Superior de0.95
. Consulta Umbrales y Alertas para una visión completa. (ej:--upper-boundary 0.95
) - Especifica el argumento del proyecto como el slug del proyecto
Save Walter White
. (ej:save-walter-white-1234abcd
)
Ahora estamos listos para ejecutar nuestros benchmarks en CI. Debido a que cada entorno de CI es un poco diferente, el siguiente ejemplo está destinado a ser más ilustrativo que práctico. Para ejemplos más específicos, consulta Benchmarking Continuo en GitHub Actions y Benchmarking Continuo en GitLab CI/CD.
Necesitamos crear y mantener una línea base histórica para nuestra rama main
ejecutando benchmarks en cada cambio en CI:
- Usa el subcomando CLI
bencher run
para ejecutar tus benchmarks de la ramafeature-branch
. Consulta el subcomando CLIbencher run
para una visión completa. (ej:bencher run
) - Establece la opción
--project
al slug del Proyecto. Consulta la documentación de--project
para más detalles. (ej:--project save-walter-white-1234abcd
) - Establece la opción
--branch
al nombre de la Rama predeterminada. Consulta selección de rama para una visión completa. (ej:--branch main
) - Establece la opción
--testbed
al nombre del Banco de Pruebas. Consulta la documentación de--testbed
para más detalles. (ej:--testbed ci-runner
) - Establece la opción
--adapter
al adaptador de harness de benchmark deseado. Consulta adaptadores de harness de benchmark para una visión completa. (ej:--adapter json
) - Establece la opción
--err
para fallar el comando si se genera una Alerta. Consulta Umbrales y Alertas para una visión completa. (ej:--err
) - Especifica los argumentos de comando de benchmark.
Consulta comando de benchmark para una visión completa.
(ej:
bencher mock
)
Finalmente, estamos listos para detectar regresiones de rendimiento en CI.
Así es como rastrearíamos el rendimiento de una nueva rama de función, llamada feature-branch
, en CI:
- Usa el subcomando CLI
bencher run
para ejecutar tus benchmarks de la ramafeature-branch
. Consulta el subcomando CLIbencher run
para una visión completa. (ej:bencher run
) - Establece la opción
--project
al slug del Proyecto. Consulta la documentación de--project
para más detalles. (ej:--project save-walter-white-1234abcd
) - Establece la opción
--branch
al nombre de la Rama de función. Consulta selección de rama para una visión completa. (ej:--branch feature-branch
) - Establece la opción
--branch-start-point
al punto de inicio de la Rama de función. Consulta selección de rama para una visión completa. (ej:--branch-start-point main
) - Establece la opción
--branch-start-point-hash
al hashgit
del punto de inicio de la Rama de función. Consulta selección de rama para una visión completa. (ej:--branch-start-point-hash 32ae...dd8b
) - Establece la opción
--branch-reset
para siempre restablecer la Rama al punto de inicio. Esto evitará la deriva de datos de benchmark. Consulta selección de rama para una visión completa. (ej:--branch-reset
) - Establece la opción
--testbed
al nombre del Banco de Pruebas. Consulta la documentación de--testbed
para más detalles. (ej:--testbed ci-runner
) - Establece la opción
--adapter
al adaptador de harness de benchmark deseado. Consulta adaptadores de harness de benchmark para una visión completa. (ej:--adapter json
) - Establece la opción
--err
para fallar el comando si se genera una Alerta. Consulta Umbrales y Alertas para una visión completa. (ej:--err
) - Especifica los argumentos de comando de benchmark.
Consulta comando de benchmark para una visión completa.
(ej:
bencher mock
)
La primera vez que este comando se ejecute en CI,
creará la Rama feature-branch
ya que aún no existe.
La nueva Rama feature-branch
usará la Rama main
en el hash 32aea434d751648726097ed3ac760b57107edd8b
como su punto de inicio.
Esto significa que feature-branch
tendrá una copia de todos los datos y Umbrales
de la Rama main
para comparar los resultados de bencher mock
frente,
en la primera y todas las ejecuciones subsiguientes.
Benchmarking Continuo Relativo
Retomando donde lo dejamos en los tutoriales
Inicio Rápido y Docker Autohospedado,
vamos a añadir Benchmarking Continuo Relativo a nuestro proyecto Save Walter White
.
🐰 Asegúrate de haber creado un token de API y establecerlo como la variable de entorno
BENCHER_API_TOKEN
antes de continuar.
Primero, necesitamos crear un nuevo Testbed para representar nuestros corredores de CI, con el nombre apropiado de ci-runner
.
- Usa el subcomando CLI de
bencher testbed create
. Consulta los documentos detestbed create
para más detalles. (ej:bencher testbed create
) - Establece la opción
--name
al nombre de Testbed deseado. (ej:--name ci-runner
) - Especifica el argumento de proyecto como el slug del proyecto
Save Walter White
. (ej:save-walter-white-1234abcd
)
El Benchmarking Continuo Relativo ejecuta una comparación lado a lado de dos versiones de tu código.
Esto puede ser útil al tratar con ambientes CI/CD ruidosos,
donde los recursos disponibles pueden variar mucho entre ejecuciones.
En este ejemplo estaremos comparando los resultados de ejecutar en la rama main
con resultados de ejecutar en una rama de características llamada feature-branch
.
Dado que cada ambiente CI es un poco diferente,
el siguiente ejemplo está destinado a ser más ilustrativo que práctico.
Para ejemplos más específicos, consulta Benchmarking Continuo en GitHub Actions
y Benchmarking Continuo en GitLab CI/CD.
Primero, necesitamos hacer checkout de la rama main
con git
en CI:
Luego necesitamos ejecutar nuestros benchmarks en la rama main
en CI:
- Usa el subcomando CLI de
bencher run
para ejecutar tus benchmarks de la ramamain
. Consulta el subcomando CLIbencher run
para una visión general completa. (ej:bencher run
) - Establece la opción
--project
al slug del Proyecto. Consulta los documentos de--project
para más detalles. (ej:--project save-walter-white-1234abcd
) - Establece la opción
--branch
al nombre de la rama de característica. Consulta selección de rama para una visión general completa. (ej:--branch feature-branch
) - Activa la bandera
--branch-reset
. Consulta selección de rama para una visión general completa. (ej:--branch-reset
) - Establece la opción
--testbed
al nombre del Testbed. Consulta los documentos de--tested
para más detalles. (ej:--testbed ci-runner
) - Establece la opción
--adapter
al adaptador de arnés de benchmark deseado. Consulta adaptadores de arnés de benchmark para una visión general completa. (ej:--adapter json
) - Especifica los argumentos del comando de benchmark.
Consulta comando de benchmark para una visión general completa.
(ej:
bencher mock
)
La primera vez que este comando se ejecute en CI,
creará la rama feature-branch
ya que aún no existe.
La nueva feature-branch
no tendrá un punto de inicio, datos existentes, ni Umbrales.
En las ejecuciones subsiguientes, la versión antigua de feature-branch
será renombrada
y se creará una nueva feature-branch
sin un punto de inicio, datos existentes, ni Umbrales.
A continuación, necesitamos crear un nuevo Umbral en CI para nuestra nueva rama feature-branch
:
- Usa el subcomando CLI de
bencher threshold create
. Consulta los documentos dethreshold create
para más detalles. (ej:bencher threshold create
) - Establece la opción
--branch
a la nueva ramafeature-branch
. (ej:--branch feature-branch
) - Establece la opción
--branch
al Testbedci-runner
. (ej:--testbed ci-runner
) - Establece la opción
--measure
a la MedidaLatency
incorporada que es generada porbencher mock
. Consulta la definición de Medida para detalles. (ej:--measure Latency
) - Establece la opción
--test
a un Umbral depercentage
. Consulta Umbrales & Alertas para una visión general completa. (ej:--test t-test
) - Establece la opción
--upper-boundary
a un Límite Superior de0.25
(es decir,25%
). Consulta Umbrales & Alertas para una visión general completa. (ej:--upper-boundary 0.25
) - Especifica el argumento de proyecto como el slug del proyecto
Save Walter White
. (ej:save-walter-white-1234abcd
)
Luego, necesitamos hacer checkout de la rama feature-branch
con git
en CI:
Finalmente, estamos listos para ejecutar nuestros benchmarks de feature-branch
en CI:
- Usa el subcomando CLI de
bencher run
para ejecutar tus benchmarks defeature-branch
. Consulta el subcomando CLIbencher run
para una visión general completa. (ej:bencher run
) - Establece la opción
--project
al slug del Proyecto. Consulta los documentos de--project
para más detalles. (ej:--project save-walter-white-1234abcd
) - Establece la opción
--branch
al nombre de la rama de característica. Consulta selección de rama para una visión general completa. (ej:--branch feature-branch
) - Establece la opción
--testbed
al nombre del Testbed. Consulta los documentos de--tested
para más detalles. (ej:--testbed ci-runner
) - Establece la opción
--adapter
al adaptador de arnés de benchmark deseado. Consulta adaptadores de arnés de benchmark para una visión general completa. (ej:--adapter json
) - Activa la bandera
--err
para fallar el comando si se genera una Alerta. Consulta Umbral & Alertas para una visión general completa. (ej:--err
) - Especifica los argumentos del comando de benchmark.
Consulta comando de benchmark para una visión general completa.
(ej:
bencher mock
)
Cada vez que este comando se ejecute en CI,
está comparando los resultados de feature-branch
solo con los resultados más recientes de main
.
🐰 ¡Felicidades! Has aprendido cómo seguir los benchmarks en CI con Bencher! 🎉