sql-server - with - reporting services pdf

Optimización de la exportación de PDF de enormes informes en Sql Reporting Services 2005

Question

En primer lugar, entiendo que es una horrible idea ejecutar informes extremadamente grandes / largos. Soy consciente de que Microsoft tiene una regla empírica que establece que un informe de SSRS no debería tardar más de 30 segundos en ejecutarse. Sin embargo, a veces los informes colosales son un mal preferido debido a fuerzas externas que cumplen con las leyes estatales.

En mi lugar de trabajo, tenemos una aplicación asp.net (2.0) que hemos migrado de Crystal Reports a SSRS. Debido a la gran base de usuarios y los complejos requisitos de UI para informes, tenemos un conjunto de pantallas que acepta parámetros ingresados ​​por el usuario y crea cronogramas para que se ejecuten durante la noche. Dado que la aplicación es compatible con múltiples marcos de informes, no usamos las funciones de programación / instantáneas de SSRS. Todos los informes en el sistema son generados por una aplicación de consola programada que toma los parámetros ingresados ​​por el usuario y genera los informes con las correspondientes soluciones de informes con los que se crearon los informes. En el caso de los informes de SSRS, la aplicación de consola genera los informes de SSRS y los exporta en formato PDF a través de la API del servicio web de SSRS.

Hasta ahora, SSRS ha sido mucho más fácil de tratar que Crystal, con la excepción de un determinado informe de 25,000 páginas que hemos convertido recientemente de informes cristalinos a SSRS. El servidor SSRS es un servidor de 64 bits de 2003 con 32 gigas de ram ejecutando SSRS 2005. Todos nuestros informes más pequeños funcionan fantásticamente, pero estamos teniendo problemas con nuestros informes más grandes como este. Desafortunadamente, parece que no podemos generar el informe anterior a través de la API del servicio web. El siguiente error se produce aproximadamente 30-35 minutos en la generación / exportación:

Mensaje de excepción: la conexión subyacente se cerró: se produjo un error inesperado en una recepción.

La llamada al servicio web es algo que estoy seguro que todos ustedes han visto antes:

data = rs.Render(this.ReportPath, this.ExportFormat, null, deviceInfo,
selectedParameters, null, null, out encoding, out mimeType, out usedParameters,
out warnings, out streamIds);

Lo curioso es que este informe se ejecutará / renderizará / exportará si el informe se ejecuta directamente en el servidor de informes utilizando el administrador de informes. El proceso que produce los datos para el informe se ejecuta durante aproximadamente 5 minutos. El informe se procesa en formato nativo de SSRS en el navegador / visor después de aproximadamente 12 minutos. Exportar a PDF a través del navegador / visor en el administrador de informes toma 55 minutos adicionales. Esto funciona de manera confiable y produce un enorme pdf de 1.03gb.

Estas son algunas de las cosas más obvias que he intentado para que el informe funcione a través de la API del servicio web:

• establezca el valor HttpRuntime ExecutionTimeout en 3 horas en el servidor de informes
• deshabilitado http keep alives en el servidor de informes
• aumentó el tiempo de espera del script en el servidor de informes
• establecer el informe para nunca tiempo de espera en el servidor
• establecer el tiempo de espera del informe a varias horas en la llamada del cliente

De los ajustes que he intentado, me siento bastante cómodo al decir que se han eliminado los problemas de tiempo de espera.

Basado en mi investigación del mensaje de error, creo que la API del servicio web no envía respuestas fragmentadas de forma predeterminada. Esto significa que intenta enviar todos los 1.3gb por cable en una respuesta. En cierto punto, IIS arroja la toalla. Lamentablemente, la API abstrae la configuración del servicio web, por lo que parece que no puedo encontrar la manera de habilitar la agrupación de respuestas.

1. ¿Alguien sabe de todos modos para reducir / optimizar la fase de exportación de PDF y / o el tamaño del PDF sin disminuir el recuento total de páginas?
2. ¿Hay alguna manera de activar la fragmentación de respuesta para SSRS?
3. ¿Alguien más tiene otras teorías sobre por qué esto se ejecuta en el servidor pero no a través de la API?

