currently we're able to use Telerik Reporting to fulfill our project requirements (.NET MVC), which is to generate Realtime resume/CV (curriculum vitae) in a divided page. Left side of the page is the form to collect the resume data, right side of the page is the Report Viewer. Basically, the processes are :
- As user, I fill the resume form
- Using an event, after 1 second we collect that data and put it as Report parameter and then send it to our report using the same method as here https://docs.telerik.com/reporting/html5-report-viewer-howto-custom-parameters
- Simultaneously, data collected is also updated into our database from backend process.
We did a test to create resume on our project (which already deployed into our Azure environment) simultaneously by some users. What happened is, every time the report refreshed, consume about more or less 300MB of RAM per user.
We did another test, which is to exclude process no. 3 to make sure our backend process is not the problem. The test result is the same.
Do you have any suggestion regarding our issue ? Thank you.
Telerik version we use : Telerik reporting R3 2019 SP1 (184.108.40.2060)
5 Answers, 1 is accepted
The Reports processing and rendering are extremely memory- and time-intensive operations. During the report generation, there are newly created resources. Each item takes memory and time to be processed and rendered in the report. The operations are very complex and include data processing (aggregates, filtering, sorting, conditional formatting, expression evaluation, events) and rendering (fonts measurements, layout calculations, paging and etc). For more information on what and when happens you may check the Report Life Cycle article and in the blog post Next Level Report Engine Explained.
The best approach for improving the report's performance and memory consumption would be to narrow the number of records by filtering the data server-side - check Performance factors in the developer’s control (Volume of the data retrieved from the data source).
For more information on how the report could be improved, you may check the Performance Considerations help article.
The memory consumption may increase also when you use lots of images, as they are stored in the cache until the generated document is ready. You may try to configure the cache of the Reporting engine to use for example File or Database rather than Memory or Auto (default). Note that if you provide the images with custom User Functions you need to take care of disposing of them.
I would also highly recommend upgrading to our latest version - 220.127.116.116 due to the fact that with each release, we bring improvements.
Virtual Classroom, the free self-paced technical training that gets you up to speed with Telerik and Kendo UI products quickly just got a fresh new look + new and improved content including a brand new Blazor course! Check it out at https://learn.telerik.com/.
Thanks for replying.
I did some investigation and tried to play with my report template. What I found out is the huge RAM consumption is caused by the watermark.
I used a picture with a size of 50kb as a watermark in my report template and this causes the RAM usage to be very high (200-300MB).
When I remove this watermark, the RAM usage will be only between 40-60MB.
Is this normal? How can a small image (50kb) caused the RAM usage to increase that high?
Indeed, the watermark may cause the used RAM to increase that much as it gets rendered on every page. The reason is that it is used by the GDI+ as a bitmap image.
Consider using the new feature we introduced in R1 2021 - Add Background Overlay using Report Designer.
Love the Telerik and Kendo UI products and believe more people should try them? Invite a fellow developer to become a Progress customer and each of you can get a $50 Amazon gift voucher.
We already tried using the background overlay on R1 2021, and we compare it with background image watermark, and it seems not much a different in the memory consumptions. Is this a bug? or indeed this is the limitation of the architecture? and is there a fix in the future to address this issue?
In order to process the image when integrating it into the report, we convert it to MemoryBMP. For the Watermark/Background Overlay, this MemoryBMP is generated for each page of the report. Hence, you need to multiply the image size in MemoryBMP format with the page count to get the needed memory. This is the reason for the increased memory consumption. In PDF format this is optimized and the image is embedded only once in the document. When processing the report though, all the generated images need to be kept in the memory.
Currently, the above behavior is by design. You may log a feature request for optimizing it in our public feedback portal.
Тhe web is about to get a bit better!
The Progress Hack-For-Good Challenge has started. Learn how to enter and make the web a worthier place: https://progress-worthyweb.devpost.com.