Performance (Reporting Services)
Report server performance is affected by a combination of factors that include hardware, number of concurrent users accessing reports, the amount of data in a report, and output format. To understand the performance factors that are specific to your installation and which remedies will produce the results you want, you will need to get baseline data and run tests. For more information about tools and guidelines, see the following publications on MSDN: Planning for Scalability and Performance with Reporting Services and Using Visual Studio 2005 to Perform Load Testing on a SQL Server 2005 Reporting Services Report Server.
General principles to consider include the following:
Report processing and rendering are memory intensive operations. When possible, choose a computer that has a lot of memory.
Hosting the report server and the report server database on separate computers tends to provide better performance than hosting both on a single high-end computer.
If all reports are processing slowly, consider a scale-out deployment where multiple report server instances support a single report server database. For best results, use load balancing software to distribute requests evenly across the deployment.
If a single report is processing slowly, tune the query if the report must run on demand. You might also consider caching the report or running it as a snapshot.
If all reports process slowly in a specific format (for example, while rendering to PDF), consider file share delivery, adding more memory, or choosing a different format.
To find out how long it takes to process a report and other usage metrics, review the report server execution log. For more information, see Report Server Execution Log.
For an overview of the stages of report processing, see Report Processor. For more information about how to mitigate performance issues by tuning memory management configuration settings, see Configuring Available Memory for Report Server Applications.