PDF Render performance with SP1 -- sql server reporting services

sql server reporting services : PDF Render performance with SP1

Jami Bradley
6/25/2004 3:01:00 PM

Hi,

We have been working with some lrge PDF reports (200-400 pages) and have been anxiously awaiting
SP1 because of performance problems we have been having.

Our initial tests show that the performance is better: Given about 3000 records from SQL Server,
we generated a 272 page report.
Pre SP1: 4 minutes 35 seconds
With SP: 2 minutes 5 second.

So it is just over twice as fast. I also noticed that it is consuming less memory (roughly down
from 700MB to 400MB)

We still would like to get the performance much better and I'm looking for help to understand the
process and what we can do. In the past, running this report in MS Access and using ActivePDF took
10-20 seconds to generate the same report. Why is there such a disparity?

The SQL Query is taking 1-2 seconds at most, then all of the time is spent in aspnet_wp - all CPU,
negligible disk I/O. How do you suggest we identify the time spent?

Are there any tricks to making the report more efficient so that the PDF render time is better? Do
you have some favorite performance counters to watch to better isolate this?

We are trying to convert to using RS exclusively for our reports, but this performance may prevent
us from doing so - any help would be appreciated!

Thanks to all,

Jami

Brian Welcker [MSFT]
6/26/2004 12:25:50 AM

In general, the rules around RDL are much more complex than that of Access.
So much of the time may be in processing, not rendering. What is the time
for XML? Also, what type of data regions are you using (list, table,
matrix?).

Nonetheless, we will continue to work on both performance and size for
future releases.

--
Brian Welcker
Group Program Manager
SQL Server Reporting Services

This posting is provided "AS IS" with no warranties, and confers no rights.

[quoted text, click to view]

Jami Bradley
6/28/2004 8:59:32 AM

We timed the XML output and it was just over 2 *seconds*. Our report is a list with sublists.

If you have any tips that may avoid performance issues with our reports, please let us know.

Thanks!

Jami

[quoted text, click to view]

Brian Welcker [MSFT]
6/28/2004 10:43:17 PM

Well, XML is much easier than PDF. One thing that you should probably look
at is converting some of your report to tables instead of lists. Tables can
sometimes be faster to render.

--
Brian Welcker
Group Program Manager
SQL Server Reporting Services

This posting is provided "AS IS" with no warranties, and confers no rights.
[quoted text, click to view]

Jami Bradley
7/6/2004 12:41:50 PM

We have been doing some testing with one of our reports and found a few interesting things. Here
is the basic information on what we did and how it affected the PDF size and PDF render
performance. All of the reports we ran were dominated by PDF render (checked in the execution
log). We were unable to get adequate performance from this report, so we solved this with a
different product, but I hope the information is useful to others.

All of these tests were using Report Manager - the processing time is the time for 'View Report' to
preview in IE, the PDF render time is the time to export to PDF from Report Manager.

A. Baseline Report (original form, desired report format):
10-15 seconds processing, 5:27 in PDF render, 508 pages, 10.6MB

B. Removed grouping and sub-report:
11 seconds processing, 2:10 in PDF render, 508 pages, 10.2MB

C. B with all details line drawing removed, and no logo (now a plain text report):
9 seconds processing, 1:00 in PDF render, 402 pages, 2.6MB

D. C with no line drawing in page header, avoiding overlapping text:
11 seconds processing, 52 in PDF render, 402 pages, 2.01MB

E. D with two fields removed (fairly complex nested iif expressions):
8 seconds processing, 46 in PDF render, 402 pages, 1.92MB

Items C, D, E had slightly different queries which reduced the row count from about 4500 to about
4000. Too bad I saw this late! I retested E with the proper row count to get the following
results:
E2. Corrected where clause to get all the rows:
9 seconds processing, 1:15 in PDF render, 451 pages, 2.16MB

So the conclusions? Grouping is dominating the time to get this report rendered (our grouping
simply puts a header line between groups). Line drawing makes the PDF significantly larger - this
is not too surpising, but other products seem to do this much more efficiently.

Good luck,

Jami

[quoted text, click to view]

Got something to say? Click here to post a reply to this thread.

Don't see what you're looking for? Try a search.

View other messages about sql server reporting services

home · blog · groups

Questions? Comments? Contact the dn