30

Es sabido por todos que el punto débil de DotNetNuke reside en la velocidad de carga de los Sitios Web, y lo más molesto, ocurre en algunas ocasiones. ¿A qué puede ser debido? ¿Necesito más requisitos de hardware? ¿Más ancho de banda? A continuación encontraremos la respuesta a dichas preguntas.

Caché

Uno de los conceptos que se reestructuraron completamente en la versión 4.x fué la cacheabilidad ASP.NET de la aplicación, es decir, se optimizó al máximo el número de accesos a la base de datos gestionando adecuadamente el caché. Podríamos crear un artículo completo al respecto pero para simplificar el actual simplemente detallaré su configuración. Sólo añadir que dicha configuración influye considerablemente sobre el rendimiento de DNN al influir en el número de accesos a la base de datos así como en el uso de recursos del servidor.

En la Configuración del Host desplegamos las Configuración Avanzada y observamos el apartado Configuración de Rendimiento en el cual disponemos de las opciones de Cacheabilidad.

- Persistencia del Estado de Página. Determina si el estado de la página se almacena en Caché (Memoria). En algunas ocasiones puede mejorar el rendimiento dependiendo del servidor sin embargo recomiendo dejar la opción por defecto, Página, sobretodo si se van a utilizar múltiples Portales.

- Método de Caché de Módulo. Determina dónde serán almacenados los objetos en el caché del módulo si utilizando la memoria o el disco. Como mejor opción de rendimiento utilizar la Memoria, el uso de recursos es mayor pero mejora el rendimiento.

- Configuración de Rendimiento. Esta opción fué la más reestructurada con la nueva versión 4 de DotNetNuke. Establece el nivel de cacheabilidad de la aplicación. Como mejor opción utilizar el Caché Pesado.

- Cacheabilidad Autenticación. Esta opción permite configurar el caché de contenido para los usuarios autenticados. Establecer como Público.

- Configuración de Compresión. Esta opción establece el uso de compresión. Para mejorar el rendimiento utilizar siempre la compresión GZip sin embargo en algunas ocasiones podemos observar un mal funcionamiento por ese motivo siempre realizar una copia de seguridad antes de modificar estas opciones. En el caso de mal funcionamiento en determinadas páginas podemos excluirlas de la compresión indicándolas en Rutas Escluidas en el apartado Configuración Compresión. Mencionar también que al usar un método de Compresión mejor no usar el filtrado de espacios en blanco.

Algunas opciones más de Configuración que podríamos modificar son por ejemplo las relacionados con el almacenamiento del Log del Sitio en el apartado Otras Configuraciones.

Compresión HTTP

Este método consiste en la compresión de datos enviados por el servidor al navegador del usuario el cual descomprime durante la recepción. Por consiguiente el aumento de velocidad reside en reducir la cantidad de datos a enviar por la línea. Aplicar este sistema a DotNetNuke puede realizarse de varias formas ya que en la propia configuración de IIS disponemos de la opción Compresión HTTP en la pestaña Servicios sin embargo, como inconveniente, mencionar que para habilitar dicha opción debemos disponer de permisos de Administrador al servidor para acceso remoto, por consiguiente debe ser un servidor dedicado o VPS (Servidor Virtual). En caso contrario podría solicitar al proveedor la activación de dicha opción sin embargo no todos los proveedores permiten dicha activación.

 Para más información sobre la configuración de IIS6 aquí os dejo este enlace de Microsoft TechNet.

En el IIS7, como es el caso de Windows Vista, disponemos de un icono denominado Compresión en el cual encontramos las mismas opciones que en la pestaña Servicios del IIS6.

Otra forma es la utilización de determinadas librerías las cuales son referenciadas en el archivo web.config sin embargo debía desactivarse antes de realizar una actualización de DotNetnuke a que generaba diversas incidencias.

Log del Sitio

Como ya he mencionado antes, DNN utiliza el Log del sitio el cual puede ser almacenado en la base de datos o en el sistema de archivos. Por defecto está configurado para el almacenamiento en la base de datos lo cual ocasiona el almacenamiento innecesario de información y aumento del a base de datos. En el caso de no querer utilizar ningún seguimiento del sitio es recomendable cada cierto tiempo limpiar las tablas correspondientes. Para ello debemos acceder como Host y en la página SQL ejecutar las siguientes sentencias como script.

 DELETE FROM ScheduleHistory y DELETE FROM SiteLog (y DELETE FROM EventLog si no desea almacenar el seguimiento de eventos).

Si dispones de acceso total, como administrador, al servidor puedes generar un script que se ejecute automáticamente cada x días.

Keep Alive

Sin duda el concepto más importante. "Mantener Viva" una aplicación consiste básicamente en evitar su descarga de memoria generando peticiones cada cierto tiempo. En primer lugar disponemos de la opción KeepAlive en el IIS el cual establecido por defecto a 120 segundos mantiene al usuario utilizado por IIS activo constantemente. En el caso de una aplicación ASP.NET como es DotNetNuke existen diversas formas para evitar el molesto tiempo de carga el cual en algunas ocasiones se demora 10 y hasta 20 segundos.

 Junto con la instalación de DNN disponemos del archivo keepalive.aspx y keepalive.aspx.vb en la raíz. Dichos archivos son los utilizados por módulos y aplicaciones. Teniendo en cuenta que dicho archivo aspx es modificado a su estado inicial al actualizar las versiones de DNN es necesario disponer de un sistema en el cual no debamos estar modificando cada vez. Después de haber indagado mucho, haber probado diversos módulos y aplicaciones, durante este mes he estado utilizando una aplicación muy sencilla denominada SiteUp. Dicha aplicación, gratuita, fué mencionada en los foros oficiales de DotNetNuke y su ubicación no se presenta de forma pública en la web.

 SiteUp consiste en una aplicación que busca una determinada palabra o texto en una URL cada cierto tiempo. El inconveniente reside en que dicha palabra sea eliminada o modificada en la página donde debe ser buscada en cuyo caso deberíamos indicarla de nuevo.

 Si se desea más información será necesario una aplicación más compleja, personalmente recomiendo DNN Keep Alive 2008 Windows Service la cual con la utilización del archivo keepalive.aspx permite disponer de informes detallados sobre la actividad indicando el número de peticiones efectuadas, tiempo para cada URL, etc.

Conclusión

Como podemos observar la configuración de DNN para mejorar su rendimiento es compleja pero posible. Desde el principio debemos tener claro todas las características del alojamiento DotNetNuke, no sólo espacio en disco y tamaño de la BD, ya que ello influirá en el rendimiento.

 Saludos.

Publicado en: Recursos y Tutoriales

Valoraciones

Comentarios

Carles Vázquez
# Carles Vázquez
sábado, 5 de julio de 2008 22:53
Soy nuevo en DNN y uno de los problemas que tenia era precisamente evitar el tiempo de carga de la aplicación, pongo en práctica lo que comentas en el artículo, que por cierto muy bien explicado, Gracias.

Enviar Comentario

Nombre (obligatorio)

Email (obligatorio)

Sitio web

Imagen CAPTCHA
Escriba el código mostrado más arriba: