none
Problemas de performance en reporting services 2008 64 bits. RRS feed

  • Pregunta

  • Tenemos un sistema desarrollado en .NET que usando reporting services 2005 de 32 bits, en un servidor Windows 2003 de32 bits, el cual genera 70.000 informes en 24 hs. en formato .pdf. Migramos a reporting services 2008 de 64 en un Windows server 2008 de 64 bits, y los tiempos se nos han triplicado. Y en cuanto al tamaño de los informes, se han multiplicado por 4. Por lo tanto, la performance ha caido extrepitosamente.

    Hicimos una prueba de instalar reporting services 2005 de32 bits en un windows server 2008 de 64, y los tiempos son similares a los originales. Sin embargo, el tamaño practicament se ha duplicado respecto al original. Por lo que suponemos que el problema de performance, pasa por la versión del Reporting Services.

    ¿Existe alguna forma de regular el tamaño de los .pdf que se generan y de mejorar los tiempos de proceso?

    Los reportes que estamos generando son los mismos en los servidores y en las versiones que probamos.

    Gracias y saludos.

    martes, 12 de julio de 2011 18:47

Respuestas

  • Hola,

    Por si sirve de ayuda; hace poco hice un servicio Web en .NET para extraer datos de un informix con el conector Informix Client SDK desde un Windows Server 2008. Las pruebas con ODBC fueron inviables por una gran demora en la obtención de los datos; se cambió la conexión por OLE DB Informix y los resultados fueron favorables.

    La cadena de conexión que utilizo es la siguiente:

    Provider=Ifxoledbc;Data Source=dbName@serverName;User ID=myUsername;Password=myPassword;

    Saludos.

    jueves, 4 de agosto de 2011 11:04
  • Hola a todos.

    Bueno, gracias al aporte de Victor, hemos logrado mejorar los tiempos. Si bien no han sido iguales a los originales, ahora solo se ha incrementado el tiempo en aproximadamente un 25%, lo cual, puede llegar a ser aceptable.

    La solución de la mejora en el tiempo, viene por la utilización del OLEdbc (y no utilizar en la cadena de conexión el tradicional ODBC).

    Ahora vamos a seguir viendo el problema del espacio que ocupa cada PDF generado, que sigue ocupando 4 veces mas que originalmente.

    Si alguno de uds. tiene alguna sugerencia para el tema del espacio, se las agradeceremos.

    Un saludo para todos y gracias.

    ama277

     

    • Marcado como respuesta ama277 martes, 29 de mayo de 2012 17:20
    lunes, 8 de agosto de 2011 19:16
  • Logramos solucionar el problema del espacio que ocupan los pdf's generados por esta version del reporting services.

    En esta nuevo version, en el propio pdf, por defecto, le incrusta las fuentes utilizadas en cada archivo, por lo que crece sustancialmente el tamaño del mismo.

    Se solucionar modificando la configuración, pero afecta a todos los reportes.

    No es una opcion disponible en el momento de la instalacion, sino en la configuracion.

    How do we disable this Font Embedding?

    1. Open the rsReportServer.Config file under the path: <RS Installation Folder>\Reporting
    Services\ReportServer
    2.  Please find

    <Extension
    Name="PDF"
    Type="Microsoft.ReportingServices.Rendering.ImageRenderer.PdfReport,Microsoft.ReportingServices.ImageRendering">

    3. 
    Replace the same with

    <Extension
    Name="PDF"
    Type="Microsoft.ReportingServices.Rendering.ImageRenderer.PdfReport,Microsoft.ReportingServices.ImageRendering">
         
    <Configuration>
                <DeviceInfo>
                     
    <EmbedFonts>None</EmbedFonts>
               
    </DeviceInfo>
          </Configuration>
    </Extension>

    Espero sea útil la respuesta.

    Saludos.

    • Marcado como respuesta ama277 martes, 29 de mayo de 2012 17:20
    martes, 29 de mayo de 2012 17:20

