Cómo detectar problemas de rendimiento de una aplicación ASP.NET
Muchas de las preguntas que recibimos son referentes al rendimiento de la aplicación. Es un tema un tanto espinoso porque no siempre está claro definir qué es buen rendimiento. Lo primero sería buscar en las especificaciones de la aplicación qué rendimiento es el esperado y en función de lo que está tipificado podemos ver si tenemos o no un buen rendimiento.
Antes de empezar, querría aclarar que si una aplicación tiene un rendimiento que no es el esperado, hay que buscar los culpables en la aplicación, los servicios a los que se conecta y las comunicaciones. El IIS y ASP.NET casi nunca tienen que ver en estos problemas de rendimiento.
Ahora ya estamos preparados para empezar a estudiar el rendimiento de nuestra aplicación. Primero deberíamos saber qué ocurre cuando nuestra aplicación no responde como esperamos, ¿da un timeout?, ¿tarda mucho pero luego da respuesta?, ¿muestra una página en blanco?...
Lo segundo sería observar cómo se comporta la memoria y la CPU.
En el caso de la memoria, es normal que crezca en los momentos de carga, pero si se ve que crece sin control o que no se reduce cuando ha terminado esa pico de trabajo, entonces podemos tener un problema de Memory Leak.
La CPU tiene dos comportamientos opuestos, que el consumo de CPU sea muy alto o que sea muy bajo. El caso más obvio puede ser que la CPU tenga un consumo muy alto, esto puede deberse a muchas causas, como por ejemplo que el Garbage Collector está funcionando.
En el caso de que la CPU tenga un consumo muy bajo, podemos estar ante un Deadlock, que el hilo de ejecución A esté esperando a un dato del hilo B y que el B esté esperando a otro del A. Como ambos se están esperando mutuamente, nunca podrán salir de ese bloqueo y aunque no consuman uso de CPU la aplicación no está dando respuesta.
En este post os comento una forma sencilla de capturar volcados de memoria con DebugDiag utilizando contadores de rendimiento https://blogs.msdn.com/b/desarrolloweb/archive/2012/05/09/debugdiag-contadores-rendimiento.aspx
Para realizar el análisis nos podemos basar en los pasos que comenté en este post todas las conexiones en uso.
Hay dos indicaciones básicas a la hora de ver el informe del DebugDiag.
La primera es que una aplicación en producción no debe estar en modo debug ni tampoco los assemblies deben estar compilados en modo debug. Os dejo este artículo que lo describe ampliamente: https://blogs.msdn.com/b/tess/archive/2006/04/13/575364.aspx
Y el otro concepto es que si en los volcados hemos capturado más de una vez el Garbage Collector podemos tener un problema en el uso de los objetos de .NET. Este artículo explica detalles de su funcionamiento interno: https://blogs.msdn.com/b/daniem/archive/2009/07/09/cosas-que-deberias-saber-sobre-el-garbage-collector-de-net.aspx
Espero que os sirva de ayuda
- José Ortega Gutiérrez