Slow First Report Response in SQL Reporting Services 2008 in Native Mode
-
Wednesday, April 15, 2009 12:07 PM
We are experiencing a slow start up time on the first report request of the day, or when there have been no report requests for an unknown period of time. In SQL Reporting Server 2005 installations we would set up the App Pool to avoid recycling the Reporting Services applications.
However, my client installed SQL Reporting Server 2008 on Windows Server 2008 in Native mode. There is no IIS installation that I can locate. I've checked through the Configuration Settings application, the Help files and forums and have not located a solution for this problem on a Native installation.
How can I control the recycling of the Reporting Services application when installed in Native mode?
All Replies
-
Monday, June 01, 2009 9:19 AMThis is a useful guide to how to fix this problem.
http://stackoverflow.com/questions/751762/slow-startup-of-sql-reporting-services-2008-in-native-mode
MarkU -
Monday, June 01, 2009 12:03 PMYes - thanks - I posted the answer of there and forgot to cross post it back here. I got results using the answer I posted - not the original answer - and the document with that answer is here: http://msdn.microsoft.com/en-us/library/bb630448.aspx.
MSDN: How to: Modify a Reporting Services Configuration File
In it I found the RecycleTime parameter. It defaults to 720 which feels like the 20 minutes or so it took to time out. I set it to 28800.
I restarted the Reporting Services service for good measure.
-
Monday, June 01, 2009 12:06 PMThe MSDN article on this says that the parameter is in minutes - so 720 = 12 hours.
See http://msdn.microsoft.com/en-us/library/ms157273.aspx
MarkU -
Friday, April 06, 2012 6:22 PM
The issue is, that the service will be always recycled after some period of time and after that period a first report will start much longer.
A possible work around is to schedule script which will recycle the service out of business hours (eg. stop and start the service) and query the report manager immediatelly. Then during the business hours the service will be live wihout any delays.
I have this solution described on my blog post: http://www.pawlowski.cz/2011/07/solving-issue-long-starting-report-ssrs-2008/
-
Saturday, April 07, 2012 4:42 PM
Just and additional thought/workaround , you could create a subscription to a report minutes before your working day start.
If you were using SQL Server Reporting Services 2008 R2 , you could a Cache Refresh Plan
Jaime - http://blogs.msdn.com/b/jtarquino/
This posting is provided "AS IS" with no warranties, and confers no rights -
Sunday, April 08, 2012 6:49 PM
This is possible, however do not solve the problem completly.
As even after you refresh cache, an APP Pool Restart can happen right after your subscription was executed.
The RecycleTime is only parameter specifying after what time the app pool will be restarted, but there are also other things which are causing app pool restart (MSDN: Application Domains for Report Server Applications). Then you cannot rely only the presumption, that the app pool was restarted prior the Subscription has timed out. As an example a configuration change forces the app pool to restart. Then the counter of RecycleTime start to count from the time of configuration and then as I have mentioned, your app pool will not be recycled prior the business hours, but the recycling can occur during the business hours so the subscription do not solve anything in this case.
Of course even my solution does not solve it completely (as as I have mentioned, the application pool restart is triggered also by other events), but at least you can rely on the fact that it was restarted prior querying the Report Manager and therefore prepare the SSRS instance for business day.
Ideal would be if there was possibility to catch app pool recycle event in some kind and then upon this event query the report manager for example to force the app domain to load fully and do not delay the first report after the restart.
But I don't know about a way to to catch such event. (maybe some kind of monitoring based on the RRSR log file).