Todas las respuestas

  • Hola,

    ¿Habéis migrado directamente los informes a la nueva plataforma? ¿Habéis probado a generar unos cuantos desde el principio para ver si los tiempos son iguales?

    Un Saludo!


    Fran Díaz | {geeks.ms/blogs/fdiaz/} | {onobanet.com} | {secondnug.com}
    miércoles, 20 de julio de 2011 9:05
    Moderador
  • Estimado Fran.

    Antes que nada, gracias por preocuparte.

    Te comento que si bien migramos los reportes a la nueva plataforma, tambien realizamos algunas pruebas con reportes diseñados de cero en la nueva plataforma (como prueba)  y la demora es la misma.

    Nunca pensamos en tener este comportamiento por cambiar de plataforma.

    Si se te ocurre alguna idea, te lo vamos a agradecer.

    Saludos.

    Ama.

    miércoles, 20 de julio de 2011 18:43
  • Vaya, pues si que es raro, ¿es la mimas máquina? ¿mismas red?

    Un Saludo!


    Fran Díaz | {geeks.ms/blogs/fdiaz/} | {onobanet.com} | {secondnug.com}
    jueves, 21 de julio de 2011 6:20
    Moderador
  • Pues si. Las máquinas son las mismas.

    En un servidor windows 2008 de 64 bits, instalamos tanto el reporting server 2008 de 64 bits como el reporting server 2005 de 32 bits.

    Y es aqui donde la comparación de tiempos es abismal. Lo mismo que respecto a los tamaños de los PDF generados, los cuales son como 4 veces mas de tamaño.

    En el comentario anterior, que hice referencia a cambio de plataforma, es que durante varios años tuvimos el aplicativo sobre Windows 2003 y reporting server 2003 (todo 32 bits). Cambiamos de servidores y llegaron las demoras. Por eso, entre las pruebas que realizamos, esta la que te expresé al principio de la nota de hoy. Sobre el mismo nuevo servidor, realizamos la prueba con las 2 versiones del reporting server.

    Gracias y saludos.

    Ama.

    jueves, 21 de julio de 2011 13:59
  • Hola,

    ¿Y nos os conviene mejor tenerlo en 32 bits? ¿o la memoria que tenéis para dicho servidor es demasiado grande para una versión de 32bits?

    Un Saludo!


    Fran Díaz | {geeks.ms/blogs/fdiaz/} | {onobanet.com} | {secondnug.com}
    jueves, 21 de julio de 2011 18:35
    Moderador
  • Pasamos a 64 bits por diferentes motivos:

    • renovamos el hardware (procesadores  mucho mas potentes con muchas mas memoria).
    • pasamos a windows server 2008 de 64 bits. Todo esto con la expectativa de mejorar los tiempos en todas las aplicaciones.
    • tuvimos problemas con uno de los reportes de otra funcionalidad, al imprimir directamente desde una página web, pues no les imprimia en forma correcta  a todos los usuarios. Esto nos obligó a que ese reporte en cuestión fuera en reporting  server 2008. Y asi de paso, aprovechamso para  migrar todo a una versión mas nueva para no quedarse atrás.

    Saludos

    Ama.

     

    jueves, 21 de julio de 2011 18:59
  • Hola.

    En ese servidor, ¿qué corre además de Reporting Services? ¿Qué versión, service pack de sistema operativo y SQL Server tienes? ¿Pudiste comparar entre la visualización en ambas versiones (sin la exportación a PDF)?

    ¿Has revisado la resolución de los PDF? ¿Y el atributo HumanReadablePDF para ponerlo a false (http://msdn.microsoft.com/es-es/library/ms154682.aspx)?

    En general, pasar a una versión más reciente, con hardware más potente no puede hacer que el rendimiento vaya a peor, pero si has cuadruplicado el tamaño, puede que sea hasta normal que tarde más en generarse cada informe.


    Alberto López Grande
    SQL Server MVP
    Visita mi blog en http://qwalgrande.blogspot.es/ Sígueme en twitter en http://twitter.com/qwalgrande

    jueves, 21 de julio de 2011 21:27
    Moderador
  • - No se corre mas nada que el Reporting Services en ese servidor (Con el motor del SqlServer necesario para la base del propio Reporting Services)
    La version Del sistema Operativo es Windows 2008 Server Standard Service Pack 2 64 bits

    La version del Sql Server es 2008 R2 (V.10.50.1600) 64 bits

    La visualizacion con Reporting service 2008 es mas lenta que con 2005

    He modificado el parametro que me has dicho (por defecto ya es false), lo probe con true y el tamaño se hizo mas grande por archivo (120 kb comparado con 60 kb con el parametro en false y 13kb que ocupaba generado con Reporting Service 2005)

    Un dato que hemos omitido y quizas sea importante es que nuestro servidor de base de datos contra lo que corre el reporting service (tanto este nuevo 2008 como el anterior 2005) no es Sql server sino Informix, por lo que el Reporting service se conecta mediante el driver Odbc de informix; de cualquier manera esto no ha cambiado respecto de el Reporting Service 2005 o dicho sea de otra forma. En una prueba que hicimos instalamos un servidor con Windows 2008 server Standard R2 64 bits (igualito al mencionado arriba) y Sql Server 2005 32 bits y generamos un conjunto de 5000 reportes de prueba lo que demoro 1hs 5 minutos, haciendo lo mismo con el servidor de producción de arriba el mismo reporte sobre el mismo servidor de base de datos (es decir la unica diferencia es el sql server porque todo lo demas es identico maquina todo) demora 2hs 50 minutos. Por otro lado revisando los logs de eventos de ambas maquinas en la base de datos de reporting service (tabla dbo.ExecutionLogStorage) que queda en el sql server surge que la mayor diferencia de tiempos esta en el tiempo de obtención de los datos (TimeDataRetrival) que pasó de 100 y pico a 1000 y pico.-

    ¿Existe alguna diferencia en la forma que Sql server 2008 interacciona con los drivers de informix respecto de Sql server 2005?

    Recalco que ambos estan corriendo contra el mismo servidor de base de datos y con los mismos drivers Odbc, salvo que unos son 32 bits y los otros 64 bits

    Un comentario mas. En lo que te refieres a cuadruplicar el tamaño, es el tamaño del pdf generado por el reporting server. La información, sigue siendo del mismo estilo. No es que nosotros estemos imprimiendo mas. Sino que sobre la misma información, genera los pdf's mas grandes.

    Muchas gracias y saludos.

     

    viernes, 22 de julio de 2011 19:15
  • LLegado a este punto, se me pasa por la cabeza algo, ¿No habéis probado a traer una copia incremental (lo nuevo o modificado) con paquetes SSIS a una BBDD SQL Server para luego extraer en local desde SSRS?

    Un Saludo!


    Fran Díaz | {geeks.ms/blogs/fdiaz/} | {onobanet.com} | {secondnug.com}
    sábado, 23 de julio de 2011 11:06
    Moderador
  • Seguimos realizando diferentes pruebas con los servidores, reinstalando sql server, etc., y siempre vuelve a fallar en la configuración originalmetne expuesta.

    Asi que seguimos sin encontar una solución.

    Saludos.

     

    jueves, 28 de julio de 2011 13:44
  • Bueno

    Mi problema es similar. He actualizado todos los SP, los KB etc.

    Tengo el SQL Server 2008 R2 + SSRS en 64 bits en un Windows Server Enterprise 2008 64bits; en algunos reportes, sobre todo en los que tienen un paginado extenso el TimeProcessing pasó a demorar aproximadamente 7-10 min, las querys fueron optimizadas ejecutándose en 2s.

    He instalado el SSRS 2008 32 bits en una máquina XP y en un servidor W2003 referenciando a la BD(ReportServer) del servidor de W2008 64 bits y funciona perfecto, en 6 s.

    Aún sigo con este problema.

    Saludos

    miércoles, 3 de agosto de 2011 17:04
  • Hola,

    Ya salió el SP1 para el SQL Server 2008 R2, si lo queréis probar....

    http://www.microsoft.com/downloads/es-es/details.aspx?FamilyID=b9aa2dba-7f20-4c0c-9afd-1eebee5a94ea

    Un Saludo!


    Fran Díaz | {geeks.ms/blogs/fdiaz/} | {onobanet.es} | {secondnug.com}
    jueves, 4 de agosto de 2011 7:07
    Moderador
  • Más info de lo que soluciona este SP: http://support.microsoft.com/kb/2528583
    Fran Díaz | {geeks.ms/blogs/fdiaz/} | {onobanet.es} | {secondnug.com}
    jueves, 4 de agosto de 2011 7:08
    Moderador
  • Hola,

    Por si sirve de ayuda; hace poco hice un servicio Web en .NET para extraer datos de un informix con el conector Informix Client SDK desde un Windows Server 2008. Las pruebas con ODBC fueron inviables por una gran demora en la obtención de los datos; se cambió la conexión por OLE DB Informix y los resultados fueron favorables.

    La cadena de conexión que utilizo es la siguiente:

    Provider=Ifxoledbc;Data Source=dbName@serverName;User ID=myUsername;Password=myPassword;

    Saludos.

    jueves, 4 de agosto de 2011 11:04
  • Hola.

    Gracias a todos por el aporte.

    Voy a comenzar a realizar las diferentes pruebas y actualizar las versiones y así ver si tenemos mas suerte.

    Los vamos a mantener informados.

    Saludos.

     

    viernes, 5 de agosto de 2011 20:49
  • Hola a todos.

    Bueno, gracias al aporte de Victor, hemos logrado mejorar los tiempos. Si bien no han sido iguales a los originales, ahora solo se ha incrementado el tiempo en aproximadamente un 25%, lo cual, puede llegar a ser aceptable.

    La solución de la mejora en el tiempo, viene por la utilización del OLEdbc (y no utilizar en la cadena de conexión el tradicional ODBC).

    Ahora vamos a seguir viendo el problema del espacio que ocupa cada PDF generado, que sigue ocupando 4 veces mas que originalmente.

    Si alguno de uds. tiene alguna sugerencia para el tema del espacio, se las agradeceremos.

    Un saludo para todos y gracias.

    ama277

     

    • Marcado como respuesta ama277 martes, 29 de mayo de 2012 17:20
    lunes, 8 de agosto de 2011 19:16
  • Logramos solucionar el problema del espacio que ocupan los pdf's generados por esta version del reporting services.

    En esta nuevo version, en el propio pdf, por defecto, le incrusta las fuentes utilizadas en cada archivo, por lo que crece sustancialmente el tamaño del mismo.

    Se solucionar modificando la configuración, pero afecta a todos los reportes.

    No es una opcion disponible en el momento de la instalacion, sino en la configuracion.

    How do we disable this Font Embedding?

    1. Open the rsReportServer.Config file under the path: <RS Installation Folder>\Reporting
    Services\ReportServer
    2.  Please find

    <Extension
    Name="PDF"
    Type="Microsoft.ReportingServices.Rendering.ImageRenderer.PdfReport,Microsoft.ReportingServices.ImageRendering">

    3. 
    Replace the same with

    <Extension
    Name="PDF"
    Type="Microsoft.ReportingServices.Rendering.ImageRenderer.PdfReport,Microsoft.ReportingServices.ImageRendering">
         
    <Configuration>
                <DeviceInfo>
                     
    <EmbedFonts>None</EmbedFonts>
               
    </DeviceInfo>
          </Configuration>
    </Extension>

    Espero sea útil la respuesta.

    Saludos.

    • Marcado como respuesta ama277 martes, 29 de mayo de 2012 17:20
    martes, 29 de mayo de 2012 17:20