Ram Krishnamoorthi wrote:
Currently, We are just invoking FOP command directly
from a Shell Script which would call the FOP Command
This means you have the overhead of starting a JVM process for
each individual invoice to process, including all the warm-up
costs. You should think about a custom Java program which
processes a larger batch of files, or about a server based
solution.
I would like to have your opinion on the Performance
that we observe here. The Test Machine we run FOP on
has 2 CPUs and 4 GB RAM. Our Production Machine that
we would be running FOP on soon has 4 CPUs though
There is an absolute limit on memory which a single JVM can manage.
Check the appropriate docs on how to set the memory limits for your
JVM. Optimize the settings in order to get most out of the available
physical RAM.
FOP uses a single thread for rendering a single PDF. You can only
take advantage of multiple CPUs by either running multiple JVMs in
parallel, or by using a custom Java program (command line or server)
which spawns multiple threads. For small input and output, and an
insignificant amount of images, FOP is processor bound rather than
I/O-bound. Including large, high resolution images or large user
font files (CJK) might turn FOP into an I/O-bound process. In any
case there shouldn't be much harm in starting a few more threads
than there are processors, unless you systematically run out of
JVM memory.
Tables take up more memory..do they Impact Performance
significantly?
Probably not. I'm not aware of a systematic study though.
(3) I am using xsl:for-each in 3-4 places in the
Stylesheet to loop through nodes with same Tag instead
of using 'Template Match'..does that matter?
FOP doesn't execute the transformation, you use an XSLT processor
for this purpose, usually the XSLT processor in the Java run time
library. Generally, for all XSLT processor commonly in use currently,
xsl:for-each is as fast as using xsl:apply-templates, and it may
be faster by a tiny, unnoticeable amount. Depending on the structure
f the input XML and the complexity of the transformation, using
xsl:apply-templates may be recommended for better maintainability.
BTW xsl:for-each is *not* a loop in the same sense as in common
procedural programming languages.
Caching a Stylesheet
Check the docs for javax.xml.transform.TransformerFactory.new Templates
and javax.xml.transform.TransformerFactory.Templates.new Transformer.
I doubt you'll notice much of an improvement unless your stylesheets
are somewhat complex and/or larger than a few hundred lines.
Are their other means to Improve Performance?
It depends where the bottleneck is. In your current setup, eliminating
the JVM startup cost is most likely what will get you the most bang for
the buck. System utilities like vmstat and iostat, some simple
instrumentation, or a more advanced profiling will show you where
possible problems hide.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
