Optimierung des PDF-Exports von großen Berichten in Sql Reporting Services 2005

Question

Zunächst einmal verstehe ich, dass es eine schreckliche Idee ist, extrem große/lang laufende Berichte zu erstellen. Ich bin mir bewusst, dass Microsoft eine Faustregel hat, die besagt, dass ein SSRS-Bericht nicht länger als 30 Sekunden für die Ausführung benötigen sollte. Manchmal sind jedoch gigantische Berichte ein bevorzugtes Übel aufgrund äußerer Zwänge, wie z. B. die Einhaltung von staatlichen Gesetzen.

An meinem Arbeitsplatz haben wir eine asp.net (2.0) Anwendung, die wir von Crystal Reports zu SSRS migriert haben. Aufgrund der großen Benutzerbasis und der komplexen Anforderungen an die Benutzeroberfläche für die Berichterstattung haben wir eine Reihe von Bildschirmen, die vom Benutzer eingegebene Parameter akzeptieren und Zeitpläne erstellen, die über Nacht ausgeführt werden. Da die Anwendung mehrere Reporting-Frameworks unterstützt, nutzen wir die Scheduling-/Snapshot-Funktionen von SSRS nicht. Alle Berichte im System werden von einer geplanten Konsolenanwendung generiert, die vom Benutzer eingegebene Parameter entgegennimmt und die Berichte mit den entsprechenden Berichtslösungen generiert, mit denen die Berichte erstellt wurden. Im Falle von SSRS-Berichten generiert die Konsolenanwendung die SSRS-Berichte und exportiert sie als PDF-Dateien über die SSRS-Webdienst-API.

Bisher war SSRS viel einfacher zu handhaben als Crystal, mit Ausnahme eines bestimmten 25.000-Seiten-Berichts, den wir kürzlich von Crystal Reports auf SSRS umgestellt haben. Der SSRS-Server ist ein 64-Bit 2003-Server mit 32 Gigabyte Arbeitsspeicher, auf dem SSRS 2005 läuft. Alle unsere kleineren Berichte funktionieren fantastisch, aber wir haben Probleme mit unseren größeren Berichten wie diesem hier. Leider können wir den oben genannten Bericht nicht über die Webdienst-API erstellen. Der folgende Fehler tritt etwa 30-35 Minuten nach der Generierung/Export auf:

Ausnahmemeldung: Die zugrunde liegende Verbindung wurde geschlossen: Bei einem Empfang ist ein unerwarteter Fehler aufgetreten.

Der Aufruf des Webdienstes ist etwas, das Sie sicher alle schon einmal gesehen haben:

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

Das Seltsame ist, dass dieser Bericht ausgeführt/gerendert/exportiert wird, wenn der Bericht direkt auf dem Berichtsserver mit dem Berichtsmanager ausgeführt wird. Der Prozess, der die Daten für den Bericht erzeugt, läuft etwa 5 Minuten lang. Der Bericht wird im nativen SSRS-Format im Browser/Viewer nach etwa 12 Minuten dargestellt. Das Exportieren in das PDF-Format über den Browser/Viewer im Berichtsmanager dauert weitere 55 Minuten. Dies funktioniert zuverlässig und erzeugt eine satte 1,03gb pdf.

Hier sind einige der offensichtlichen Dinge, die ich ausprobiert habe, um den Bericht über die Webdienst-API zum Laufen zu bringen:

• die HttpRuntime ExecutionTimeout festlegen Wert auf 3 Stunden für den Bericht Server
• deaktiviert http keep alives auf dem Berichtsserver
• die Skript-Zeitüberschreitung auf dem Berichtsserver erhöht
• den Bericht so einstellen, dass er auf dem Server nie abläuft
• die Zeitüberschreitung für den Bericht beim Client-Aufruf auf mehrere Stunden einstellen

Nach den Änderungen, die ich ausprobiert habe, kann ich mit ziemlicher Sicherheit sagen, dass alle Zeitüberschreitungsprobleme beseitigt wurden.

Ausgehend von meiner Forschung der Fehlermeldung, glaube ich, dass die Webdienst-API nicht standardmäßig chunked Antworten senden. Dies bedeutet, dass es versucht, alle 1,3 GB über die Leitung in einer Antwort zu senden. An einem bestimmten Punkt wirft der IIS das Handtuch. Leider abstrahiert die API die Webdienstkonfiguration, so dass ich keine Möglichkeit finde, das Chunking von Antworten zu aktivieren.

1. Weiß jemand, wie man die PDF-Exportphase und/oder die Größe der PDF-Datei reduzieren/optimieren kann, ohne die Gesamtseitenzahl zu verringern?
2. Gibt es eine Möglichkeit, das Response Chunking für SSRS zu aktivieren?
3. Hat jemand andere Theorien, warum dies auf dem Server läuft, aber nicht über die API?

