Después de de haber tenido un primer semestre sumamente ocupado, me da gusto poder continuar con mi blog.

La presente guía permite la instalación y configuración del Reporting Services 2005 para mejorar los tiempos de espera que tiene un usuario para un reporte pueda visualizarlo.

Descripción de la solución.

Reporting Services para SQL Server 2005 es hospedado sobre Internet Information Services (IIS). IIS tiene una característica de optimización, el cual da de baja o apaga una aplicación después de un periodo de 20 minutos de inactividad (el valor default). Esta opción es manejada por la propiedad Idle Timeout Metabase.

Este comportamiento causa la sensación al usuario que el reporte que va a consultar toma demasiado tiempo, este tiempo puede variar entre 5 a 20 segundos para que el reporte sea mostrado al usuario. Causando la impresión de que los reportes son lentos.

Para evitar que el servidor de reportes se dé de baja, se realiza una consulta al servidor de reportes de manera periódica para que este nunca quede inactivo, este proceso no consume recursos y es realizado bastante rápido ya que el servidor de reportes se encuentra actualmente en ejecución.

Podemos pensar que simplemente deshabilitando la opción de Idle Timeout del IIS esto quede resuelto, pero es una técnica útil, ya que el proceso de Reporting Services puede ser dado de baja por varios motivos, tal como reiniciar un servidor, reiniciar el IIS, un problema en un reporte, baja memoria RAM, etc.

No me imagino estar pendiente a que el proceso de mis reportes empresariales estén siempre activos, consultando cada hora cruzando los dedos para que ningún ejecutivo se le ocurra en una reunión mostrar los reportes y se muestre este retraso (como lo mencione anteriormente, este tiempo puede llegar hasta los 20 segundos, dependiendo la carga), por esa razón tener una alternativa que este verificando que los reportes estén activos siempre será una alternativa útil para incrementar la satisfacción del cliente.

La solución consiste de asignar correctamente los valores a la propiedad de worker processes en el IIS, y generar un Reporte que únicamente este realizando un ping a la estructura de reportes, cada determinado tiempo para evitar que el proceso de Reporting Services en IIS sea dado de baja, o al sufrir un reinicio de los servicios este proceso se vuelva a levantar.

Créditos

Esta guía está basada principalmente en el artículo de Lukasz Pawlowski [Keeping your report servers awake (or No more waiting for report server to startup)], el cual implementa el reporte aquí utilizado como parte de la solución.

La información de la configuración del worker processes está basado en el artículo de Microsoft [Planning for Scalability and Performance with Reporting Services] sobre rendimiento de Reporting Services en SQL Server 2005

Implementación.

Una vez visto la teoría vamos a la práctica.

Lo primero que vamos a configurar es el atributo de worker processes dentro del IIS.

Abrimos el Internet Information Services, seleccionamos de la carpeta Application Pool la instancia de la aplicación de Reporting Services en este caso ReportServer si la instalación del producto fue la default, y vemos las propiedades (File->Properties).

En la pestaña de Performance, en la sección de Web Garden asignamos el valor de worker processes, se recomienda asignar el valor dependiendo del número de procesadores, si nuestro sistema tiene 2 procesadores worker processes sería a 2, si nuestro servidor tuviera 4 podemos asignar 4 worker processes.

Este valor es muy importante porque mientras más grande sea este dato, tomará más tiempo al Reporting Services inicializar y por lo tanto tomará mucho más tiempo a los reportes cargar y ejecutar, ya que la carga de procesamiento se balancea entre todos los worker processes que asignemos, el abuso de este parámetro afectara sensiblemente el rendimiento de nuestro Reporting Services.

En mi caso como mi servidor ocupa un solo procesador el valor esta en 1.

Configuración del Reporting Services

Enseguida agregamos el reporte que permite estar despierto a nuestro Reporting Services.

El reporte puede ser descargado del enlace del artículo de Lukasz Pawlowski aquí. O al final del artículo se encuentra el archivo.

Entramos a nuestro report server, generalmente por la liga http://localhost/Reports, en esta sección agregamos el archivo ListChildren.rdl, mediante la opción de “Cargar Archivo” para tenerlo publicado.

Una vez publicado el reporte, ejecutamos el reporte para verificar que funcione correctamente, el reporte contiene valores por default que corresponden a los valores default de una instancia de Reporting Services.

Enseguida editar las propiedades del reporte, en caso de que las propiedades de los parámetros por default no cumplan con las propiedades que necesitemos las podemos editar.

Asignar las credenciales con las que el reporte se ejecutará. Estas credenciales son necesarias que sean almacenadas como seguras dentro del mismo reporte, además la cuenta asignada deberá pertenecer al rol de Content Manager de Reporting Services.

Enseguida vamos a programar el reporte para que se ejecute de manera periódica, esta es la clave ya que permitirá comunicarse con el Report Server de manera constante permitiendo que si se reinician los servicios de Reporting Services, el reporte pueda ser cargado lo más rápido. La programación la realizamos en la opción de Suscripciones.

Para las opciones de la suscripción utilice la opción de Recurso compartido de Windows y que no sobrescriba el archivo anterior si existe una nueva versión, esto permite que solo se ejecute en memoria el reporte y solo la primera vez se genera el archivo, para que no consuma recursos en disco, además seleccione el formato CSV por ser el más ligero de los demás formatos. Para la opción de Ruta generé una carpeta compartida en el mismo servidor de Reportes, con privilegios a la cuenta que se definió en las credenciales de ejecución del reporte de ListChildren.

Este último paso lo explico más a detalle.

Se genera una nueva carpeta y posteriormente se comparte esta carpeta.

Se asignan los privilegios al mismo usuario que se utilizo en la cuenta de fuente de datos del reporte ListChildren.

Enseguida se programa que el reporte se ejecutará cada 9 minutos, en mi caso fue un tiempo aceptable pero este tiempo debe variar dependiendo las necesidades de reporteo que se requieran.

Finalmente podemos verificar si el reporte se ha ejecutado correctamente, si en la ruta que compartimos se encuentra el archivo del reporte de ListChildren.

Recursos

Descarga el archivo ListChildren, o desde aquí.

Conclusiones.

No existe una receta única para tener un servidor de reportes eficiente, pero si podemos sacar ventaja de algunas técnicas como las explicadas en este artículo para incrementar la satisfacción de nuestros clientes.