Report Rendering is Incredibly Slow

[Mike Lyncheski]

We are using the Silverlight viewer in conjunction with Telerik Reporting.  Any report with more than a few pages takes an unreasonably long time to render.

I will save you the painful details because I see you are well aware of this issue (search for slow in Reporting forum).

Are there any plans in the immediate future to rectify this?

Also, is there any way to gracefully cancel a loing-running report?  A built-in cancel button would be helpful.  Failing that, are there any events for detecting when the report is rendered/viewable (e.g., RenderEnd)?

Thanks,
Mike

[Steve]

Hello Mike,

A few pages is a pretty vague concept, moreover it is what you have on those pages that matter most when it comes to performance. The processing time (consumed memory as well) depends heavily on the complexity of the report layout, data calculations (aggregates, conditional formatting), the rendering media, and the size of the generated document (in pages). In this line of thoughts handling such reports requires powerful CPUs, and enough memory to handle all those operations.

We're not sure whether you want to ask for actual help on how to optimize your report (have you reviewed our suggestions in the other threads you've encountered?) or you just want to voice your opinion here. Either way, without a runnable sample project on our end, it is very hard to give appropriate advise especially when it comes down to making something work faster. Sending us a sample runnable application is usually the fastest way to get to the bottom of a problem and suggest how to optimize it or confirm it as an issue that needs to be addressed on our end.

As for your second question, unfortunately there is no way to cancel a report from being processed/rendered once the process begins. The web is stateless, i.e. the server is not aware of what the client does, so what happens is: you start the processing and it is performed on the server until ready. This process continues independently on whether your browser is still there waiting for the report to appear or has been closed during that period.

Telerik Reporting is an embedded engine which means that it is part of your application (not a separate one). If you can figure out a way to stop your application at a certain time (i.e. elapsed time or taken memory), this would stop the report processing as well.
 

All the best,
Steve
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.

[Maarten]

Hi,

Is there any update on the rendering issue?
I have to agree with other threads, rendering time is not acceptable.

We use TeleRik for a major customer since this year and the rendering will become a problem.
Simple example (difficult to send code samples due to privacy):

I have a fairly simple report (no sub reports, no conditional formatting), just a bit of grouping and about 10 columns with data in the report. 3 data sources (2 for drop down filters, 1 for the report content), those take about 100 milliseconds and my report data set returns between 500 & 1000 rows. The report is 36 pages and the rendering takes up to 18(!!) seconds.

I added a screen shot to show how simple the report is (I had to blur the data for privacy reasons, because it concerns patient information).

Very difficult to sell to the customer...

best regards
Maarten

[Peter]

Hi Mike Lyncheski,

In order to investigate the reasons for the slow-down we don't need your actual data. All we need is the report definition and sample data. Thus we will appreciate if you open a support thread and send us the report definition to profile it locally.

Generally we are constantly working on improving Telerik Reporting performance as a whole and we do have some ideas for improving the performance for the next release.

Regards,
Peter
the Telerik team

[GAM]

When can we expect an update to the Silverlight ReportViewer? We have a project going live this June (2011) and I will get shot if we replace the current reports with something this slow. I would like to think that an update is iminent.

Some stats:
- the actual database query takes 0.719 seconds
- the business layer processing dioesn't even register
- the report viewer renders in between 6-10 seconds

It is blatantly obvious where the bottle neck is...

[Peter]

Hello Malcolm,

One has to keep in mind that handling reports (be it with large data or large number of report items) usually requires additional resources to handle all the operations. Those operations are much more complex and include data processing (aggregates, filtering, sorting, conditional formatting, expression evaluation, events) and rendering (fonts measurements, layout calculations, paging and etc.). In general report processing/rendering is quite complex process and can't compared with data retrieval and business layer processing. For more information on what happens and when it happens check out the Report Life Cycle help article.

Kind regards,
Peter
the Telerik team

[Sheeraz]

Hi Peter,

