Performance in deployment environment

[pedro]

Hello,

I have developed a typical application that produce a .docx a this is transformed to .pdf. In development enviroment the performance is acceptable. About 10 secons. But when I have generated a .jar and move to deployment enviroment, the performance decreases and takes about 3 minutes. A execute a via .bat like this "java -Xms512m -Xmx2048m -Djava.util.logging.config.file=D:\temp\factures\config\logging.properties -jar D:\temp\factures\PDFInvoice.jar %1"

The development environment is eclipse mars 2, my jre is 1.8 and all run in windows 10. The docx4j is 4.3.3 and docx4j-export-fo is 3.3.1.

Any idea or solution?

Which is the best way to deployment this kind of application/service that generate a .pdf from .docx merging via docx4j?

Thanks in advance.

[jason]

When you start the JVM cold, the JAXB context needs to be initialised. This may take somewhere between 5 and 20 secs depending on your environment.

So typically you leave the JVM running, ready to respond to requests as they occur. For example, implementing your app as a servlet running in Tomcat or Jetty. Or something like vert.x.

That doesn't explain your 3 minutes though. Maybe your machine is swapping to disk?

You should figure out where the 3 mins is going eg how long until JAXB context init is done, and how much time the export-fo step is taking.

Check your logging is at WARN or ERROR level, not DEBUG.

I would be remiss not to point out that our commercial PDF Converter is much faster than the export-fo method, so that could usefully be part of your solution. See http://converter-eval.plutext.com/

[pedro]

First, thank you for your reply.

Below, you can see the log generated. I don't understand why delay more than 1 minute in "Using Java 6/7 JAXB implementation"

Code: Select all

2017-02-27 11:07:07 INFO  Context:85 - java.vendor=Oracle Corporation
2017-02-27 11:07:07 INFO  Context:86 - java.version=1.8.0_121
2017-02-27 11:07:09 INFO  Context:110 - No MOXy JAXB config found; assume not intended..
2017-02-27 11:07:12 INFO  NamespacePrefixMapperUtils:67 - Using NamespacePrefixMapperSunInternal, which is suitable for Java 6
2017-02-27 11:07:12 INFO  Context:119 - Using Java 6/7 JAXB implementation
2017-02-27 11:08:20 INFO  Context:164 - Not using MOXy; using com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl
2017-02-27 11:08:58 INFO  XmlUtils:193 - setProperty com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl
2017-02-27 11:08:58 INFO  XmlUtils:206 - actual: com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl


Can I improve anything in this point?

BR

[jason]

Seems like JAXB context init is really slow when reading your uber/fat jar from disk. How did you create your fat jar? How big is it? What's in it? Maybe that's the problem....

java -verbose:class might give you some insight.

As previously mentioned, usually the solution would be to:

leave the JVM running, ready to respond to requests as they occur. For example, implementing your app as a servlet running in Tomcat or Jetty. Or something like vert.x.

http://stackoverflow.com/questions/8441 ... w-to-start may also give you some ideas...