El rendimiento y la resiliencia del software (resiliencia) son componentes clave de la experiencia del usuario, pero a medida que la industria del software adopta DevOps, comienza a quedarse corto en términos de rendimiento y resiliencia. Los problemas de rendimiento a menudo se pasan por alto hasta que el software falla por completo.
Sin embargo, todos sabemos que el rendimiento no se degrada repentinamente. A medida que el software se lanza a través de iteraciones, existe un costo de rendimiento cada vez que se agrega más código, así como un ciclo adicional de lógica donde las cosas pueden fallar, lo que afecta la estabilidad general.
Pocos problemas de rendimiento o usabilidad del software paralizantes surgen debido a un solo cambio de código. En cambio, suele morir con mil cortes. Mejorar el rendimiento y la resiliencia a través de prácticas rigurosas y probar continuamente estos aspectos es una excelente manera de solucionar los problemas antes de que comiencen. Al igual que con muchos aspectos de las pruebas, la calidad de las prácticas de desempeño es mucho más importante que la cantidad de pruebas que se realizan.
Aquí hay siete consejos simples para impulsar prácticas de ingeniería de rendimiento y resiliencia eficientes
1. Use puntos de referencia para cambiar solo una variable a la vez
En ingeniería de desempeño y resiliencia, un punto de referencia es una pregunta o prueba estandarizada que sirve como base para la evaluación o comparación. Definimos tales pruebas para que podamos compararlas entre sí. A modo de comparación, cambiamos un elemento y medimos el efecto de ese cambio en otra prueba.
Durante nuestro proceso de integración continua, comparamos nuevas versiones de nuestro software para medir cómo los cambios en el código afectan el rendimiento y la resistencia de nuestro software. Entre otros puntos de referencia, queremos medir el rendimiento de nuestro software en hardware de diferentes tamaños. Dado que también admitimos múltiples arquitecturas, plataformas, sistemas operativos, bases de datos y sistemas de archivos, queríamos poder no solo definir cómo obtener el mejor rendimiento y confiabilidad, sino también compararlos entre sí.
Estas son prácticas válidas de evaluación comparativa cuando cambiamos un elemento y medimos el impacto de ese cambio. Sin embargo, si tuviéramos que cambiar la versión del software bajo prueba y el hardware que probamos al mismo tiempo, y luego intentáramos comparar los resultados, no podríamos concluir que cualquier cambio que observamos se debió a un cambio en uno, o el otro, o una combinación de ambos; por lo general, los cambios Una combinación de tendrá un efecto diferente que si ocurren solos.
En ingeniería de rendimiento, intente hacer comparaciones de "manzanas con manzanas", use puntos de referencia y cambie solo una variable en las múltiples versiones de prueba que desea comparar.
2. Supervise el uso de la memoria, la CPU, el disco y la red
Dado que la ingeniería de rendimiento y resiliencia es un esfuerzo científico, solo se puede lograr tratando de explicar objetivamente los eventos que observamos de manera repetible. Esto significa que tenemos que medir.
Para la ingeniería de rendimiento, medimos no solo el software que estamos probando, sino también el hardware en el que lo estamos probando. Supervisar el uso de la memoria, la CPU, el disco y la red es clave para nuestro análisis. También debemos comprender cómo se asignan estos recursos en relación con nuestras necesidades de procesamiento.
En tecnología de la información, siempre estamos transfiriendo datos de un punto a otro y transformándolos. En el proceso, agregamos redundancia; parte de la redundancia es desperdicio o sobrecarga, y parte es necesaria porque nos permite garantizar la integridad y seguridad de los datos. La ingeniería de rendimiento consiste en eliminar los gastos generales y aumentar la integridad de los datos.
3. Ejecute cada prueba al menos tres veces
Antes de comparar los resultados de las pruebas, debemos asegurarnos de que los números que queremos comparar sean confiables. Cada vez que ejecutamos una prueba, esperamos que si ejecutamos la misma prueba en las mismas condiciones en diferentes momentos, obtengamos los mismos resultados y métricas.
Pero cuando ejecutamos la prueba por primera vez, no teníamos el historial de pruebas bajo las nuevas condiciones para decidir si nuestros resultados eran repetibles. Tenga en cuenta que las pruebas anteriores con un componente diferente no pueden permitir la repetibilidad de los resultados; solo realizar la misma prueba varias veces nos dará confianza en los resultados.
Los resultados en los que podemos confiar son factores clave, por lo que le recomiendo que no considere los resultados de las pruebas de comparación de rendimiento a menos que las haya realizado al menos tres veces. Cinco o mejores pruebas de seguro. Para lanzamientos a clientes o lanzamientos de disponibilidad general, se necesita hacer más.
4. Lograr menos del 3% de variación en los resultados
Continuando con el tema de los resultados, tenemos que probar que la misma prueba repetida en diferentes momentos debería producir el mismo resultado. Una métrica clave es la varianza (también conocida como variabilidad) de la métrica principal. La varianza es una medida que representa la diferencia porcentual entre el mejor y el peor desempeño de la misma prueba.
Consideremos una prueba de rendimiento donde la métrica principal es la medición del rendimiento en las transacciones. Si nuestra prueba tuviera el peor rendimiento de ejecución de 100 transacciones por segundo y el mejor rendimiento de ejecución de 110 transacciones por segundo, nuestra diferencia sería del 10 %:
Varianza = (valor mayor – valor menor) / valor menor
(110 - 100) / 100 = 0,1
Del mismo modo, para una prueba de resiliencia, donde la métrica principal es el tiempo de recuperación en segundos, si nuestra prueba tuviera un peor tiempo de recuperación de 5 minutos y un mejor tiempo de 4 minutos, nuestra variación sería del 25 %.
La varianza es una medida clave de la credibilidad de nuestros resultados. Una variación de menos del 3% significa que nuestros resultados son confiables. Una variación entre el 3 % y el 5 % significa que los resultados son aceptables y reproducibles, pero aún hay margen de mejora en términos de pruebas, el entorno o la estabilidad del software de prueba. Una variación entre el 6 % y el 10 % significa que no podemos replicar nuestros resultados y debemos investigar activamente por qué tenemos una variación tan alta. Cualquier prueba con una variación superior al 10 % no se puede utilizar por consideraciones de rendimiento.
5. Ejecute una prueba de carga durante al menos media hora.
Las pruebas de carga generalmente están diseñadas para medir la capacidad de un sistema para un propósito específico. El objetivo es que el sistema maneje la mayor carga de trabajo en el menor tiempo posible sin fallas. Para que las mediciones de estas pruebas realmente tengan alguna base, en mi opinión, una prueba de rendimiento debe durar al menos 30 minutos.
Cuando lo piensa, lo único que está demostrando con una prueba de carga de 15 minutos es que el sistema puede manejar la carga durante quince minutos. Además, cuanto más corta sea la carrera, más se verá afectada por la variación humana.
En ingeniería de rendimiento, también necesitamos un período de calentamiento, porque la primera ejecución siempre es más lenta la primera vez que se ejecuta. Incluso en un sistema precalentado, las primeras transacciones probadas pueden ser más lentas y no necesariamente iguales entre ejecuciones, por lo que habrá diferencias artificiales. Estos no aparecerán en pruebas de 30 minutos o más y es mucho menos probable que induzcan diferencias.
Si la duración de la prueba de carga es inferior a 30 minutos, los resultados no serán muy significativos desde el punto de vista de la ingeniería de rendimiento. La prueba es de al menos media hora excluyendo cualquier período de calentamiento.
6. Demuestra que tus resultados de carga duran al menos dos horas
Recomiendo nuevamente al menos media hora. Como se indicó anteriormente, solo una prueba de carga de 30 minutos demuestra que el sistema puede soportar la carga durante 30 minutos. Si bien 30 minutos serán suficientes para detectar la mayoría de los nuevos cambios de rendimiento, para que estas pruebas sean legítimas, también debe poder demostrar que se pueden ejecutar con la misma carga durante al menos dos horas.
Las cargas máximas deben ser sostenibles indefinidamente si no hay espacio para agotarse. Demostrar que la carga puede funcionar durante dos horas es un buen comienzo. Recomiendo apuntar a 6, 12 y 24 horas como hitos y, cuando sea posible, demostrar 5 días de operación continua bajo estas cargas.
Tenga en cuenta que estas pruebas de durabilidad de la carga están diseñadas para demostrar la sostenibilidad de los resultados de la carga. No es necesario ejecutarlos para cada cambio de código, solo para demostrar la sostenibilidad de los números de carga.
Comience demostrando que dos horas son sostenibles. Cualquier número menor de contenido y rendimiento no debe usarse para lanzamientos de rendimiento, y definitivamente no por razones de capacidad.
7. Asegure una buena automatización
No puede tener una ingeniería de desempeño exitosa sin una buena automatización. ¿Pasa más tiempo analizando los resultados de las pruebas (buena automatización) o ejecutando pruebas y mejorando la automatización existente (menos automatización)?
Si cree que puede mejorar sus prácticas de automatización, comience con estos siete principios:
- Conozca sus razones para automatizar
- Conozca los pasos para automatizar
- No pienses solo en el camino feliz o el camino infeliz
- Los bloques de construcción se pueden apilar uno encima del otro
- Planifique la automatización con anticipación
- Configurar la escena de automatización
- Recopile métricas de la automatización
Diseñe sus pruebas para obtener resultados significativos
La forma más eficaz de abordar el rendimiento y la resiliencia del software es a través de pruebas efectivas. Pero repensar y reestructurar sus pruebas no tiene por qué ser complicado. Si sigue estos siete sencillos consejos, detectará muchos problemas de rendimiento a tiempo, antes de que se conviertan en problemas reales.
Caso práctico
La teoría óptica no sirve de nada, hay que aprender a seguirla, y hay que hacerlo uno mismo, para poder aplicar lo aprendido a la práctica, en este momento se puede aprender de algunos casos prácticos.
Si te es útil, dale me gusta y recógelo para alentar al autor. También es conveniente que lo encuentre rápidamente la próxima vez.
Si no lo entiende, consulte la pequeña tarjeta a continuación. El blogger también espera aprender y progresar con evaluadores de ideas afines.
A la edad adecuada, elija la posición correcta e intente aprovechar al máximo sus propias ventajas.
Mi camino de desarrollo de pruebas automatizadas es inseparable del plan de cada etapa del camino, porque me gusta planificar y resumir,
¡Pruebe y desarrolle tutoriales en video, notas de estudio y portales de recepción! ! !