The SQLCAT team just released a very interesting technical note which compares the relative “scalability goodness” of Reporting Services 2005 to 2008. You can read the article just as well as I can, but here’s the executive summary, and the results are pretty impressive (bold is mine, btw)

Executive Summary

Reporting Services 2008 was able to respond to 3–4 times the total number of users and their requests on the same hardware without HTTP 503 Service Is Unavailable errors compared with Reporting Services 2005, regardless of the type of renderer. In stark contrast, Reporting Services 2005 generated excessive HTTP 503 Service Is Unavailable errors as the number of users and their requests increased, regardless of the report renderer.

Our tests clearly show that the new memory management architecture of the report server enables Reporting Services 2008 to scale very well, particularly on the new four-processor, quad-core processors. With our test workload, Reporting Services 2008 consistently outperformed SQL Server 2005 with the PDF and XLS renderers on the four-processor, quad-core hardware platform (16 cores) both in terms of response time and in terms of total throughput. Furthermore, with these renderers on this hardware platform, Reporting Services dramatically outperformed other hardware platforms regardless of Reporting Services version, responding to 3–5 times the number of requests than when running on either of the other hardware platforms. As a result, we recommend that you scale up to four-processor, quad-core servers for performance and scale out to a two-node deployment for high availability. Thereafter, as demand for more capacity occurs, add more four-processor, quad-core servers.

Finally, with all renderers and with all hardware platforms using our test workload, the performance bottlenecks were the processor on the front-end server and the disk subsystem on the data source with Reporting Services 2008, whereas the Reporting Services front-end Web service was the performance bottleneck with Reporting Services 2005.

It’s a whole new ballgame, folks!

Some people love to review logs. For an even smaller group, log reviewing becomes a compulsion. For those of you who fall into either bucket (or even for people like me who only look at logs if my server is spinning in circles like Regan from the Exorcist) you may occasionally see this:

w3wp!runningjobs!5!6/1/2008-12:00:00:: w WARN: Thread pool pressure. Using current thread for a work item

So, what does it mean? I attempted to explain this message to a colleague the other day, and then John Gallardo, an SDE on the SSRS team did a much better job. Here is the essence of what he said:

When a report is processed by Reporting Services, we do our best to separate the work it takes to persist “report meta data” (my words, not his) like the snapshot we store in reportservertempdb and the work involved in actually getting a report to your users. Doing so gets the report back to the user faster. Essentially, we save that snapshot data asynchronously on a different thread from the main report request whenever there are available threads to do so.

If your system is under pressure we don’t grab another thread to do this “dirty work”. Instead, we synchronously process both the report and do the additional work on the same thread. The net result for you is that normally your report will take longer to get back to the requester because they have to wait for extra tasks to finish up before the report is delivered.

I saw an interesting thread today I thought I would pass along. In essence, one of my colleagues wanted to know if the twenty-ish queries behind his SSRS report would all fire at the same time, or sequentially.

The answer is (of course, we’re Microsoft) “it depends”. Robert Bruckner from the SSRS product team pointed to the “Use Single Transaction” option on the data source properties dialog in Report Designer. If  this option is enabled (it’s disabled by default), then we run queries sequentially. If the option is disabled, we run in parallel assuming we have available threads in the SSRS thread pool.

Interesting stuff!