Por: Ivanov Cepeda

Algunas de las consultas más comunes con las que me he encontrado trabajando en casos de soporte es, ¿Porqué mi aplicación funciona más lentamente con el paso del tiempo?, ¿Porqué el tiempo de respuesta incrementa considerablemente cuando la carga al servidor web es muy alta? ¿Cómo incrementar el rendimiento de las aplicaciones web sin tener que cambiar el código de mi aplicación?

Muchos de los problemas de este tipo, que he ayudado a resolver, coinciden con la configuración del sitio web y la configuración con la cual fue compilado el código fuente de la aplicación.

Depuración

El problema más común es la mala práctica de NO deshabilitar las opciones de depuración de la aplicación en los ambientes de producción.

Parece ser que estas opciones son consideradas como “inofensivas” en los ambientes de producción. He visto mucha documentación en Technet y en el KB que explican como habilitar la depuración de aplicaciones para detallar los problemas que tiene la aplicación y que simplemente advierten a los administradores de un impacto negativo en el performance al habilitarla (que parece ser subestimado por los administradores), y el problema comienza al no ver problema alguno en mantener esta opción habilitada en un ambiente de producción, o simplemente no darse cuenta que esta opción está habilitada, afectando radicalmente la manera en que IIS funciona.

Por ejemplo en el caso de ASP 3.0, o como algunos llamamos ASP clásico, si esta opción se encuentra habilitada, IIS trabaja en modo “Single Thread” lo que quiere decir que solamente tenemos un thread para procesar las solicitudes en IIS 5.0 y IIS 6.0 cuando podríamos estar procesando las solicitudes en múltiples threads, pero las cosas se pueden poner mal cuando un error aparece dentro de nuestra aplicación y no tenemos un depurador configurado adecuadamente para depurar el error y se puede producir lo que conocemos como un “Hang", como se puede ver en este articulo del KB 312941 PRB: IIS May Hang If You Enable ASP Server-Side Script Debugging .

En el caso de ASP.Net, tener configurado el código para permitir depuración en un ambiente de producción tiene otras implicaciones negativas, como el uso de módulos temporales que ocupan espacio de memoria, pero en general esta opción no debe estar habilitada en un ambiente de producción, y desafortunadamente es la principal causante de los problemas de desempeño que he resuelto.

¿Cómo deshabilito la depuración del código?

Si se trata de ASP 3.0, o como algunos llamamos ASP clásico, basado en scripting, debemos revisar que la opción Enable ASP Server-Side Script debugging se encuentre totalmente deshabilitada, esta opción se encuentra en la página de propiedades del sitio web. Para desactivarla de debe abrir el IIS manager, hacer doble click en el computador que estamos administrando, y hacer click derecho en la carpeta Web Sites para seleccionar Propiedades, en el tab Home Directory encontraremos el botón Configuration que nos llevara a un formulario llamado Application Configuration en este formulario hay un Tab con el nombre Debugging, verifique que la opción Enable ASP Server-Side Script debugging este deshabilitada, si no lo está deshabilítela y haga click en ok. Ahora debe asegurarse que su aplicación Web que se puede encontrar dentro del Default web Site o en otro Web Site tenga esta misma configuración.

Deshabilitar esta opción en aplicaciones Web ASP.Net es diferente y el artículo KB 815157 describe como hacerlo paso a paso

Es muy importante que la depuración este deshabilitada en ambientes de producción, y es la primera opción que los administradores deben revisar cuando detectan problemas de rendimiento en sus aplicaciones para garantizar que estos problemas no sean causados por una mala configuración de la aplicación.

Compresión

Por otra parte parece que no muchas personas conocen una opción disponible desde la versión 5.0 de IIS que permite comprimir las páginas estáticas y de esta manera disminuir dramáticamente la cantidad de información que es enviada al cliente, es una opción que debe ser considerada en sitios web que tienen bastante contenido estático ya que permite incrementar el tiempo de respuesta y la cantidad de solicitudes que puede atender el servidor web al reducir el tamaño de las respuestas y comprimir el contenido estático.

Para habilitar esta opción basta con seguir los pasos que se encuentran en la guía de operaciones de IIS.

Si su sitio o aplicación web, depende más de contenido dinámico que de contenido estático aun puede beneficiarse de la compresión de datos, pero deberá hacerlo de una manera más cuidadosa ya que al tratarse de contenido dinámico necesitara escoger muy bien que contenido debe comprimir, porque esta opción incrementará el uso de CPU por parte de la aplicación para comprimir el contenido que será enviado al cliente, y si su servidor ya se encuentra utilizando una gran cantidad de tiempo de la CPU (más del 60%) en promedio, no obtendrá ninguna mejora en rendimiento.

Optimización

Por último recomiendo revisar la guía de operaciones de IIS 6.0, en particular el capítulo dedicado a Performance tuning  que contiene información más detallada de otros parámetros que podría tener en cuenta para afinar mejor el comportamiento de su aplicación web.