|
|
Rank: Newbie
Groups: Member
Joined: 2/22/2023
Posts: 5
|
Hi!
We upgraded EO.Pdf recently and quickly noticed severe RAM and response time on our servers. The problem happens when converting big HTML documents to PDF. For instance, one 13 MB HTML document, resulting in 156 pages of PDF, takes a very long time and eats >8 GB of RAM before I have to kill the process.
After trying different minor versions, I figured out that version 23.0.51 doesn't have this problem, and takes less than a minute and ~1 GB of RAM on my laptop.
The latest version (23.1.21) still has the problem. We suspect it's related to the Chromium update in 23.0.83 perhaps?
I can send you a test project if that helps.
Best regards,
Erik
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,086
|
Hi, Yes, please send a test project to us so that we can investigate further. See here for more details on sending test project to us: https://www.essentialobjects.com/forum/test_project.aspxThanks!
|
|
Rank: Newbie
Groups: Member
Joined: 2/22/2023
Posts: 5
|
I've emailed a test project with the subject "Test project for EO.Pdf high RAM usage issue".
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,086
|
Hi,
We have looked into the test project you sent to us and it appears that the main issue is due to version 23.0.83 uses a newer Chromium browser engine (23.0.83 is based on Chromium v108, where as 23.0.51 is based on Chromium v104). Unfortunately we are not in a position to "fine tune" the enormous Chromium browser engine.
We did find that a big contributor of the resource usage is triggered by HtmlToPdfOptions.RepeatTableHeaderAndFooter. By default this property is true and the converter will automatically repeat the table header/footer on every page. Since your document is a large table, it is extremely sensitive to this property and would result in signficiantly more pages thus much longer processing time and much higher memory usage. So if repeating table header/footer is not important in your application, you can set this property to false.
Another contributor factor is the newly added accessibility tag support. Our current version automaticlaly generates accessiblity tags in the result PDF, while older versions does not. Our next build will add HtmlToPdfOptions.GenerateTags property that would allow you to turn this off. This would further save process time/memory, even though not as much as setting RepeatTableHeaderAndFooter to false.
Hope this helps. Please feel free to let us know if you have any more questions.
Thanks!
|
|
Rank: Newbie
Groups: Member
Joined: 2/22/2023
Posts: 5
|
Hi, thanks. We will stay on .51 and try GenerateTags when available.
If that doesn't help we will have to look at other options.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,086
|
Hi,
This is just to let you know that we have posted build 23.1.25 that added HtmlToPdfOptions.GenerateTags. The default value is false. So you do not need to set it. You can download the new build from our download page. Please take a look and let us know how it goes.
Thanks!
|
|
Rank: Newbie
Groups: Member
Joined: 2/22/2023
Posts: 5
|
Hi,
Unfortunately that didn't make much of a difference.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,086
|
Hi,
Have you tried to set HtmlToPdfOptions.RepeatTableHeaderAndFooter to false? Our test indicates that this option alone would reduce the memory consumption to half. The test file you sent to us would consume up to 7GB memory with this option on (which is default), but would only consume 3GB once this option is set to false. The conversion time would reduce proportionally as well.
Thanks!
|
|
Rank: Newbie
Groups: Member
Joined: 2/22/2023
Posts: 5
|
Hi, perhaps, but we need this functionality enabled and it's still much worse than version .51.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,086
|
Hi,
In that case you may want to stay with version .51 for the time being. As the Chromium browser engine is updating constantly, we regularly updates our Chromium browser engine version as well. So there is a chance this problem will be addressed on their end in the near future and it will be integrated into our product when we refresh the browser engine again. In the mean time we will also continue to look into this from our end to see if we can find exactly what triggered the big change.
Thanks!
|
|