¿Cómo se prueba el rendimiento del código entre versiones de lanzamiento de software?

Question

Estoy desarrollando software en C# /. NET, pero creo que la pregunta también puede hacerse en otros lenguajes de programación. ¿Cómo se prueba el rendimiento de su software entre las versiones de lanzamiento? Déjame elaborar un poco más.

Antes de la versión de producción del software, me gustaría comparar el rendimiento del software para un conjunto de funciones que estaban disponibles en la versión anterior del software. Supongamos que está hablando de un proyecto de biblioteca de software (sin GUI) que da como resultado el lanzamiento de uno o más dll. ¿Cómo se lograría esto? ¿Cuáles son algunas de las mejores prácticas? No puedo cambiar el dll actual con el dll de la versión anterior y ejecutar la misma prueba.

Una forma en que puedo pensar es agregar la misma prueba de rendimiento en la rama principal (que se utiliza para la versión actual) y la rama de versión anterior y luego comparar el rendimiento. Creo que hay algo de dolor involucrado al hacer esto, pero es posible.

Otra forma en que puedo pensar es comenzar con la rama de lanzamiento de prueba, anunciar los nuevos códigos y funciones que se pusieron después de la última versión, y luego ejecutar la prueba. No creo que esto produzca un resultado correcto, sin mencionar que este enfoque es aún más doloroso que el enfoque anterior.

Gracias por otras ideas. Preferiría las respuestas específicas de C# /. NET.

Editar 1: This y this son preguntas un tanto relacionadas.

Answer 1

Tenemos un conjunto de pruebas de rendimiento. Estas son solo pruebas NUnit. Cada prueba configura algunos objetos, inicia un temporizador (el cronómetro funciona bien), realiza la operación que nos interesa (por ejemplo, carga los datos para una determinada pantalla) y luego escribe el tiempo transcurrido en un archivo CSV. (NUnit registra la duración de cada prueba, pero queremos excluir la lógica de configuración, que en algunos casos variará de una prueba a otra, por lo que nuestros propios temporizadores y registros tienen más sentido.)

Ejecutamos estas pruebas de vez en cuando, siempre en el mismo hardware y entorno de red. Importamos los resultados en una base de datos. Entonces es fácil construir gráficos que muestren tendencias o que llamen a grandes cambios porcentuales.

Answer 2

Puede agregar los resultados de la prueba a un archivo de texto controlado por fuente para cada nueva versión. Eso le daría un historial fácilmente accesible del rendimiento de cada versión.

Su idea de ejecutar la prueba de rendimiento contra la bifurcación y el enlace troncal es esencialmente la misma, pero guardar los resultados probablemente le ahorrará el esfuerzo de cambiar su copia de trabajo hacia adelante y hacia atrás.

Answer 3

Si realmente quiere comparar el rendimiento entre las versiones, necesitará algunas pruebas que realicen las mismas funciones en todas las versiones. Las pruebas unitarias a menudo funcionan bien para esto.

Otra cosa más activa que puede hacer es instrumentar su código con el registro basado en umbrales de rendimiento predefinidos. Por ejemplo, cuando ejecuta código en una versión anterior, obtiene una métrica. A continuación, agregue el código de tiempo a su aplicación, de modo que si la misma función demora un cierto tiempo en cualquier momento, registre un mensaje (o difunda un evento que la persona que llama puede registrar opcionalmente). Por supuesto, no desea exagerar esto en la medida en que el código de tiempo podría resultar en una degradación del rendimiento.

Hacemos esto en nuestras aplicaciones con llamadas SQL. Tenemos un umbral para el tiempo máximo que debe tomar una llamada sql única y si hay una llamada SQL sobre el umbral, entonces lo registramos como una advertencia. También hacemos un seguimiento de la cantidad de llamadas sql en una solicitud HTTP determinada con la misma cosa. Su objetivo debe ser reducir los umbrales a lo largo del tiempo.

Puede envolver estas pruebas en las secciones #if para no incluirlas en la producción, pero también puede ser realmente útil tenerlas en producción.

Answer 4

Tenemos una configuración especial que un usuario (o comprobador) puede habilitar. Lo habilitamos, genera un archivo CSV que podemos enviar a Excel y ver el informe de rendimiento.

Informará recuentos individuales de ciertas operaciones y cuánto tiempo tomaron. Excel muestra esto de una manera visual agradable para nosotros.

Todo el código es personalizado, la única desventaja es la sobrecarga del código de seguimiento del rendimiento, sin embargo, lo hemos comparado y prácticamente no es nada. Está muy bien optimizado y muy corto.

La belleza de este enfoque también es que puede obtener buenos comentarios del cliente si experimentan problemas de rendimiento que no puede reproducir.