Después de casi ya 2 meses desde mi último post, estoy de vuelta para concluir la serie acerca de las novedades en SQL Server 2008. Recuerden que hasta este momento todo lo escrito aplica a la última versión disponible que es el CTP de Febrero. Como lo comentamos al inicio de esta serie, Reporting Services 2008 es el que más a “sufrido” (para beneficio nuestro) cambios a nivel de su arquitectura, tanto a los procesos y servicios del motor de proceso de los informes como en la herramienta del usuario para crear dichos informes.
Algunos de los principales cambios en la arquitectura son los siguientes:
- Eliminación de dependencia de Internet Information Services (IIS) de la arquitectura: Para muchos DBAs, el tener que instalar un IIS para poder habilitar los servicios de Reporting Services 2005 era toda una complicación, ya que los fantasmas de seguridad siempre han asechado a IIS y por tanto las políticas de TI les previenen que el tener que instalar IIS y SQL Server en la misma caja puede ser un riesgo. Por otro lado para el equipo de desarrollo de producto de SQL Server también fue complicado la inter-operabilidad con el equipo de desarrollo de IIS para planificar temas tan importantes como el manejo de los recursos compartidos como la memoria. Para nosotros como usuarios comunes también teníamos nuestra cuota de complicación. Cuándo tenemos algún reporte o reportes corriendo en SSRS 2005 que tiene pobre desempeño, es bastante complicado tratar de determinar en cuál de las capas está el cuello de botella: ¿será a nivel de la metadata en SQL?, ¿será el problema con los WebServices de SSRS?, ¿será el problema con IIS?, ¿será el problema con ASP .NET?, etc. ¿Qué indicadores (performance counters) puedo usar para monitorear el desempeño de mi SSRS: SQL, SSRS, IIS, ASP.NET??? (y cada uno tiene una decena de indicadores o más). Obviamente como ya habrán podido notar (o tal vez no), SSRS funciona muy bien para reportes relativamente cortos, pero se vuelve un problema para reportes más largos o extensos.
Bueno al final del túnel siempre hay una luz, y en este caso la luz le llegó al equipo de desarrollo de SSRS removiendo la dependencia con IIS. Los principales beneficios de esta estrategia son:
a) Configuración más fácil: nos evitamos los posibles conflictos con otras aplicaciones instaladas en IIS: Sharepoint, Proclarity PAS, etc.
b) Mejor administración de recursos: Ahora el equipo de SSRS tiene el control completo y por tanto puede controlar mejor el uso de los recursos como la memoria. Por ejemplo uno de las limitaciones que se tenía desde el inicio era que IIS había sido diseñado para presentar páginas estáticas o dinámicas de HTML pero no para la ejecución de reportes extensos como los que podemos tener en SSRS.
En SSRS 2008 se ha implementado un HTTP Listener que usa el módulo HTTP.SYS directamente del sistema operativo (y se evita así toda la plomería de IIS), aceptando directamente todas las peticiones que se hagan en el URL y puerto pre-establecido en la configuración de SSRS. Las tareas de autenticación también están bajo el HTTP Listener de SSRS trabajando con los mismos mecanismos que brinda IIS (Windows, Basic y Anónima).
- Reservas de URL: El cambio anterior implica que ahora debemos decirle también a la configuración de SSRS dónde queremos que “escuche” las peticiones (URL Reservations), que pueden ser más de una para la misma aplicación (Report Manager, ReportServer).
Las opciones son:
Tipo | Ejemplo | Resultado |
Todas | http://+:80/reports | Todas las llamadas al directorio virtual Reports en el puerto 80 |
Específica | http://adventureworks.com:80/reports | Llamada específica al directorio virtual Reports en el puerto 80 de adventureworks.com |
Todas las NO asignadas | http://*:80/reports | Las llamadas no manejadas por otras aplicaciones en el puerto 80 para el directorio virtual Reports |
Figura 1. Pantalla para la configuración del Web Service URL
Figura 2. Creación de un "EndPoint" adicional para el Web Service URL
Figura 3. Ahora nuestro SSRS está listo para atender solicitudes en los 2 URL configurados
- Cambios al Motor de Reportes (Report Engine): El mecanismo de procesamiento sobre demanda de los reportes (o sea cuando el usuario inicia llamada), ha sido mejorado para minimizar los tiempos de repuesta. En la versión 2005 si teníamos un reporte bastante grande e intentábamos mostrarlo, podríamos esperar probablemente varios minutos antes de poder ver la primera página del mismo, ya que el mecanismo de procesamiento hacía su trabajo para TODAS las páginas del informe (que podían ser 100, 1000 ó 10000) a pesar que el usuario tal vez quería ver sólo la primera o alguna de ellas. Con las mejoras en el Report Engine el tiempo de respuesta de cada una de las páginas se ha optimizado y busca ser constante en cada una. Además está preparado para escalabilidad. Si tenemos muchos usuarios viendo distintos reportes a la vez, el Report Engine ya no va a procesar TODAS las páginas y ponerlas en memoria, sino lo hará según sean requeridas.
La arquitectura del rendering ha sido totalmente re-escrita. En 2005 existía una extensión individual para cada tipo por ejemplo Excel y HTML. En la versión 2008 se encapsulado todos los procesos comunes del rendering para que luego cada una de las extensiones consuma sus datos de una manera estándar sin tener que repetir trabajo. Probablemente este cambio en las extensiones de rendering no sean percibidas por el usuario final, pero para el equipo de producto significó la posibilidad de estandarizar esa parte del código de SSRS y posibilitar la escritura de nuevas extensiones con menos esfuerzo.
Con la versión 2008 también se incluye la extensión de rendering para Microsoft Word y la de Microsoft Excel ha sido mejorada. Ambas extensiones son para la versión 97-2003 y no de la nueva versión (2007). Es bastante probable que las extensiones para Word y Excel 2007 se incluyan como un Technical Refresh después que la versión RTM salga al mercado. - Políticas para Administración de Memoria: Con el propósito de asegurar el funcionamiento correcto de SSRS bajo alta demanda, se han implementado políticas para el manejo de la memoria. En este caso el componente Memory Broker de SSRS es el encargado de monitorear el uso de la memoria y de disparar eventos que cambien las funciones de SSRS según el escenario de uso de memoria que esté ocurriendo.
La tabla siguiente muestra los 3 estados que SSRS identifica con respecto al uso de memoria y las funciones o comportamiento que tomará de acuerdo al estado:Estado
Comportamiento
Low Memory Preasure (bajo uso de memoria)
* Solicitudes actuales continúan
* Nuevas solicitudes se aceptan
* Procesamiento “background” de baja prioridad
Medium Memory Preasure (uso de memoria intermedia)
* Solicitudes actuales continúan
* Nuevas solicitudes podrían ser aceptadas
* Se reducen las asignaciones de memoria para todas las aplicaciones
* Reducción sustancial del procesamiento en “background”
High Memory Preasure (uso de memoria alta)
* Solicitudes actuales lentas
* Nuevas solicitudes se rechazan
* Se reducen aun más las asignaciones de memoria
* Uso de memoria virtual (memory swap)
Para controlar estos 3 estados de la memoria el archivo de configuración del ReportServer contiene las siguientes variables: WorkingSetMaximum, MemoryThreshold, MemorySafetyMargin and WorkingSetMinimum. Para más detalles sobre el manejo de memoria y la configuración de estas variables referirse a los Books On Line (BOL).
- Cambios en la herramienta de configuración - Configuration Manager: El primer cambio que van a notar aquí es que ya no tenemos los colores verde, amarillo y rojo que más que ayudarnos en la configuración hacían confundir al usuario. Las pantallas de configuración ha sufrido algunos cambios y ahora muestra un workflow más intuitivo para el usuario.
Figura 4: La nueva versión del Reporting Services Configuration Manager
sin los colores de estatus
Figura 5: Conexión a SSRS 2005 desde el Management Studio
Figura 6: Conexión a SSRS 2008 desde el Management Studio.
Noten que ya no está el folder Home y ahora está el folder Jobs.
Esto es todo por esta entrega, hasta la próxima.
Alan