ReportViewer.aspx performance from reportserver URL takes significantly longer than the same request from SSRS Report Manager

ReportViewer.aspx performance from reportserver URL takes significantly longer than the same request from SSRS Report Manager by Piquet

Active

Type:	Bug
ID:	698266
Opened:	10/31/2011 7:56:42 PM
Access Restriction:	Public

Workaround(s)

view

User(s) can reproduce this bug

I have a report that includes several row groups on a tablix.

When running this report from Report Manager within Internet Explorer 8.0 the report takes seconds to render to the user (around 7 seconds in one particular test case).

When running this same report with the same parameters within Internet Explorer 8.0 but using the ReportViewer.aspx URL (i.e. via http://server/ReportServer/pages/ReportViewer.aspx?... ) the report takes over 1 minute to render!

We need to be able to call up this report via ReportViewer.aspx because the report call (and relative parameters) are passed to the URL from an application. Currently this performance discrepancy is a showstopper for us.

Details (expand)

English

SQL Server 2008 R2 SP1

Reporting Services

Windows Server 2008 R2 Enterprise (SP1)

US English

Create and deploy a parameterized SSRS report that includes a tablix and many collapsible row groups (our report had 10 row groups that could be expanded / collapsed - in case it is relevant...).

From a client (desktop) PC:
- Run the report by navigating to it in IE using Report Manager (i.e. SSRS native mode).

- Run the report via the ReportViewer control on the report server, specifying the appropriate querystring parameters (e.g. in our test case the URL string looks like: http://ssrsServer/reportserver/pages/ReportViewer.aspx?/MyReport&rs:Command=Render&rc:Parameters=false&MyParameter1=Par1Value&MyParameter2=Par2Value&ExpandAll=True)

In case it is relevant, the parameters for this report include 2 query filter parameters plus a third boolean parameter "ExpandAll" that is used to determine the initial collapse/expand state of the row-groups.

Compare the timings to render the image in IE on the client PC with these two calls.

The Report Manager call completes in significantly less time than the same report request via ReportViewer.aspx - i.e. 7 seconds vs 70 seconds.

This timing discrepancy is consistent across tests.

Further information:
During the 70 second wait for the report to render using ReportViewer.aspx the client desktop PC (dual core CPU) runs iexplore.exe at 50% CPU for almost the entire duration of the request. The call to Report Manager does not exhibit this same behaviour - iexplore.exe CPU usage is minimal.

If &rs:Format=EXCEL is added to the ReportViewer querystring the report renders (in Excel) in around 7 seconds (i.e. is comparable to rendering the report in Excel from Report Manager).

The time taken to deliver the same report in the same (html) format should be comparable whether it be via Report Manager of ReportViewer.aspx.

X64

0 attachments

Posted by Microsoft on 4/12/2013 at 8:46 AM

Thank you for filing this issue. You may try to use the latest version of the Report Viewer Runtime to see if it addresses the issue (http://www.microsoft.com/en-my/download/details.aspx?id=35747). If it does not, and this issue affects a production deployment, please contact Customer Support (again).

Posted by Piquet on 1/22/2012 at 2:23 PM

G'day Microsoft,

FYI the following Tech Support case was raised regarding this issue: MS-Solve Case 111111421327152.

Investigations & testing conducted to date for this Case indicate that the performance issue is client-side (not server) related, and is somehow related to the presence of the Report-Viewer TOOLBAR on the report (the performance degradation does not occur if the toolbar is disabled in reprot Viewer by adding "&rc:toolbar=false" to the URL querystring.

Posted by Microsoft on 1/20/2012 at 2:42 PM

Thank you for the feedback according to our understanding the performance should be identical between the Report Manager and using the Reporting Services.aspx URL. The issues may come from specific environment; may we suggest checking the following:
1.    Please check if the server assemblies’ versions are the same as the version of Report Manager?
2.    Is the browser running in quirks mode for both sites?
3.    It may be a product bug as well, if you would like to provide us the RDL. We can try to look for rendering mitigation.

If none of these things suggest a problem, recommend contacting CSS to help identify the issue in the environment.

Best Regards,
SQL Reporting Services.

Posted by Piquet on 1/22/2012 at 2:30 PM

The performance issue is related to HTML rendering on the client-side. The performance degradation can be avoided by forcing the report to render in (for example) Excel instead of the default HTML, by adding "&rs:Format=Excel" to the Report-Viewer URL querystring.
This requires the client desktop machine to have the necessary software to view the rendered report (e.g. in this case, Excel).

Posted by Piquet on 1/22/2012 at 2:25 PM

If you can live without the Toolbar on your report, the performance degradation can be avoided by adding "&rc:Toolbar=false" to the URL querystring.
Whilst this avoids the performance issue, it also means the user cannot perform any toolbar functions on the rendered report, such as changing parameters, exporting the report, searching within the report, etc.