On Feb 12, 2008, at 17:06, Puppala, Kumar (LNG-CON) wrote:
Hi Kumar
We are currently using FOP 0.20.5 on our production boxes and
intend to use the latest FOP at some point this year. As such, we
are trying to gauge performance improvements between the two.
However, I am finding that the new FOP is taking more time to
render than the old one. The options used to run the FOP (both old
and new) are as shown below:
Just to be sure: which revision of the trunk are you trying out?
As Jeremias already pointed out, make sure that at least the
FopFactory is instantiated only once (that was the whole point of its
inception: to save time on reloading resources that can be shared
between multiple runs).
Apart from that, focusing purely on FOP Trunk, if you know how to
narrow it down to specific methods/calls that cause the increase in
processing time that would help us a lot.
Small question: Did you, by any chance, also try different JVM
versions? Different platform?
/usr/local/jvta/jre1.6.0_02/bin/java -Djava.endorsed.dirs=/usr/
local/java/pkgs/jmx1.0.1 -server -Xms128m -Xmx1024m -
XX:MaxPermSize=128m -verbose:gc -XX:+PrintGCDetails -XX:
+PrintGCTimeStamps -DJMX_1_2=true -D -Sqds_fop_dev5_001 -javaagent:/
opt/wily/Agent.jar -Dcom.wily.introscope.agentProfile=/l-n/app/
sysman/wily/default/Agent_tier1.profile -
Dcom.wily.introscope.agentName=FOP -Dpid=11403
com.lxnx.ols.qds.fop.gen.server.FOPServer
Do you know which XML parser / XSLT processor gets used at runtime?
Not necessarily to shift the blame, but if you can check whether
substituting one of those helps, that would again be very helpful.
<snip />
Here are my findings after running:
1) After server startup, the initial transactions are not
that far apart from those obtained using old FOP. However, as time
progresses, I do see the time for the same transactions increases.
After about 15 such iterations, the processing time almost doubles.
So, (again focusing on FOP Trunk) this would mean that the processing
time increases with the number of runs, or do I interpret this wrong?
In local tests I ran here, with two concurrent threads and a shared
FopFactory instance, the processing time remains quite stable for me
(test run on Apple JVM 1.5 using a document that generates two page-
sequences (=2+69 pages; the larger page-sequence contains forced
breaks for each page))
2) I do see a lot of garbage collection happening in the new
FOP. The collection times are also very high. I am hereby attaching
the garbage collection stats for both the old and new FOP for about
the same number of transactions (refer to newFop_SL.stdout.txt and
oldFop_SL_stdout.txt). Also a thread dump for the server running
new FOP is provided (threadDump_newFop.txt).
3) After using jmap and jhat to analyze the heap, I do see a
lot of objects consuming lot of memory in the new FOP. I am hereby
providing a spreadsheet containing Heap histograms for both the old
and new FOP for the same load (refer to HeapObjects.xls). Also, the
jmap output for the server using old and new FOP is provided (refer
to oldFopMap.txt and newFopMap.txt)
4) Documents containing lots of Images are rendered amazingly
fast (about 85% improvement).
That last bit is certainly good to know.
The high ratio of GC is also to be expected, since both during
parsing and layout, a lot of short-lived objects are created. FOP
0.20.5 simply offered the JVM less opportunity to clean up any mess.
Come to think of it: are your images stored on a local disk, or is
there any network traffic involved that might explain the increasing
lag...?
HTH!
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
