Q1 2014 slow rendering performance

[Roland]

Hello

We are working on optimizing our reports, and after some investigation it turns out, reports with more than 1000 rows take too long to render.



We have modified our queries so fetching the data is actually neglectible compared to the actual rendering time. Both Excel and CSV produce very similar results, so it cannot be due to some formatting issue. There isn't any conditional formatting applied to the reports there is only a table with 14 columns in the details section.
The computer specs I'm testing it on: Core i5 3.2 GHz, 8GB RAM, 240 GB SSD.

I know that similar thread exist, but I've read in the release notes that rendering performance has been significantly improved in this version, so that's why I'm puzzled.

Regards,
Roland

















Rows
SQL Time (ms)
Linq time (ms)
GetData Total (ms)
Render (ms)


2000
1
16
95
3567


4000
1
24
105
13905


8000
1
39
122
51170







%��:�

[Roland]

Hmm, copying from excel doesnt look quite good, let me try again:

Rows   SQL    Linq      Data Total          Telerik Render (ms)
2000   1          16          95                       3567
4000   1          24         105                     13905
8000   1          39         122                     51170

Times in miliseconds.

[KS]

Hi,

Check the performance considerations - http://www.telerik.com/help/reporting/designing-performance.html

-KS

[Frank]

As I said, CSV performance is just as bad as XLS, so there are:
- No PageCount,
- No Expressions
- No Subreports
- No HtmlTextBox items
- No Events
- No Chart items.
There are also no warning signs in the layout.
The only item is a table 14 columns and many rows.

[Peter]

Hi Roland,

We have reviewed the sample report definition you have send us in the support thread and noticed that you have set the Table.DataSource with Binding. Additionally the table is located in the report detail section and this will result in processing table instance for every detail row. This will have a serious impact on the report rendering times if you have thousands of details and corresponding table instances. Thus our recommendation is to change the report layout by moving the table item in a report header or unbound group section. If you need additional assistance please elaborate further on the desired report layout and send us some dummy data so we can advise you accordingly.

Generally in most cases the report rendering time should increase linearly according to the report size. Still the report generation is very intensive task that requires much more resources and processing time then the data retrieval itself. As shown in the Report Life Cycle - based on the report definition OLAP cube is build from the report raw data. Dimensions are build according to Group Definitions for the report and contained Data Items. Measures are calculated from all expressions. This is repeated for every DataSource in the report definition. Then using the report definition and the already calculated OLAP cubes hierarchies, the Report Processing Object Tree is built. Report Processing Tree contains all required layout information regardless of the PageSettings information. Then the report is paged vertically and horizontally and finally the corresponding rendering extensions renders the prepared report elements with the target format native elements.

Regards,
Peter
Telerik

 

 

[Brian]

"Generally in most cases the report rendering time should increase linearly according to the report size"

We also have experienced performance degradation with large reports. Our data does not support the above statement:

# Rows  Rendering Time (sec)  Memory Usage (MB)
  1000                                     3                            650
  5000                                   11                          1000
10000                                   23                          1400
20000                                   60                          1600
40000                                 210                          2400
80000                                 960                          3700

The report is a simple table in an unbound details section. It's datasource is set via a query in the Report NeedsDataSource event. The above data was generated using a query.Take(x), so the same query executes regardless (approx. 10 sec.). We've already subtracted this constant value from the total rendering time in the above data. We've verified the output of the data and do not have duplication of tables. We've followed the performance guidelines.

We're quite certain that there's nothing else we can do to improve the performance of this report. We will, of course, follow up with a support ticket, but I'd like to add my voice to this forum thread as well. I understand that there's no perfect reporting engine, but we're having to explain that reports that executed quickly on large volumes of data in the old Delphi/Oracle system will no longer work in the .NET/Telerik system. We would appreciate a clear statement from Telerik as to what the upper limits of reasonable performance are so that we can plan accordingly.

[Stef]

Hello Brian,

Below is a quote from my response in your support ticket on the same question:
"The report is designed properly. My only recommendation is regarding supplying data:

1. Move the code in the Table item's NeedDataSource event. You do not need to wrap the existing data object in a data source component. In general, the ObjectDataSource can use the provided class and method names to get the data via Reflection. Thus there is no need to use a data source component if the data object is already created, assign the data directly to the processing Table.
2. Other approach is to extend the existing data access layer with such data-retrieval methods used by reports. Then in reports you can use an ObjectDataSource component to wrap the corresponding method and pass values to the methods arguments via report parameters - Using Parameters with the ObjectDataSource Component.

About performance, Telerik Reporting is an embedded reporting engine, which primary goal is to analyze data and represent it in a human-readable format that is also suitable for printing. The server machine should have enough resources to handle the data retrieval and the document processing, where documents are processed with data at once. Thus there is no common measure we can provide you for amount of data, processing and rendering times, these depend on the server machine.

The new cache mechanism provides means allowing you to keep and share rendered reports, and thus avoid the re-processing - Cache Management. Other options are to use the processing power of multiple machines in a web farm, or filter data displayed in reports to avoid overloading the server. More suggestions for optimizing the performance are available in Performance Considerations.


Note that reports are rendered as HTML which is loaded in the DIV element with the ID of the viewer. Some browsers have limitations in the number of HTML elements they can display at once. For more details and suggestions, please check Design Considerations for HTML Rendering (Browsers and limitations)."

Please let us continue the discussion in one of both threads in order to keep a better track on the exchanged information.
Thank you for your understanding.

Regards,
Stef
Telerik