CHAPTER 10 MANAGING REPORTSFigure 10-27. Report Execution Log report
Monitoring Performance
Of course, no one wants to experience the frustration of building a solid reporting solution in a
development environment only to find out that, when deployed to the masses, it can’t hold up under the
strain. Generally, it’s a best practice to put a simulated load on your servers to gain a better
understanding of how the systems will function. As well, when you roll out a full solution, it’s a common
practice to roll out several pieces at a time to a limited number of users. That is what we’ve done in our
online models.
The strategy for rolling out should also include a plan for which reports will be available on-demand
versus which ones will be provided via report snapshots or subscriptions, as you’ve done up to this point
in the chapter. Combining a strategy of peak and off-peak report processing will greatly improve
performance. Another consideration for performance with SSRS lies in splitting the load of SSRS Web
services and database services. That is, if the entire SSRS installation resides on the same system, this
could negatively impact performance.
In this section, we’ll show the results of a stress test that we ran accessing two report server
instances on two separate servers, RS05 and HWC04. Many tools, such as SSRS, are available for stress
testing Web applications; fortunately, the Ultimate edition of Visual Studio 2010 has a Web stress-test
tool built in that we used to perform a simulated load on the two servers with up to 250 virtual users out
of the box. You can find out more about the web test tool at http://www.microsoft.com/visualstudio.