I am suffering from same issue, I have a report that has 3 sub report. One of those sub reports has further 6 sub reports. And each report from those 6 reports has 5 to 8 sub reports. I have a case where this report has to show 2600 pages on report viewer. Its rendering is looking impossible. System hardware is 8 GB RAM, Core i7, 1TB harddisk. Please suggest some solution for rendering of this report. It is a do and die situation and I need this report as per our client requirement.

Thanks

[KS]

Hi,

This definetely will not pass the described here - http://www.telerik.com/help/reporting/designing-performance.html. Try to reorganize the layout to remove at least half of the sub reports. There are also ways to bind data more effectively - http://www.telerik.com/help/reporting/data-items-how-to-use-data-object.html.


-KS

[Tony]

I am going to go out on a limb here and state that the performance issues described are a result of a serious issue with how Telerik Reporting pulls data WHEN using an embedded SQL statement as its data source. I have been perplexed for a long time now as to why my tabular reports take so long to run with no apparent CPU or memory resource limitations. What I've noticed however is that during a long running tabular report there is consistent network usage pattern indicative of a SQL statement that is being executed over and over again. It is as if the report engine is pulling the records in 50 or 100 row blocks.

The work around is to use a stored procedure as your data source. In one test case the exact same SQL in a stored  procedure rendered the report in 2 seconds which the equivalent embedded SQL version of the report took ~75 seconds.

This was observered on version R1 2017 SP1.

[Katia]

Hi Tony,

Report processing and rendering are memory intensive operations. During the report generation, besides the retrieved data there are newly generated resources by the report which are held in memory and each item takes memory and time to be rendered in the report.

The best approach for improving the report's performance would be to narrow the amount of records by filtering the data server side - please check Performance factors in the developer’s control(Volume of the data retrieved from the data source).
More detailed information and suggestions for improving the report's performance are described in Performance Considerations help article.

You can attach your report in the support ticket #1128570 so we can test it locally and check if there could be some ways to optimize the performance of the report.

On the side note, reports performance is our major concern and we are constantly working to improve it. For example, the upcoming R3 2017 release (next week) will have more improvements of performance and scalability of the report rendering engine - What's Coming in R3 2017.


Regards,
Katia
Progress Telerik

[Thao]

I faced the same issue. If my report is just few page, the generated time is few seconds. But if my report is 30-50 pages, it will take up to 20minutes. That is not acceptable. I investigated and saw that the function to get the data just takes 1 minutes, the rest is the report render. I'm looking to switch to other solution like iTextSharp to generate PDF instead of Telerik report.

[Katia]

Hello Thao,

I agree that the generation of 50 pages report should not take 20 minutes. I have performed some tests locally and the report that contains 50 pages generates in less than a minute on my side. 
Feel free to send us the problematic report with some test data so we can profile this report locally and check if there can be any performance optimizations. You can attach the report to the support ticket #1135881.


Regards,
Katia
Progress Telerik

[Thao]

Thanks Katia,

I found the solution. Remove the pagecount will fix the issue. 

[Vincent]

How do you switch off the PageCount

[Thao]

In my report footer, I have code to call to the pagecount function, I just need to remove that function call. Not sure if that completely disable the pagecount, at least my report doedn't call the pagecount function for each page. 

[Silviya]

Hello Thao,

Indeed, using PageCount object triggers an extra paging and lead to slowing down the rendering time. Performance factors in the developer’s control section mention that if it's possible, you should avoid it to speed up the performance. This could be done by simply remove that function from your report definition.

Regards,
Silviya
Progress Telerik

[Đức Tường]

Hello Admin,

I have create a report with pagebreak, with 4000 record and have 30 record on a page, only 20 columns. But report render very slowly  about 5 min. I do it on version Progress® Telerik® Reporting R2 2019 SP1 (13.1.19.618). How I reslove it.

Thanks

TuongTD

[Neli]

Hi TuongTD,

In Telerik Reporting R3 2019 (13.2.19.918), we have added an optimized performance of the DataSource Components. The Reports service cache invalidation algorithm is also improved. For that reason, I suggest checking the performance after upgrading to the official Service Pack (13.2.19.1030) or to the latest Internal Build (13.2.19.1111).

Regards,
Neli
Progress Telerik