EDITAR: Después de leer la publicación de Kcrumley comencé a echar un vistazo al tamaño promedio de la página tomando el tamaño del archivo / número de páginas. De manera bastante interesante en informes más pequeños, la matemática se resuelve para que cada página tenga aproximadamente 5K. Curiosamente, cuando el informe aumenta, este "promedio" aumenta. Un informe de 8000 páginas, por ejemplo, promedia más de 40K / página. Muy raro. También agregaré que el número de registros por página está establecido, excepto la última página de cada agrupación, por lo que no es un caso en el que algunas páginas tienen más registros que otras.

Answer 1

1. ¿Alguien sabe de todos modos para reducir / optimizar la fase de exportación de PDF y / o el tamaño del PDF sin disminuir el recuento total de páginas?

Tengo algunas ideas y preguntas:
1. ¿Es este un informe de gráficos pesados? De lo contrario, ¿tiene tablas que comienzan como texto pero que se convierten en un gráfico mediante el representador de PDF de SSRS (verifique si puede seleccionar el texto en el PDF)? 41K por página podría ser más de lo que debería ser, o podría no serlo, dependiendo de qué tan denso sea su informe. Pero hemos tenido casos en los que tuvimos problemas menores con el diseño de un informe, como tener una tabla sangrando en los márgenes de la página, lo que hizo que el procesador de PDF de SSRS "levantara las manos" y convirtiera la tabla como una imagen en lugar de texto . Obviamente, cuantos menos gráficos haya en su informe, menor será el tamaño de su archivo.
2. ¿Hay alguna manera de poder dividir fácilmente el informe en pedazos? Por ejemplo, si se trata de un informe de 10 ubicaciones, donde la Ubicación 1 va seguida de la Ubicación 2, etc., en su informe final, ¿podría ejecutar la porción de Ubicación 1 independientemente de la porción de Ubicación 2, etc.? Si es así, puede unir los 10 subinformes en un PDF final usando PDFSharp después de haberlos recibido todos. Esto lleva a algunas dificultades con la numeración de páginas, pero nada insuperable.

3. ¿Alguien más tiene otras teorías sobre por qué esto se ejecuta en el servidor pero no a través de la API?

Creo que sería el tamaño del informe. No recuerdo todo sobre qué es una configuración de IIS y qué es específico de SSRS, pero podría haber algunas configuraciones generales de IIS (tal vez en Metabase.xml) que tendrían que actualizarse para permitir incluso el paso de esa cantidad de datos.

Podría aislar la pregunta de si la hora es el problema tomando uno de sus informes de trabajo y construyendo en un largo tiempo de espera en sus procedimientos almacenados con WAITFOR (suponiendo SQL Server para su DBMS).

No soluciones, per se, sino ideas. Espero eso ayude.

Answer 2

Obviamente, es un gran informe, de hecho, está más cerca de una base de datos de 1.3 GB que de un informe.

¿Has pensado en encontrar la manera de dividirlo en varias piezas y luego combinarlas? (use una de varias maneras diferentes de combinar archivos PDF que figuran en este sitio).

Answer 3

Redujimos las grandes exportaciones de PDF de SSRS y encontramos 2 culpables principales

1) A menos que las imágenes sean JPG o PNG, tipo de color 3, se expanden a BMP. Ver aquí

2) A menos que configure SSRS para que se comporte de otra manera (no recomendado), SSRS incorporará fuentes o subconjuntos de fuentes en el PDF, a menos que sean una de las 5 fuentes PDF ''estándar'' .

Aunque ninguna de las fuentes estándar (aparte de Symbol, supongo) está instalada en la mayoría de los sistemas operativos de Windows, hemos encontrado que si usas Times New Roman, Courier New, or Arial , se producirá la sustitución de fuentes hacia adelante y hacia atrás. .

La forma más fácil de convertir sus RDL es verlos como XML y buscar y reemplazar las etiquetas de FontFamily .

Si tiene que usar una fuente no estándar, entonces, aún puede minimizar el daño:

• Use las menos fuentes que pueda. Busque en RDL XML para asegurarse de que no haya fuentes redundantes.
• Use fuentes TTF si usa diferentes tamaños de la fuente.
• Intente no mezclar variantes normales, negrita y cursiva de la fuente, de lo contrario se incrustará varias veces.