Cómo medir el desempeño de aplicacions ASP.NET
La literatura disponible nos sugiere que para analizar el desempeño de las aplicaciones ASP.NET debemos medir al menos los siguientes parámetros dentro del Performance Monitor:
| Performance object | Performance counter |
| ASP.NET | Application Restarts |
| ASP.NET | Requests Queued |
| ASP.NET | Worker Process Restarts |
| ASP.NET Applications | Errors Total |
| ASP.NET Applications | |
| Processor | % CPU Utilization |
Fuente: Help de Microsoft.Net SDK 1.1, sección:
Ms-help://MS.NETFrameworkSDKv1.1/cpguidenf/html/cpconperformancecountersforaspnet.htm
Application Restarts: indica cuantas veces una aplicación ASP.NET se re inicializa, lo ideal es que este parámetro sea 0 (cero), pues una aplicación sin problemas no debe presentar re inicios, salvo cuando se hagan updates o se instalen nuevas versiones de alguna componente.
Request Queued : Cuantos requerimientos se encuentran encolados esperando una respuesta. Cuando este número empieza a crecer linealmente con respecto a la carga de cliente conectados, entonces el servidor web ha alcanzado el límite de requerimientos concurrentes que puede procesar. El máximo por omisión es de 5.000. Este parámetros se puede cambiar en el archivo Machine.config.
Worker Process Restarts: El número de veces que un proceso trabajando ha sido re iniciado en el servidor. Este número aumenta cuando se producen caidas inesperadas de algún proceso. Este parámetro no debe aumentar bruscamente, de hacerlo debe investigarse las causas de inmediato.
Errors Total: Es el número total de errores que ocurren durante la ejecución de requerimientos http. Incluye errores en el parser, errores de compilación, errores durante el procesamiento y errores de ejecución. Este valor debe ser revisado atentamente.
Requests/Sec: Es la cantidad de request por Segundo atendidos por el servidor web. Este valor representa el throughput real de las aplicaciones en el servidor web. Bajo carga constante este valor debe mantenerse dentro de ciertos rangos.
% CPU Utilization: es el porcentaje de utilización de la CPU, a mayor utilización de la CPU mayor será la contención de las aplicaciones.
Parámetros más finos
Los parámetros descritos anteriormente son relevantes para monitorear aplicaciones, pero cuando se han detectado problemas entonces es bueno fijarse en estos otros parámetros:
| Performance object | Performance counter | |
| ASP.NET Applications | Pipeline Instance Count | |
| .NET CLR Exceptions | # of Exceps Thrown | |
| System | Context Switches/sec |
Pipeline Instance Count: Es el número de instancias de pipelines para la instancia de ASP.NET indicada. Dado que un thread sólo puede correr en 1 pipeline, es mejor que este valor se mantenga bajo, pues este indica el número de request que están siendo atendidos por la aplicación.
# of Excepts Thrown:: Es la cantidad de excepciones generadas. Este valor se puede complementar con el parámetro que indica la cantidad de excepciones por segundo.
# Context Switches/sec: Este parámetro mide la tasa a la cual ocurren cambios de contextos de los threads entre todas las CPUs. Un valor muy alto de este parámetro implica una gran contención debido a locks o muchos cambios entre modo kernel o user en cada thread.
Recomendaciones de Microsoft
El documento ASP.NET Performance Monitoring, and When to Alert Administrators, disponible en línea en la siguiente dirección: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/monitor_perf.asp, nos indica en que fijarse y cómo tomar algunas medidas para evitar el colapso de las aplicaciones. También nos permite encontrar indicadores de que puede estar fallando en nuestras aplicaciones.
El artículo contiene enlaces a varios utilitarios, como snap.exe, que es una herramienta para recolectar datos para medir el desempeño de las aplicaciones.
Otro utilitario disponible es httpClient.exe que permite medir el TTLB (Time to last byte), un parámetro importante para medir la contención y la latencia de las aplicaciones.
Qqq.exe es una aplicación en modo comando de linea que permite stressar aplicaciones.
ErrorHandler.dll, es una dll que permite registrar en la bitácora de eventos (log) las excepciones no manejadas.
Todos estos utilitarios están con códigos fuente, por lo que pueden ser modificados para necesidades específicas.
También en el artículo se describe como con una modificación en el archivo global.asax, podemos registrar en el log la mayoría de las excepciones no manejadas.
E
Otras aplicaciones de depuración que también se mencionan en este artículo son sos.dll, winddbg.exe y cdbg.exe que permiten depurar en un servidor de producción, pudiendo incluso observarse el proceso de recolección de basura. O estudiar el contenido del heap del GC. El uso de estas aplicaciones es importante en este caso para poder detectar cuales son los objetos que llenan el heap y que obligan a realizar tanto garbage collection, como se pudo observar.