Share via

On-Demand Report Processing in Reporting Services 2008

  • Article

You may have heard by now that the report processing engine of Reporting Services 2008 works significantly different underneath the covers, compared to previous releases. While I plan to dive into more technical details in future postings, I wanted to provide a few examples upfront explaining why you as a report author or end user might care:

  • On-demand processing of reports with many datasets and data regions.
    For instance, if a user only views page one through three, and those pages only refer to data regions / expressions referencing DataSet1, all other data regions bound to other datasets are not necessarily processed immediately. Processing can be delayed until a user navigates to a particular page showing that data region or hitting an expression that references information from those other datasets.
     
  • Reports with heavy usage of interactivity can be significantly faster.
    The main reason for the speedup is that certain interactivity related calculations (e.g. toggles, drillthrough actions) are now performed on-the-fly as pages are viewed by the user, instead of having to do these upfront before the first page is shown.
     
  • Faster page-by-page navigation when viewing reports interactively.
    The new architecture allows us to cache a few bytes per page that enable quick restart of pagination of a partially/fully paginated report. As a result, navigating to a page of a report which was already previously accessed during the same session is now faster, particularly the larger the report in size. You can verify this with a report with several thousand pages. Navigate to the last page of the report (which triggers paginating the entire report), and then try to randomly navigate to any page within the report. Reporting Services 2008 will be faster.
     
  • Smaller memory footprint.
    The memory footprint of requests is generally smaller with the on-demand processing engine, particularly for very large reports. However on a system with low load, you may not see any significant working set difference in task manager due to various types of caches utilized within the processing engine.
     

So what is the main architectural difference with on-demand report processing?

Unlike the RS 2005 processing engine that processed the report as a snapshot evaluating all expressions exactly once upfront (including textbox values, style expressions, etc.), the RS 2008 on-demand processing engine pre-computes and persists only certain invariants, such as grouping, sorting, filtering, aggregates, and report/group variables. All other expressions (style expressions, textbox values) are evaluated on-demand based on the invariants, at the time a rendering extension requests a specific page containing those values. Hence, you could also call it rendering-driven on-demand processing engine.

You probably now think, thanks that’s nice; and where is the catch? J

Well, most expressions in a report, particularly textbox values and style expressions, are evaluated on-demand in Reporting Services 2008 as you navigate to a particular page. If you go there multiple times, it might be re-evaluated again. Try this to see the effect of on-demand processing:

  1. Generate a multi-page report with a textbox value of =Now on the first page.
  2.  View the first page in HTML and note the textbox timestamp value.
  3.  Navigate to the second page, then go back to the first page.
  4.  Note that the textbox was re-evaluated as the first page was rendered again in RS 2008. The timestamp changed.

If you do not want this on-demand behavior in particular cases (e.g. time-dependent calculations, custom code, or expensive calculations requiring caching), you should use so-called Report Variables or Group Variables, and then reference the variable value in the report (e.g. =Variables!V1.Value). Variables are covered in more detail in a previous posting.  If it is just about consistent time stamps, you should instead use =Globals!ExecutionTime, regardless of the version of Reporting Services (more info on global built-in collections is available on MSDN).

Among other topics, future postings in the on-demand processing series will also provide report design tips to better leverage the new processing engine in RS 2008.

Comments

  • Anonymous
    August 11, 2008
    PingBack from http://blogs.msdn.com/robertbruckner/archive/2008/07/20/Using-group-variables-in-reporting-services-2008-for-custom-aggregation.aspx

  • Anonymous
    August 11, 2008
    Note: this posting provides an overview of when to consider using Report Variables and/or Group Variables

  • Anonymous
    December 31, 2008
    CustomReportItem in Reporting Services 2005 A new feature introduced in Reporting Services 2005 (RS 2005)

  • Anonymous
    January 05, 2009
    There are several options for monitoring performance of a report server. The upcoming fourth article

  • Anonymous
    January 19, 2009
    We plan to release significantly updated and improved versions of both the Winforms and ASP.NET Report

  • Anonymous
    January 27, 2009
    In order to integrate Reporting Services into your Web Application you have the following options: using

  • Anonymous
    March 05, 2009
    Tablix is the new underlying flexible data region and grouping structure introduced in Reporting Services

  • Anonymous
    March 27, 2009
    In working with a customer doing a migration from Reporting Services 2005 to 2008 an error appeared when