WinForms ReportViewer: slow initial rendering

Question

UPDATE 2.4.2010 Yeah, this is an old question but I thought I would give an update. So, I'm working with the ReportViewer again and it's still rendering slowly on the initial load. The only difference is that the SQL database is on the reporting server.

---

UPDATE 3.16.2009

I have done profiling and it's not the SQL that is making the ReportViewer render slowly on the first call. On the first call, the ReportViewer control locks up the UI thread and makes the program unresponsive. After about 5 seconds the ReportViewer will unlock the UI thread and display "Report is being generated" and then finally show the report. I know 5 seconds is not much but this shouldn't be happening. My coworker does the same thing in a program of his and the ReportViewer immediately displays the "Report is being generated" upon any request.

The only difference is that the reporting server is on one server and the data is on another server. However, when I am developing the reports within SSRS, there is no delay.

---

UPDATE

I have noticed that only the first load of the ReportViewer takes a long time; each subsequent load of the same or different reports loads fast.

---

I have a WinForms ReportViewer that I'm using in Remote processing mode that can take up to 30 seconds to render when the ReportViewer.RefreshReport() method is called. However, the report itself runs fast.

This is the code to setup my ReportViewer:

rvReport.ProcessingMode = ProcessingMode.Remote
rvReport.ShowParameterPrompts = False
rvReport.ServerReport.ReportServerUrl = New Uri(_reportServerURL)
rvReport.ServerReport.ReportPath = _reportPath

This is where the ReportViewer can take up to 30 seconds to render:

rvReport.RefreshReport()

Answer 1

You can pull a report in two modes, local and server. If you're running in local mode, it's going to pull both the data and the report definition onto your machine, then render them both. In server mode, it's going to just let SSRS do all the work, then pull back the information to render.

If you're using local mode, it could be a hardware issue. If you've got a huge dataset, that's a lot of data to store in memory.

Other than that, that's not a lot of info to go on...

Update: since you've noticed it's only the first call that takes a while, have you done any profiling to determine if the bulk of the work is done on the backend SQL calls or is spent in the actual report render?

If it's faster on subsequent calls, it's possible you're (incidentally) caching at one level or another. You can cache reports (http://www.sqlservercurry.com/2007/12/configure-report-to-be-cached-ssrs-2005.html) or it could be that the execution plan to return the data is being cached deep in SQL Server.

Answer 2

UPDATE

I have noticed that only the first load of the ReportViewer takes a long time; each subsequent load of the same or different reports loads fast.

Answer 3

I've had the same problem with Crystal reports viewer. I suspect it has something to do with the initial loading of the supporting infrastructure of the reporting engine that takes a bit of time.

Answer 4

Thinking way out of the box: Is the report server on different machine to the one running the application? The network could be taking a long time to resolve "reportServerURL". Once resolved the name would be cached and hence subsequent calls would be quicker..

I have had this problem before with badly configured DNS servers. Try replacing "reportServerUrl" with "reportServerIPAddress" and see if the initial call to ReportViewer is any faster.

Answer 5

You are set to run on server which means the SRS server needs to do the rendering as such the first time there will be a delay for one or all of the following reasons (these are the slowest of the bunch, there are others but they are quicker):

• DNS resolution: The URL needs to be resolved to an IP address. Once this is done it is cached locally which speeds it up.
• ASP.NET/IIS needs time to warm up. There is all kinds of compilation and initial loading that must occur - after loaded it will remain in the servers memory until you restart IIS or the default clean up time occurs.
• Reporting Services needs time to warm up in the same way as ASP.NET/IIS does.

To test for this use a network monitor such as Netmon (if you are a Microsoft fan) or Wireshark (my recommendation) and watch the traffic from your machine to the server. You'll see the DNS request, then the HTTP requests go and the delay will be in the returning data. On second call you will see the speed is vastly different in the return and DNS checks.

What you could do to prevent this is a warm up script - I don't know one for SRS but here is a link to a SharePoint one which would not be hard to change since it has the exact same issues.

Answer 6

ReportServer always takes a while to wake up because it's running under IIS. There is a process time out on each AppPool. We have the same issue with our ASP.NET application's report viewer. You could try increasing the AppPool keep alive times in the IIS settings.

See here:

• http://www.sqlreportingservices.net/Ask/5536.aspx
• http://www.developmentnow.com/g/115_2005_9_0_0_597422/First-run-of-reports-is-SLOW.htm

I'm assuming you're running SQL2005 SSRS of course.

One option is to upgrade to 2008 where SSRS no longer depends on IIS.

Answer 7

In summary of the various ideas already presented, it could be

• startup time for the report viewer infrastructure on the client
• cache loading time on the client
• query execution time at the server
• report rendering time at the server

Try running the report, closing down the client, restarting the client and running the report again. If the report is much faster the second time, repeat this experiment but load, run and unload another large application in between report runs.

If the second report run continues to be much quicker, then the difference you are seeing has more to do with the SQL Server's I/O cache than what's happening on the client. You can further test this by deliberately displacing the MSSQL cache by running a query that pulls a lot of data from tables that aren't used in the report.

All of the above is interesting but unimportant. If you want to ensure snappy report response Reporting Services provides extensive support for scheduled generation of reports, so that when the consumer requests the report, the only delay is network delivery.

If your users insist on reporting on up to the minute (live) data they'll either have to specify tighter constraint parameters or get used to waiting.

Answer 8

It seems as though you are going after the SSRS report directly. You may want to hit the SSRS web service instead. That may improve your performance.

Answer 9

Hi, Here is a possible resolution for your problem: Try to access the first report from web before accessing any report with the application.

If the problem doesn't appear, you could make an application that will "preload" the first report, in order to allow reporting services to do their start-up.

I've seen this kind of solution for some demo applications from Microsoft. The applications where using Analysis Services and Reporting Services.

Good luck otherwise

Answer 10

I was having this same problem.

i find out that changing the default printer(slow network here) fix the problem.

The ReportViewer gets some information from the default printer, and since the network here is very slow, i was having 10 seconds of delay

Hope it helps

Answer 11

I've had the same problem here with Windows Forms apps, .NET 2.0 with Crystal Reports for .NET 2.0, but sometime in the past few weeks it has gotten much worse. It used to take up to 10 seconds to load the Crystal Reports viewer the first time within an app, but now it takes over 2 minutes! And this is happening on multiple apps, every report (whichever runs first), on different computers. This is on a corporate network; I think something has been pushed out that is causing the problem, like a Microsoft security update, more virus software junk, or similar. Has anyone found a solution? I tried changing default printers and that hasn't helped.

Answer 12

I found the answer on other forums. MSDN explains that a DLL is searching for some Verisign web server and it takes forever... there are 2 ways to turn it off, one is a checkbox in internet explorer and another is adding some lines to the app.config file of the app.

Answer 13

Ilan Makka Kuzza , Sakka Nila baboothae Sankanya