Métricas de rendimiento en rutinas específicas: ¿cuales son las mejores prácticas?

Question

Me gustaría recopilar métricas sobre rutinas específicas de mi código para ver dónde puedo optimizar mejor. Tomemos un ejemplo simple y digamos que tengo una base de datos "Clase" con múltiples "Estudiantes". Digamos que el código actual llama a la base de datos para cada estudiante en lugar de atraparlos todos a la vez en un lote. Me gustaría ver cuánto tarda cada viaje a la base de datos para cada fila de estudiantes.

Esto es en C#, pero creo que se aplica en todas partes. Por lo general, cuando tengo curiosidad sobre el rendimiento de una rutina específica, creo un objeto DateTime antes de ejecutarlo, ejecuto la rutina y luego creo otro objeto DateTime después de la llamada y tomo la diferencia de milisegundos entre los dos para ver cuánto tiempo se ejecuta . Normalmente acabo de mostrar esto en la traza de la página ... así que es un poco lo-fi. ¿Alguna de las mejores prácticas para esto? Pensé en poder poner la aplicación web en algún modo de "diagnóstico" y hacer una escritura detallada/registro de eventos con lo que sea que busque, pero quería ver si la mente de la colmena stackoverflow tiene una mejor idea.

Answer 1

Algunas veces el enfoque que tome le dará una mejor visión del desempeño de su aplicación. Una de las cosas que puedo recomendar es usar System.Diagnostics.Stopwatch en lugar de DateTime, DateTime es preciso solo hasta 16 ms donde Stopwatch es exacto hasta la marca de la CPU.

Pero recomiendo complementarlo con contadores de rendimiento personalizados para la producción y ejecutar la aplicación en Profiler durante el desarrollo.

Answer 2

Uso este método y creo que es muy preciso.

Answer 3

que utiliza este método en ocasiones y parece que es bastante exacta. El problema es que en aplicaciones grandes con una cantidad bastante considerable de registros de depuración, puede ser complicado buscar en los registros esta información. Así que uso herramientas externas (programo en Java principalmente, y uso JProbe) que me permiten ver tiempos promedio y totales para mis métodos, cuánto tiempo se dedica exclusivamente a un método en particular (a diferencia del tiempo acumulado por el método y cualquier método al que llame), así como asignaciones de memoria y recursos.

Estas herramientas pueden ayudarlo a medir el rendimiento de aplicaciones completas, y si está realizando una cantidad significativa de desarrollo en un área donde el rendimiento es importante, puede investigar las herramientas disponibles y aprender a utilizarlas.

Answer 4

Para consultas de bases de datos, tiene dos pequeños problemas. Caché: caché de datos y caché de sentencias.

Si se ejecuta la consulta una vez, se analiza la declaración, preparado, atado y ejecutado. Los datos se obtienen de los archivos en la memoria caché.

Cuando se ejecuta la consulta por segunda vez, se utiliza la memoria caché, y el rendimiento es a menudo mucho, mucho mejor.

¿Cuál es el número de rendimiento "real"? ¿Primero uno o segundo? Algunas personas dicen que el "peor caso" es el número real, y tenemos que optimizar eso. Otros dicen "caso típico" y ejecutan la consulta dos veces, ignorando la primera. Otros dicen "promedio" y corren en 30 oportunidades, promediándolos a todos. Otros dicen "media típica", ejecute las 31 veces y el promedio de los últimos 30.

Sugiero que el "último 30 de 31" es el número DB rendimiento más significativo. No te preocupes por las cosas que no puedes controlar (analizar, preparar, enlazar) veces. Sudor las cosas que puede controlar - estructuras de datos, carga de E/S, índices, etc.

Answer 5

Hay algunos Profilers disponibles pero, francamente, creo que su enfoque es mejor. El enfoque de perfil es excesivo. Tal vez el uso de perfiladores valga la pena si no tienes ni idea de dónde está el cuello de botella. Prefiero pasar un poco de tiempo analizando el problema desde el principio y poniendo unas pocas declaraciones de impresión estratégicas antes que descubrir cómo configurar tu aplicación para el perfilado y luego verter informes gigantescos donde se calcula el tiempo de cada línea de código ejecutable.

Answer 6

Si está trabajando con .NET, te recomiendo la salida a la clase Stopwatch. Los tiempos que regrese de eso serán mucho más precisos que una muestra equivalente usando DateTime.

También recomendaría consultar ANTS Profiler para los escenarios en los que el rendimiento es excepcionalmente importante.

Answer 7

Creo que tiene un buen enfoque. Recomiendo que genere registros "amigables para la máquina" en el (los) archivo (s) de registro para que pueda analizarlos más fácilmente. Algo así como CSV u otros registros delimitados que están consistentemente estructurados.

Answer 8

Vale la pena considerar invertir en un buen perfilador comercial, especialmente si alguna vez espera tener que hacer esto por segunda vez.

El que yo uso, JProfiler, trabaja en el mundo Java y se puede unir a una aplicación ya se encuentra corriendo, por lo que no se requiere una instrumentación especial (al menos con los más recientes JVM).

Construye rápidamente una lista ordenada de puntos de acceso en su código, que muestra los métodos en los que su código está pasando la mayor parte del tiempo. Se filtra de forma bastante inteligente por defecto, y le permite ajustar el filtrado aún más si es necesario, lo que significa que puede ignorar los detalles de las bibliotecas de terceros, mientras selecciona aquellos de sus métodos que están tomando todo el tiempo.

Además, obtiene muchos otros informes útiles sobre lo que está haciendo su código. Pagó el costo de la licencia en el tiempo que guardé la primera vez que la usé; No tuve que agregar muchas declaraciones de registro y construir un mecanismo para analizar el resultado: los desarrolladores del generador de perfiles ya habían hecho todo eso por mí.

No estoy asociado con ej-technologies de ninguna manera que no sea un cliente muy feliz.