My team is using Aspose PDF to turn html documents into PDFs. Unfortunately, we’re seeing performance issues with this. The attached code sample generates a PDF from a large html file. It takes nearly 4 minutes. For the actual html we use (of approximately the same size), we’ve seen times of 8 minutes or longer.
I’ve also attached the output from JProfiler, a Java profiling tool. You can see that Aspose uses around 6G of memory, and although the PDF is generated after about 3.4 minutes, Aspose hangs onto the memory, classes, and threads for another 5 minutes.
Is there anything you suggest to improve performance?
We were able to notice the performance issue in our environment. However, in our case, it threw an OOM (OutOfMemory) exception. We have logged an issue as PDFJAVA-39443 in our issue tracking system for it. We will further look into its details and keep you posted with the status of its correction. Please be patient and spare us some time.
We regret to share that we cannot share any ETA at the moment as issue is pending for analysis. Please note that issues are resolved on first come first serve basis in normal support model. However, we have recorded your concerns and will surley consider them during issue investigation. As soon as we have some certain updates regarding fix or ETA, we will share with you. Please spare us some time.
Thank you for your reply. Is there someone I can speak with to prioritize this issue? We paid a lot of money for you product, and immediately found problems with it. The performance and memory issues are delaying a critical release for us.
Please let me know who I can speak with to expedite this issue.
Performance issues are used to be complex in nature and they need certain amount of time to get resolved. We have recorded your concerns and escalated the issue to next level of priority. Please note that we realize the severity of the issue and will surely resolve it. We will inform you as soon as we make some significant progress towards issue resolution. We greatly appreciate your patience in this matter. Please spare us some time.
Hello there, This performance issue is turning out to be a huge blocker for our upcoming critical release. Could you connect us to someone in Aspose leadersip we could talk to to prioritize this issue for quicker resolution? or provide alternatives for us?
We have performed an initial investigation against the logged ticket and found that the issue can be resolved by using more than 6Gb of Heap Memory for such documents to avoid OOM Exception ( -Xmx6g -Xms6g ) and get converted documents.
This is the expected result for converting documents with 323 pages for 3-4 minutes. Our .NET API converts the attached document for 180-190 seconds, while Java version takes 220-230 seconds, and this is not a big difference.
We also take into account an issue and will try to optimize our algorithms to make this conversion faster by using less memory. But due to the complex nature of the issue, it would take more time, and sadly, we cannot promise any ETA at the moment.
We would also like to add that you can please check our priority support option which can be used to prioritize/escalate blocker issues.
It has been over 6 months since your team confirmed the performance degradation on your side along with the memory leak. The workarounds suggested in the thread doesnt scale for us and we have a lot of enterprise customers that has reported how unacceptable this performance is. This is causing Jama revenue loss and customer churn. This performance has also made some of our recent features around PDF exports un-usable. As a customer invested in more than one of your product suite I would expect more diligence from Aspose than pointing to priority support option.
Have your team identified any further optimizations? When can we expect an answer or resolution?
We improve API performance in terms of memory consumption in every monthly release. There are certain improvements in the API for HTML to PDF conversion in the upcoming version i.e. 20.12 which will be released at the end of this month. However, we regret that we cannot replace our existing conversion engine completely in a short amount of time. Therefore, the ticket is taking time to get completely resolved.
Furthermore, we have taken your concerns into account and escalated the ticket to the next level of priority. We will try to provide an update soon regarding resolution of the earlier logged ticket. We highly appreciate your patience and comprehension in this matter.
Can you run our previous provided test through your version of 20.12 and confirm if that is rendering any noticeable improvement? We have upgraded Aspose early this year to 20.6 and that incurred us cost around regression and trade off of product roadmap. I would like to know for sure that the update solves our problem before we take that.
Can anyone from Aspose product/engineering run through your roadmap and expected timeline for the replacement plans of your conversion engine? I would like to understand if that matches our product need and make appropriate decision before our next Aspose license renewal cycle.
Currently, the 20.12 version is at its final stage to be released. We are already running some tests against the integrations made and as soon as the final JAR is ready, we will be able to test your case with it.
We have recorded your above inquiry along with the ticket and will gather related details to share with you. We will try to provide some definite ETA along with clarification for API performance as soon as possible. Please give us some time.
We profiled the PDF generation using JProfiler tool and we consistently noticed that the Aspose library code was stuck waiting on a lock for 100 seconds in our test environment. In contrast, in our development environment, the same report runs in less than 10 seconds, and did not notice such locking. Screenshots attached.
Based on these findings, we had a couple of questions:
Does the library take a different code path based on the environment (cpu, memory, etc) and use a multi-threaded approach to generate the pdf? If that’s the case, is it configurable?
In the screenshots, you will notice that the code is waiting exactly 100 seconds for a lock. This could be a hint to why the pdf generation is getting stuck in our test and production environment. To reiterate, in our local instance, the same report takes less than 10 seconds. Can you explain why it’s waiting for 100 seconds?
Please note that currently the logged ticket is under investigation phase and we are improving some internal components of the API in order to improve the HTML to PDF conversion engine. The inquiries which you posted have also been logged under the ticket ID logged previously.
We need to look into these details in order to resolve the issue and provide you an appropriate feedback. We will soon let you know about the updates once the ticket is resolved. We highly appreciate your patience and cooperation in this matter. Please give us some time.
We understand that the research and core issue resolution is taking longer at your end while it is equally affecting our customer base. While you folks investigate and work on fixing the core issue, would it be possible to schedule technical consultation from your end to review our configuration and provide some solution that could alleviate the pains we are noticing?
Who can help schedule a call with your solution architects or some one to review our configuration and provide advice?
Our Aspose PDF renewal is coming up in April and I would want to know if this long running issue can be fixed before Feb for us to make our renewal decision. I do expect some tangible nexts with ETAs as a response to this thread.
We have recorded your concerns and will surely consider them in order to escalate the ticket resolution process. As far as review of the configuration and other environment settings matter, please give us little time to analyze and offer you some workaround to prevent the issue before the ticket is completed resolved. We will be reaching you soon with our feedback.