We are running a load test on our product and we have noticed IIS application pool crashes. We ran a dottrace to pinpoint where the memory starts crashing. We noticed that 85% of the memory allocation is happening inside of the Aspose product.
Document(Stream, LoadOptions) constructor in the Aspose library… internally, Aspose is delegating all of the work from the constructor to a method called \u0002.
Aspose.PDF was upgraded in October 2017.
Kindly send us your source document(s) which you are using to load into the stream and passing as parameter to the Document class constructor. We will investigate your scenario in our environment, and then share our findings with you.
we are using version 17.9 and we will upgrade to 18.3 since we saw that there were memory release issues with the version 17.9
Sure, please try the latest version 18.4 of Aspose.PDF for .NET API because the latest version includes the recent features and enhancements.
We upgraded to version 18.4 and we are still experiencing high memory allocation from aspose, while load testing our application. 2018-05-07_9-37-59_Aspose.png (135.2 KB)
Kindly send all details of the scenario, including source documents and code. We will investigate your scenario in our environment, and share our findings with you.