Visual Studio 2010 Profiling tools solucionando problemas de performance Parte 2
Escrito por Nestor Guadarrama – Revisado por Ivanov Cepeda
En la primera parte de esta serie de artículos, conversamos sobre lo que la herramienta Microsoft Visual Studio Profiling Tools ofrece a los desarrolladores para los procesos de perfilamiento de código y la evaluación e identificación de problemas relacionados con el rendimiento de las aplicaciones .NET. Además, utilizamos la aplicación de muestra “HRWeb Profiler”, para hacer algunas mediciones iniciales sobre el comportamiento de dicha aplicación.
En este artículo, utilizaremos una nueva sesión de rendimiento para utilizar la técnica de colección de datos de tipo Instrumentation y realizaremos una captura especial de datos para obtener información sobre la carga y tiempo de vida de objetos .NET en memoria denominada .NET Memory Profiling Collection.
SESION DE RENDIMIENTO - INSTRUMENTATION
Como describimos en el artículo anterior, el método Instrumentation inyecta código dentro de los archivos binarios para capturar información sobre los tiempos de ejecución de cada función primaria en el archivo instrumentado y por cada llamada a función realizada por dichas funciones primarias. Además, identifica cuando una función, llama al sistema operativo para operaciones de escritura/lectura como escribir un archivo.
Para poder seleccionar el método Instrumentation en el proceso de perfilamiento, podemos ubicarlo en la sección superior de la ventana Performance Explorer:
Figura 1: Ventana Performance Explorer.
Para esta prueba, utilizaré la misma llamada a la página Benefits.aspx, que utilizamos en el artículo anterior, para comparar el resultado de este reporte y los valores que el mismo toma. Une vez realizada la navegación básica de la aplicación, y haciendo la respectiva llamada a la página Benefits.aspx, Visual Studio 2010 iniciará el proceso de análisis de toda la data recolectada durante la navegación y presentará una venta con el resumen del Instrumentation Profiling Report:
Figura 2: Instrumentation Profiling Report, indicando las secciones
La primera diferencia notoria que nos muestra este reporte versus el reporte emitido mediante la técnica de Sampling, es que este reporte describe las muestras de análisis realizadas por marco de tiempo (en milisegundos):
Figura 3: Sección de información sobre el tiempo que duro la muestra analizada
Otra interesante característica que ofrece esa técnica es que las distintas vistas del reporte, ofrecen la información sobre llamadas a funciones y otros métodos, mostrando la cantidad de tiempo (en milisegundos) específica por llamada:
Figura 4. Vista “Modules” del reporte Instrumentation Profiling Report
También muestra los tiempos invertidos por cada línea de ejecución sobre la cual acceder mediante distintas combinaciones del click derecho del mouse:
Figura 5. Distintas opciones de navegación que consume más tiempo
En esta ocasión, seleccionare “Show Functions Calling <SU FUNCION>”, donde <SU FUNCION> será el nombre de la función que esta tomando mas tiempo o la llamada que Ud. desea consultar. Para el escenario de la aplicación HRWeb Profiler, esta llamada tendrá como nombre “BuidPargraph. Al seleccionar dicha opción, la herramienta nos llevara a una vista denominada “Caller / Callee”. Esta vista presenta el tiempo de las funciones que llaman a <SU FUNCION> y las llamadas realizadas desde <SU FUNCION>:
Figura 6. Vista “Caller / Callee”, con la información de las llamadas realizadas desde/hacia la función analizada
Como se observa en la figura 6, es evidente que la concatenación de cadenas es un problema a resolver de manera inmediata. Utilizando la misma técnica (botón derecho del mouse sobre a función que consume mayor cantidad de tiempo), podemos navegar hasta la llamada específica donde reside el inconveniente de concatenación:
Figura 7. Navegación hacia la opción “Show Function Details”
Figura 8. Detalle de la función HRWeb.Benefits.Page_Load
Otra vista interesante que ofrece el método Instrumentation, es la vista Marks. Esta vista ofrece una visión global de las llamadas realizadas por la aplicación, asociando cada llamada a contadores del sistema (contadores como los visualizados a través de la herramienta Performance Monitor):
Figura 9. Vista Marks, mostrando los valores almacenados de los contadores del sistema para cada llamada.
Estos contadores se agregan por defecto por cada ejecución y pueden ser configurados (agregados, modificados, eliminados) a través de las propiedades del reporte de rendimiento como se muestra en las figuras 10 y 11 respectivamente:
Figura 10. Propiedades del reporte de Performance
Figura 11. Ventana de propiedades del reporte de Performance, mostrando la sección “Windows Counters”
Como pueden inferir, el modelo de ejecución de rendimiento basado en el método Instrumentation, ofrece una amplia gama de opciones para alimentar el reporte con información valiosa para los procesos de depuración de aplicaciones .NET., tomando los tiempos de ejecución específicos que tarda cada llamada ejecutada por la aplicación, lo que permite establecer rápidamente potenciales problemas de rendimiento en llamadas a múltiples componentes y funciones y en diversos niveles de una aplicación.
.NET MEMORY PROFILING COLLECTION
La técnica de recolección de datos .NET Memory Profiling Collection, establece un mecanismo de apoyo para analizar potenciales problemas de rendimiento asociados a carga de objetos en memoria por parte de su aplicación. Esta técnica colecta la siguiente información:
· Tamaño y cantidad de objetos .NET en memoria que fueron cargados por la aplicación
· Ciclo de vida de los objetos creados por la aplicación, incluyendo los objetos que fueron reclamados por el Garbage Collector en sus tres (3) generaciones.
Para colectar información sobre los objetos .NET, se puede utilizar cualquiera de los dos (2) métodos de perfilamiento mencionados (Sampling o Instrumentation). Sin embargo, existe una sutil diferencia entre cada uno:
· Cuando se utiliza el método Sampling, el perfilador realiza un seguimiento de todos los objetos .NET cargados en memoria que fueron creados por las instancias (aplicaciones) iniciadas o anexadas posteriormente al inicio del proceso (attachs).
· Cuando se utiliza el método Instrumentation, el perfilador realiza un seguimiento solamente de los objetos .NET cargados en memoria que fueron generados por los módulos perfilados.
Par activar esta técnica, se debe habilitar en la ventana de propiedades del reporte de Performance:
Figura 12. Ventana de propiedades de la sesión Performance, mostrando la opción .NET memory profiling collection
Al ejecutar nuestra aplicación para realizar el perfilamiento, los cambios en el reporte permiten visualizar los datos obtenidos por el proceso de colección de objetos .NET residentes en memoria:
Figura 13. Reporte de perfilamiento Memory Profiling Report, donde se muestran las funciones que mas están realizando carga de datos en memoria.
Un aspecto interesante del análisis realizado por el perfilador, es la cantidad de trabajo que el procesador y la memoria realizan, para poder crear todas las cadenas necesarias que el proceso HRWeb.Benefits.Page_Load requiere. La vista Object Lifetime nos brinda valiosa información sobre los tipos de objetos creados por la ejecución, en que generación se distribuyeron, cuantos fueron colectados, cuantos sobrevivieron al final de la colección, etc. Esta vista nos ofrece una perspectiva de donde esta trabajando más la aplicación y que llamadas no pueden liberar recursos porque los objetos están anclados (pinned) en memoria:
Figura 14. Vista Object Lifetime, donde se aprecian los contadores del sistema asociados con los objetos .NET cargados en memoria
Al hacer click con el botón derecho del mouse, podemos navegar hasta la vista Allocation, donde el perfilador nos muestra cual es la llamada que esta consumiendo más memoria y recursos del sistema:
Figura 15. Vista Allocation con la selección de las llamadas que consumen más memoria y recursos.
Otra característica resaltante de la ejecución del reporte de perfilamiento, utilizando .NET Memory Profiling Collection, es la sección View Guidance, dado que nos muestra diversos mensajes aclaratorios sobre problemas específicos de rendimiento, basados en las reglas construidas y utilizadas por el perfilador para el análisis de ejecución de la aplicación:
Figura 16. Sección Error List, mostrando diversas advertencias y mensajes relacionados con el perfilamiento de la aplicación. Se hace especial énfasis en el mensaje del alto uso de tiempo del GC para colectar datos en memoria.
Esto es todo por los momentos. En la siguiente entrega, estaremos mostrando otros métodos de perfilamiento (Concurrency, Tier Interaction), así como profundizar en algunas técnicas de análisis para los hilos de ejecución de memoria (threads) sobre la información colectada por el Microsoft Visual Studio Profiling Tools.