Cómo realizar un seguimiento de las pruebas de rendimiento

Question

Actualmente estoy realizando pruebas de rendimiento y carga de un sistema complejo de varios niveles que investiga el efecto de diferentes cambios, pero tengo problemas para realizar un seguimiento de todo:

• Hay muchas copias de diferentes ensamblajes
  • Conjuntos liberados originalmente
  • Revisiones publicadas oficialmente
  • Conjuntos que he construido que contienen correcciones adicionales adicionales
  • Conjuntos que he creado que contienen registro de diagnóstico adicional o seguimiento
• Hay muchos parches de base de datos , algunos de los ensamblajes anteriores dependen de ciertos parches de base de datos que se aplican
• Existen muchos niveles de registro diferentes , en diferentes niveles (registro de aplicaciones, estadísticas de rendimiento de la aplicación, perfiles del servidor SQL)
• Hay muchos escenarios diferentes , a veces es útil probar solo 1 escenario, otras veces necesito probar combinaciones de diferentes escenarios.
• La carga se puede dividir en varias máquinas o solo en una sola máquina
• Los datos presentes en la base de datos pueden cambiar , por ejemplo, algunas pruebas pueden realizarse con datos generados y luego con datos tomados de un sistema en vivo.
• Hay una gran cantidad de datos potenciales de rendimiento que se recopilarán después de cada prueba , por ejemplo:
  • Muchos tipos diferentes de registro de aplicaciones específicas
  • trazados del analizador de SQL
  • Registros de eventos
  • DMVs
  • Contadores de Perfmon
• La (s) base (s) de datos tiene varios Gb de tamaño , por lo que, cuando hubiera usado copias de seguridad para volver a un estado anterior, tiendo a aplicar los cambios a cualquier base de datos que esté presente después de la última prueba. para perder rápidamente la pista de las cosas.

Recopilo toda la información que puedo sobre cada prueba que hago (el escenario probado, a qué parches se aplican los datos que se encuentran en la base de datos), pero todavía tengo que repetir pruebas debido a los resultados inconsistentes. Por ejemplo, acabo de hacer una prueba que creía que era un duplicado exacto de una prueba que realicé hace unos meses, sin embargo, con datos actualizados en la base de datos. Sé por un hecho que los nuevos datos deberían causar una degradación del rendimiento, ¡sin embargo, los resultados muestran lo contrario!

Al mismo tiempo, me encuentro dividiendo cantidades desproporcionadas de tiempo grabando todos estos detalles.

Una cosa que consideré fue el uso de secuencias de comandos para automatizar la recopilación de datos de rendimiento, etc ..., pero no estaba seguro de que fuera una buena idea, no solo es tiempo de desarrollar secuencias de comandos en lugar de pruebas, sino de errores en mis secuencias de comandos. podría hacerme perder el rastro de las cosas incluso más rápido.

Estoy buscando algunos consejos / sugerencias sobre cómo administrar mejor el entorno de prueba, en particular, cómo encontrar un equilibrio entre recopilar todo y, de hecho, realizar algunas pruebas con el riesgo de perder algo importante. ?

Answer 1

Hacer un script de la colección de los parámetros de prueba + el entorno es una muy buena idea para verificar. Si está realizando pruebas durante varios días y el proceso de secuencias de comandos tarda un día, es un tiempo bien empleado. Si después de un día lo ve, no terminará pronto, vuelva a evaluar y posiblemente deje de seguir esta dirección.

Pero te debes a ti mismo intentarlo.

Answer 2

Tiendo a estar de acuerdo con @orip, es probable que ahorrarle tiempo al hacer una secuencia de comandos de al menos parte de su carga de trabajo. ¿Podría considerar tomarse un momento para preguntar qué tareas consumen más tiempo en términos de su trabajo y qué tan susceptibles son a la automatización? Los scripts son especialmente buenos para recopilar y resumir datos, mucho mejor que las personas, por lo general. Si los datos de rendimiento requieren mucha interpretación de su parte, puede tener problemas.

Una ventaja de las secuencias de comandos de algunas de estas tareas es que puede verificarlas junto a la fuente / parches / ramas y puede beneficiarse de la estructura organizativa de la complejidad de sus sistemas en lugar de luchar para perseguirlo como lo hace ahora. .

Answer 3

Si puede realizar la prueba solo con unas pocas configuraciones establecidas, el administrador será sencillo. También puede facilitar la instalación de una en varias de las máquinas virtuales, que se pueden volver a implementar rápidamente para proporcionar líneas de base limpias.

Si realmente necesita la complejidad que describe, le recomendaría crear una base de datos simple para que pueda consultar los resultados multivariados que tiene. Tener una columna para cada uno de los factores importantes le permitirá consultar preguntas como "¿qué configuración de prueba tuvo la varianza más baja en la latencia?" y " ¿qué base de datos de prueba permitió el surgimiento de la mayoría de los errores? " ;. Uso sqlite3 (probablemente a través de la envoltura de Python o el complemento de Firefox) para este tipo de colección liviana, porque mantiene los gastos generales de mantenimiento relativamente bajos y le permite evitar perturbar el sistema bajo prueba, incluso si necesita ejecutarlo. la misma caja

La creación de secuencias de comandos de las pruebas las hará más rápidas de ejecutar y permitirá que los resultados se recopilen de una manera ya ordenada, pero parece que su sistema puede ser demasiado complejo para que esto sea fácil de hacer.