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.
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):
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):
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.