por Ivanov Cepeda

En todo el tiempo que llevo ayudando a clientes premier, he encontrado que los casos que más frecuentemente se presentan, y que cuesta más trabajo identificar, están relacionados con rendimiento (performance) en las aplicaciones web, en algunas ocasiones debido a configuraciones que causan problemas, pero la mayoría de las veces los problemas se deben al código de las aplicaciones.

En este post quiero hacer un corto checklist que pueda servir de guía para revisar problemas comunes de configuración que afectan el performance, y las acciones a tomar para empezar a obtener un diagnóstico que ayude a encontrar la raíz del problema.

 

Revisar que la aplicación no tenga configuraciones que afecten el rendimiento:

a. Verificar que la aplicación no está configurada en modo de depuración como lo explique en un blog anteriormente.

b. Cuando se trata de una aplicación Web basada en le framework 1.1 verificar que la configuración de la aplicación tiene las configuraciones adecuadas según el hardware que se está utilizando, el KB 811268 ha sido de gran utilidad para muchos clientes que han tenido problemas de performance relacionados con la configuración de .Net 1.1, afortunadamente estos parámetros son afinados automáticamente en la versión 2.0 del framework y en las versiones posteriores.

c. Verificar que todos los módulos de la aplicación están compilados en modo Release.

 

Si ya estamos seguros que la configuración de nuestra aplicación es la adecuada para un ambiente de producción y continuamos teniendo problemas de rendimiento, es hora de empezar a medir el rendimiento del servidor y de nuestra aplicación con contadores de performance que nos indiquen posibles causas comunes de performance.

a. Para aplicaciones ASP clásicas:

i. Es indispensable revisar los siguientes contadores detenidamente por un espacio de tiempo adecuado que incluya la hora en la que se presenta el problema de rendimiento. Si existe algún indicador que indique algún problema relacionado con el hardware (CPU, Memoria, Disco) es momento de revisar la capacidad del servidor, quizá ya llego a su límite y esta sea la causa.

ii. Si la capacidad del Hardware no es el problema y los contadores ASP/Request Wait Time(milisegundos que espero el ultimo request en el queue) y ASP/Request Queued (cantidad de requests en el queue) son muy altos (más de 10000 milisegundos de espera en el queue, o un queue de más de 300 Requests) se podría llegar a afinar la configuración para mejorar el rendimiento siguiendo el KB 238583, sin embargo es hora de empezar a revisar que tan óptimo es el código para la carga que tiene la aplicación y para ello se puede hacer uso de los 25 tips de ASP para mejorar el rendimiento y el estilo.

b. Para aplicaciones ASP.Net:

i. Es indispensable revisar los siguientes contadores detenidamente por un espacio de tiempo adecuado que incluya la hora en la que se presenta el problema de rendimiento. Si existe algún indicador que indique algún problema relacionado con el hardware (CPU, Memoria, Disco) es momento de revisar la capacidad del servidor, quizá ya llego a su límite y esta sea la causa.

ii. Si tiene problemas relacionados con el GC por favor adicione el contador .Net CLR Memory/# Induced GC, algunos desarrolladores utilizan el método GC.Collect para forzar una recolección de memoria al GC, si esto ocurre muy frecuentemente causa problemas de rendimiento graves en la aplicación debido a que los threads deben detener su ejecución cuando el garbage collector se está ejecutando, este contador debe tener en lo posible un valor de 0 si no es así debe tratar de eliminar del código los llamados a la función GC.Collect, sobre todo en las funciones más utilizadas en la aplicación.

 

Si ya ha identificado los contadores que identifican el problema, pero ningún cambio en la configuración le ayuda a resolver el inconveniente, y no se trata de un problema de capacidad del hardware es tiempo de concentrarse en la fuente más común de los problemas de performance: el código de la aplicación.

Las herramientas que le pueden ayudar a verificar cualquier problema en el código que degrada el rendimiento son variadas y en muchos casos muy complejas, por lo que necesitara la ayuda de especialistas y toda la colaboración de los desarrolladores del sistema.

La falta de instrumentación en las aplicaciones hace muy difícil el poder medir los tiempos de respuesta de las aplicaciones por lo que se requiere de herramientas intrusivas como depuradores o perfiladores de código para poder realizar un diagnóstico de las causas del problema.

La acción mas sencilla a seguir es la de recolectar dumps de memoria en los momentos en que el problema es más grave, de ser posible recolectar 3 o 4 dumps del proceso en donde se ejecuta la aplicación en un espacio de tiempo corto (2 a 3 minutos). Si su aplicación es ASP clásico puede utilizar DebugDiag tanto para colectar dumps como para hacer un análisis de los mismos, sin embargo para poder revisar detalladamente el proceso deberá hacer uso de un depurador que le permita ver en detalle lo que está sucediendo en el proceso, como Windbg, para un análisis detallado puede acudir a los ingenieros de Soporte en Microsoft quienes estaremos gustosos de ayudarle en la identificación del problema.