xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Delmelle <andreas.delme...@telenet.be>
Subject Re: Fop 0.20.5 vs Fop Trunk Performace
Date Tue, 12 Feb 2008 19:21:56 GMT
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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Mime
View raw message