|
|
Rank: Member
Groups: Member
Joined: 6/16/2014
Posts: 22
|
Hi,
Currently we are using EO.PDF version 19.2.11.0. We have referred EO.PDF, EO.Base, EO.Webbrowser and EO.WebEngine in our project as dll references.
We se EO.PDF to convert browser content to generate a pdf.
We tried upgrading to EO.PDF to version 23.1.4.0. On doing so, we see that our code hangs at this step while loading the html.
session.LoadHtml(htmlBuilder.ToString());
There are no logs related to this. The code just hangs here without proceeding further. No exception caught as well. Any pointers, if there are any changes in the latest version which we are trying to upgrade?
Thanks in advance.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,088
|
Hi, There are millions line of code of changes because these are two different version of the Chromium browser engine. So it is impossible for us to look into the issue from that angle. Can you try to isolate the problem into a test project and then send the test project to us so that we can take a look? See here for information on sending test project: https://www.essentialobjects.com/forum/test_project.aspxThanks!
|
|
Rank: Member
Groups: Member
Joined: 6/16/2014
Posts: 22
|
Thanks for the quick response. I will try to isolate the root cause and see if I can give more details.
|
|
Rank: Member
Groups: Member
Joined: 6/16/2014
Posts: 22
|
Hi Team,
We have upgraded to the latest EO version (EO.Total 2023.1.45). Our previous version was 19.2.11.0. We are able to covert the html to pdf and the existing functionalities are working fine.
On further testing, we found that when the conversion is happening, memory usage is more. Shoots up to almost 98-99%. Our machines are of 16GB RAM. This is specifically happening when the data involved in the pdf is more. Around or more than 10000 records. And the size of the pdf is around 3MB to 4MB.
Any specific changes are needed to resolve this issue? Any pointers would be helpful. The same memory shoot up is not happening in the previous version that we used.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,088
|
Hi,
Please double check if you are indeed using 2023.1.45 build. There was a memory issue before 2023.1.45 build but that was fixed in build 1.45. Build 2023.1.45 would still use more memory than 2019.2.11 since it's a newer build (the browser engine is newer, more complex and bigger), but if it is significantly more, then please try to send a test project to us and we will investigate further. Without a test project we would be shooting in the dark and there is virtually no chance that we can hit anything among 30+ million lines of code.
Thanks!
|
|
Rank: Member
Groups: Member
Joined: 6/16/2014
Posts: 22
|
I have emailed the test project with subject "Test project for Support ticket 53027"
Addition details is mentioned in the Email message body
Thanks in advance
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,088
|
Hi,
We tested your code on build 2013.1.45 and it does work correctly. Are you sure you have tried build 2013.1.45? The process does take a while (67 seconds on our test system) because the result file is 556 pages.
Thanks!
|
|
Rank: Member
Groups: Member
Joined: 6/16/2014
Posts: 22
|
Team
Please note the version number is 2023.1.45 and not 2013 as mentioned in your reply. I will assume it as typo.
Also note that we never mentioned it is not working. It does work and gives us the pdf (but sometimes crashes as well, error message attached in the email sent before). But the memory goes upto 99% which affects our other services deployed in our machine as well.
Kindly confirm if you have tested with the correct version. Are there any existing memory/performance issues in the latest version identified?
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,088
|
Hi,
You are correct about the typo. Sorry about that.
Giving the size of your table, both memory and CPU will spike up during the conversion. During our test, memory usage for the rendering process (the child process that is responsible for rendering HTML and running JavaScript code) peaks at about 5.5G. CPU spike is relatively minor on a multi-core system since one conversion tasks only use one core. However if you have multiple conversion tasks of this size running at the same time it can cause multiple cores to spike at the same time thus stresses the CPU on the system overall.
Memory/CPU spike will always occur for HTML of this complexity. However some version of browser engine may spike less than others depending on exactly how the browser engine is optimized. However that part is beyond us since we are not in a position to optimize the browser engine based on specific user cases (we won't be able to do a better job than the Chromium team even if we want to). Additionally, as a general rule, a newer browser engine will always uses more memory/CPU than an older one because of the size and complexity of the browser engine only grows with newer versions. This is the same idea as Windows 95 can run on 2MB of memory but Windows 10 won't. This is normal and it is not realistic to expect the newer version to be on the same level as the old version.
Sorry for the disappointment. Please feel free to let us know if you have any more questions.
Thanks!
|
|