Optimizing the PDF Export of Huge Reports in Sql Reporting Services 2005

Question

First off I understand that it is a horrible idea to run extremely large/long running reports. I am aware that Microsoft has a rule of thumb stating that a SSRS report shoul

Answer 1

1. Does anyone know of anyway to reduce/optimize the PDF export phase and or the size of the PDF without lowering the total page count?

I have a few ideas and questions:
1. Is this a graphics-heavy report? If not, do you have tables that start out as text but are converted into a graphic by the SSRS PDF renderer (check if you can select the text in the PDF)? 41K per page might be more than it should be, or it might not, depending on how information-dense your report is. But we've had cases where we had minor issues with a report's layout, like having a table bleed into the page's margins, that resulted in the SSRS PDF renderer "throwing up its hands" and rendering the table as an image instead of as text. Obviously, the fewer graphics in your report, the smaller your file size will be.
2. Is there a way that you could easily break the report into pieces? E.g., if it's a 10-location report, where Location 1 is followed by Location 2, etc., on your final report, could you run the Location 1 portion independent of the Location 2 portion, etc.? If so, you could join the 10 sub-reports into one final PDF using PDFSharp after you've received them all. This leads to some difficulties with page numbering, but nothing insurmountable.

3. Does anyone else have any other theories as to why this runs on the server but not through the API?

My guess would be the sheer size of the report. I don't remember everything about what's an IIS setting and what's SSRS-specific, but there might be some overall IIS settings (maybe in Metabase.xml) that you would have to be updated to even allow that much data to pass through.

You could isolate the question of whether the time is the problem by taking one of your working reports and building in a long wait time in your stored procedures with WAITFOR (assuming SQL Server for your DBMS).

Not solutions, per se, but ideas. Hope it helps.

Answer 2

We narrowed down the large PDF exports from SSRS and found 2 main culprits

1) Unless images are JPG or PNG colour type 3, they are expanded to BMP's See here

2) Unless you configure SSRS to behave otherwise (not recommended), then SSRS will embed fonts or font subsets into the PDF, unless they are one of the 5 'standard' PDF fonts.

Although none of the standard fonts (other than Symbol I guess) are installed on most Windows OS's out of the box, we've found that if you use Times New Roman, Courier New, or Arial then forward and reverse font substitution will take place.

The easiest way to convert your RDL's is to view them as XML and search and replace the FontFamily tags.

If you have to use a non standard font, then, you can still minimize the damage:

• Use as few fonts as you can. Search through the RDL XML to make sure there aren't any redundant fonts.
• Use TTF fonts if you use different sizes of the font.
• Try not to mix normal, bold and italic variants of the font, else it will be embedded multiple times.

Answer 3

Obviously, its a huge report, in fact it's closer to a 1.3 GB database, than a report.

Have you thought of finding a way to split it into multiple pieces and then combine them together? (use one of several different ways to combine PDFs listed on this site.)