• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 4519
  • Last Modified:

Slow performance with SSRS ReportViewer control in WinForms application

I have a Windows Forms application that uses SQL Server 2005 Reporting Services and displays the reports in the application using the ReportViewer control. I'm having a significant performance problem. There seems to be a large performance cost to using the ReportViewer control. A report that displays in 30 seconds when run by navigating through the reports directory using IE takes 4 minutes when displayed using the ReportViewer control. Is there some way that I can cause the ReportViewer control to speed up its processing or at least to display the first page of the report as soon as it is available? This app is a port from an Access database and the Access reporting performance is so much better that I'm having customer satisfaction issues. Thanks.
1 Solution
I'm having the same performance issues with the Report Viewer for ASP.NET... any more info out there?
Just a question:
1. Did you tried to keep the report creation on the server (ProcessingMode=Remote)? This might be a reason because when you make it local all the source dataset is sent locally (reproduced from DB into a local DS), then the report is processed, and that may take quite a while, especially when the cusomer doesn't have a large bandwidth to communicate with the server.
It's weird that IE responds faster that the windows app, they should be comparable. For IE the report is produced on the server, than is parsed into and HTML, the process is pretty the same for Reporting.WinForms.ReportViewer
2. If your problem persists it might be something about your reports, there are some tricks there too. Instead of drilldowns (if any) you shoud create subreports, that will not grab the whole data (if your view is at group level as for drilldowns) but just the data you need. Some other trick is to pre-prepare the reports - if they are predictable (i.e. the passed month invoices) - and just show them when asked, not produce them each time.
3. Another issue may be the authentification/authorization for the reports of the client that ask for them. The process of authentication/authorization to access a resource (report) may add a certain ammount of time. Try initially to take off all the auth's and see what's happening. If there's the extra time try to find some faster way of auth's.
Paracom_IncAuthor Commented:
Thanks for the suggestions.
The reports are being processed remotely not locally, so that's not the issue. There is no drill down for the reports in question. And there is no special authentication/authorization in play either. The one shared feature of each of the slow reports is that they have a picture displayed in each row of the report. The pictures are displayed using a URL, they are not stored in the database. Only the URL is stored in the database. The reports have thousands of rows and therefore thousands of pictures to display. But, of course, this is true even when the report is displayed in IE, when it is not slow. Does this help?
I'm having the same issues.  Most of the reports perform adequately although there has been a significant performance impact by using the ReportViewer - in the order of 12-13x.  We are using some beefy iron and a SQL-Server database.  Our longest running report takes about a second to run from the ReportManager (http://reportserver/reports/reportpath), but when I run it on the web page it takes about 13 seconds.  
I've tried a few things to deal with the problem and found a couple of things:
1 - The ReportViewer uses a lot of TCP ports to do anything.  When I started looking at the performance I saw up to 120 ports per report request (for the 13 second report).  Given that Windows' (by default) only allows for about 4000 ports, we end up with a significant limit on the number of users we can have.  Even when we upped the number of ports to 65K & reduced the recycle time to release ports back we continued to have the problem.  One thing I found to do to help resolve this issue was to write my own ReportServerConnect.  That seems to have reduced the number of ports and improved performance, but didn't eliminate the problem.
2 - The ReportViewer apparently causes issues with the asp.net Viewstate.  I was getting viewstate errors if I tried to click quickly through my list of reports.  The ReportServerConnection manager along with a new base Page class (that makes Viewstates handled in a server-side array that I store in the session object) has eliminated the stability issue, but the performance issue continues.

At this point I don't know where to look next.  If anyone has any ideas for performance improvements I'm happy to supply detailed code examples.  I'm using MS ReportViewer (their web.ui version) version 9.  

Featured Post


Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now