We are experiencing horrible performance when first creating either an empty Document (new Document()) or a document from a RTF string converted to a ByteArray (new Document(is, LoadOptions)).
The first hit seems to take 1-2 minutes while subsequent hits seem to work fine.
We are using:
- Tomcat8 / Java8
- AWS ElasticBeanstalk (single server)
- Aspose.Words 15.8.0 (licensed)
Locally, either running under Jetty or Tomcat8, we do not experience these problems.
UPDATE:
Running in the exact same server environment using Jetty9 works fine.
Thanks for your inquiry. When a document is loaded into Aspose.Words DOM, it takes some time to load all resources first time. Please note that usually Aspose.Words needs few times more memory than document size to build model of the document (DOM) in memory. Usually, Aspose.Words needs 10 times more memory than the original document size to build a DOM in the memory.
It
is quite difficult to answer such questions because CPU performance and
memory usage all depend on complexity and size of the documents you are
loading/generating.
Could you please share the time difference which an empty Document (new Document()) or a document from a RTF string converted to a ByteArray (new Document(is, LoadOptions)) take at Tomcat8/Java8 and Jetty9? Please also share at which Operating system you are testing this scenario. I will investigate the issue on my side and provide you more information on this.
I can actually replicate the issue by just constructing a new Document() using the empty constructor.
In our code, right after we set the license if I call “new Document()” the system comes to a halt for at least a few seconds.
Running in Tomcat8, without special modifications, the Aspose portion of our app, narrowed down to the construction of the Document, takes a significant amount of time and with minimal load, 2-3 users it seems to bottle-neck the webapp.
Running in Jetty9, without special modification, the Aspose Words portion of our app seems to run perfectly (i will test this more today).
All we set in the load options, is the encoding and in some cases the format but again, just constructing an empty Document() has problems.
Aside from the webserver, Tomcat8 or Jetty9, the environment is exactly the same (AWS Linux). Approximately 4GB RAM, 4 core, etc. Also, it should be noted that running locally in a virtual machine (Linux Mint), the Tomcat8 environment seems to work well.
When a document is loaded into Aspose.Words DOM, it takes some time to load all resources first time. Upon the first time, Aspose.Words initializes common static resources, for example fonts installed on the PC. Could you please share the steps here to reproduce this issue at our end? Please
also share at which Operating system you are testing this scenario.
I have tested the scenario and have not found the shared issue. Creating empty document (new Document() ) takes time first time only. It takes 255 ms first time and for second time it takes around 50 ms at my end.
I believe this is a problem running Aspose Words along side New Relic instrumentation. I can now replicate the issue in Jetty9 when I enable NewRelic. Disable it and it works fine.
Finally, I think I have the details - it has to do with the fact your JAR is signed and it is causing the -javaagent instrumentation strife.
If I “unsign” your JAR it works fine along-side NewRelic and properly handles any instrumentation.
NewRelic (http://www.newrelic.com) is used to monitor applications and requires using of the -javaagent to be able to instrument them at runtime. This is a fairly standard enterprise Java tool used by almost all of our clients.
To replicate the scenario you can spin up either Tomcat or Jetty using the -javaagent=newrelic.jar, create a simple JAX-RS service that does something as simple as create a new Document(), include the NewRelic.jar and yml file then call the REST service. In our case, a simple service is getting deadlocked at the point we start using any of the Aspose.Words API.
Thanks for sharing this detail. We are setting up the same environment at our side. As soon as everything is setup, we will test the issue at our end and will post the results here for your kind reference.
Sets consent for sending user data to Google for online advertising purposes.
Sets consent for personalized advertising.
Cookie Notice
To provide you with the best experience, we use cookies for personalization, analytics, and ads. By using our site, you agree to our cookie policy.
More info
Enables storage, such as cookies, related to analytics.
Enables storage, such as cookies, related to advertising.
Sets consent for sending user data to Google for online advertising purposes.
Sets consent for personalized advertising.
Cookie Notice
To provide you with the best experience, we use cookies for personalization, analytics, and ads. By using our site, you agree to our cookie policy.
More info
Enables storage, such as cookies, related to analytics.
Enables storage, such as cookies, related to advertising.
Sets consent for sending user data to Google for online advertising purposes.