EDIT: Nachdem ich den Beitrag von kcrumley gelesen hatte, begann ich, die durchschnittliche Seitengröße anhand der Dateigröße/Seitenzahl zu ermitteln. Interessanterweise ergibt die Rechnung bei kleineren Berichten, dass jede Seite etwa 5K groß ist. Interessanterweise erhöht sich dieser "Durchschnitt", wenn der Bericht größer wird. Bei einem Bericht mit 8000 Seiten beispielsweise liegt der Durchschnitt bei über 40K/Seite. Sehr merkwürdig. Ich möchte noch hinzufügen, dass die Anzahl der Datensätze pro Seite mit Ausnahme der letzten Seite in jeder Gruppierung festgelegt ist, es ist also nicht so, dass einige Seiten mehr Datensätze haben als andere.

Answer 1

Wir haben die großen PDF-Exporte von SSRS eingegrenzt und 2 Hauptverursacher gefunden

1) Sofern es sich nicht um JPG- oder PNG-Farbbilder des Typs 3 handelt, werden sie zu BMP-Bildern erweitert. aquí

2) Wenn Sie SSRS nicht so konfigurieren, dass es sich anders verhält (nicht empfohlen), bettet SSRS Schriftarten oder Untergruppen von Schriftarten in die PDF-Datei ein, es sei denn, sie sind eine der 5 'Standard'-PDF-Schriften .

Obwohl auf den meisten Windows-Betriebssystemen keine der Standard-Schriftarten (außer Symbol, nehme ich an) von Haus aus installiert ist, haben wir festgestellt, dass, wenn Sie die Times New Roman, Courier New, or Arial dann wird die Schrift vorwärts und rückwärts ausgetauscht.

Der einfachste Weg, Ihre RDLs zu konvertieren, ist, sie als XML zu betrachten und die FontFamily Tags.

Wenn Sie eine nicht standardisierte Schriftart verwenden müssen, können Sie den Schaden dennoch minimieren:

• Verwenden Sie so wenige Schriftarten wie möglich. Durchsuchen Sie die RDL-XML, um sicherzustellen, dass es keine überflüssigen Schriftarten gibt.
• Verwenden Sie TTF-Schriften, wenn Sie verschiedene Größen der Schrift verwenden.
• Versuchen Sie nicht, normale, fette und kursive Varianten der Schriftart zu mischen, sonst wird sie mehrfach eingebettet.

Answer 2

1. Weiß jemand, wie man die PDF-Exportphase zu reduzieren/optimieren und/oder die Größe der PDF-Datei zu verringern, ohne ohne die Gesamtseitenzahl zu verringern?

Ich habe ein paar Ideen und Fragen:
1. Handelt es sich um einen grafiklastigen Bericht? Wenn nicht, haben Sie Tabellen, die als Text beginnen, aber vom SSRS-PDF-Renderer in eine Grafik umgewandelt werden (prüfen Sie, ob Sie den Text in der PDF-Datei auswählen können)? 41K pro Seite können mehr sein, als sie sein sollten, oder auch nicht, je nachdem, wie informationsreich Ihr Bericht ist. Aber wir hatten schon Fälle, in denen wir kleinere Probleme mit dem Layout eines Berichts hatten, z. B. eine Tabelle, die in die Seitenränder hineinragte, was dazu führte, dass der SSRS-PDF-Renderer "die Hände über dem Kopf zusammenschlug" und die Tabelle als Bild statt als Text darstellte. Je weniger Grafiken in Ihrem Bericht enthalten sind, desto kleiner ist natürlich auch die Dateigröße.
2. Gibt es eine Möglichkeit, den Bericht einfach in Teile zu zerlegen? Wenn es sich z. B. um einen Bericht mit 10 Standorten handelt, bei dem auf Standort 1 Standort 2 usw. folgt, könnten Sie dann in Ihrem endgültigen Bericht den Teil mit Standort 1 unabhängig von dem Teil mit Standort 2 usw. ausführen? Wenn ja, könnten Sie die 10 Teilberichte zu einer endgültigen PDF-Datei zusammenfügen, indem Sie PDFSharp nachdem Sie sie alle erhalten haben. Dies führt zu einigen Schwierigkeiten bei der Seitennummerierung, aber nichts Unüberwindbares.

3. Hat noch jemand eine andere Theorien, warum dies auf dem Server läuft Server läuft, aber nicht über die API?

Ich vermute, es liegt an der schieren Größe des Berichts. Ich weiß nicht mehr, was eine IIS-Einstellung ist und was SSRS-spezifisch ist, aber es könnte einige allgemeine IIS-Einstellungen geben (vielleicht in Metabase.xml), die Sie aktualisieren müssten, damit so viele Daten überhaupt durchgelassen werden.

Sie könnten die Frage, ob die Zeit das Problem ist, isolieren, indem Sie einen Ihrer Arbeitsberichte nehmen und eine lange Wartezeit in Ihre gespeicherten Prozeduren mit WAITFOR einbauen (vorausgesetzt, SQL Server ist Ihr DBMS).

Das sind keine Lösungen, sondern nur Ideen. Ich hoffe, es hilft.

Answer 3

Es handelt sich natürlich um einen riesigen Bericht, der eher einer 1,3 GB großen Datenbank als einem Bericht entspricht.

Haben Sie schon einmal darüber nachgedacht, eine Möglichkeit zu finden, die Datei in mehrere Teile aufzuteilen und sie dann zu kombinieren? (Verwenden Sie eine der verschiedenen Möglichkeiten, PDFs zu kombinieren, die auf dieser Website aufgeführt sind).