Post reply

Reporting Services Report Generation Benchmark

  • February 6, 2007 at 2:31 pm

    #118918

    Our I/T Mgm't would like to understand Reporting Services throughput via a BENCHMARK.  I realize this is dependent on # CPU's, RAM, Clockspeed, yaddy ya --and-- "how" the Reporting Services Reports are designed and rendered.

    Assuming a rather straight READ-WRITE approach (reporting data is laid out in a custom format on Report tables in SQL Server 2005) 

    Can anyone share w/ us -- the number of Reporting Services reports you generate in a batch for Monthly’s and Quarterly’s – ALONG w/ the time it takes to generate them.. ?

     You do NOT have to include any Data Warehouse ETL time or DW_Rpt_Driver generation time.. (these being the batch processes which prefill the warehouse and reporting tables)   Assume the Report tables are already populated – I only need the actual Report Generation timings…

    Any generic ballpark number would be great.. (eg.  1000 reports generated on a monthly basis in 4 hours… each report consists of approx 12 frames)

    BT

  • February 7, 2007 at 9:17 am

    #688317

    "Skippy" --

    I haven't conducted any throughput tests at my shop, but I can tell you the reports are typically designed in Visual Studio; from the graphical representation of a report, VS generates RDL (= "report definition language") code, which is essentially an XML variant developed by MS (in Visual Studio, open a report, then click on "View > Code" to see the RDL).  At run time, the reports are rendered into HTML by the server-side Reporting Service, using RDL and SQL Server-based data sets (created by the execution of queries or sprocs from within Reporting Services) as inputs, and served by IIS to the browser.  A browser-side control, RSClientPrint, assists with print pagination (or at least tries to do so!  Please see an earlier post of mine on the subject.).

    I assume you are interested in report generation throughput timings to identify the appropriate off-peak batch window.  From the above description, you may see that there are several potential throughput bottlenecks.  Report generation timing really depends on a number of variables; RDL rendering to HTML is but one of them.  Please keep in mind that the efficiency of your SQL queries are another.  A poorly constructed query potentially may take far longer to complete than the rendering phase itself, so you may want to consider the required execution time of your queries as part of your research.

    Kindest regards,

    Craig

Viewing 2 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic. Login to reply