By Omri Gindi, Windows Azure SQL Reporting team


In this post, I'd like to share some of our findings from recent performance tests that looked at how performance varies based on report composition. The key finding is that using large interactive sizing (or no interactive sizing at all) for large rendered reports reduced overall report performance, mostly due to the large amounts of data that had to be loaded into the first page.

What this tells us is that if you want to view big amounts of data in a report page, you can expect a small hit in performance, which you may be able to offset by reducing page interactive size. Reducing the size renders a smaller first page, hopefully putting it within an acceptable range of performance for your report consumers.


The reports we used for this test are real customer reports in production, on a reporting service deployed in the North Central (Chicago) data center.

For this test the customer provided the following reports. Except for the differences detailed below, all reports were identical, consisting of a table with about 100 rows.

  1. Small Interactive Sizing – Interactive height was 8.5 inches.
  2. Large Interactive Sizing – Interactive height was 80 inches.
  3. Shared Dataset – Identical to Large Interactive Sizing, with a shared dataset (the shared and embedded datasets are identical across all reports).


The results were compatible with the results we saw on our test report servers. The most influential parameter was the interactive height.

We rendered each report 10 times, from a machine in San Jose (Azure DC West US).

Following are the times it took for the first page of each report to be rendered in the browser, after the RVC (Report View Controller) had been loaded (in milliseconds):

  1. Small Interactive Sizing: 1801.6
  2. Large Interactive Sizing: 5320.1
  3. Shared Dataset: 5790

We can attribute the small difference (less than 10%) between Large Interactive Sizing and Shared Dataset to network latency.

When looking at engine performance, we see minor differences in report execution, which do not account for to overall performance differences we see in the previous list. Following is the average total time spent in the Reporting Engine for each of the reports (in milliseconds):

  1. Small Interactive Sizing: 1236
  2. Large Interactive Sizing: 1100
  3. Shared Dataset: 1124


From these results, we can conclude that slower performance is due to the time it takes to transfer a rendered page from a reporting service to a client application in a geographically distant location. A rendered page that contains a large amount of data takes longer (in our tests, over twice as long), than a page containing less data.