You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by Jignesh-NX01880 Kapadia <Ji...@us.michelin.com> on 2004/01/12 15:01:04 UTC
FOP being very slow.
Hi ,
We are having here. We are using FOP here for our application it generates
a 81 page PDF in the output. It takes a very long time to generate it almost
more than 1 minute. The user acceptance criteria is 15-20 seconds for such big
PDF. if say more than 20 user try to generate the PDF file then we reach peak
with our JVM and after that no user can do anything. We are using following FOP
driver class.
org.w3c.dom.svg.SVGDocument.
The websphere instance on which the application is running has 512MB of JVM
size. We need that application can sustain a load of 60 user at a time to
generate PDF document. The server has RAM of 3GB. The application is built with
struts. Is there any way that FOP is can be made less memory intensive? so that
it will not use much JVM but use CPU rather?
You answer will really a help,
Thanks,
Jignesh
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-user-unsubscribe@xml.apache.org
For additional commands, e-mail: fop-user-help@xml.apache.org
Re: FOP being very slow.
Posted by John Austin <jw...@sympatico.ca>.
On Mon, 2004-01-12 at 10:31, Jignesh-NX01880 Kapadia wrote:
> Hi ,
> We are having here. We are using FOP here for our application it generates
> a 81 page PDF in the output. It takes a very long time to generate it almost
> more than 1 minute. The user acceptance criteria is 15-20 seconds for such big
> PDF. if say more than 20 user try to generate the PDF file then we reach peak
> with our JVM and after that no user can do anything. We are using following FOP
> driver class.
>
> org.w3c.dom.svg.SVGDocument.
>
>
> The websphere instance on which the application is running has 512MB of JVM
> size. We need that application can sustain a load of 60 user at a time to
> generate PDF document. The server has RAM of 3GB. The application is built with
> struts. Is there any way that FOP is can be made less memory intensive? so that
> it will not use much JVM but use CPU rather?
This is a long-running issue with FOP and there is no immediate
relief. I believe that performance will improve when the 1.0
version is released but there is no predictable release date
at this time.
Here are a couple of ideas but your mileage may vary:
1) Use the best version of FOP that works for your app.
0.20.5 is the highest stable release of FOP
2) Use the best version of the JVM that works for your app.
1.4.2_? from Sun appears to be pretty good. Some older
postings indicate that Sun's 1.3 is faster than 1.2 and
you should measure and compare 1.3 to 1.4
IBM also have their own versions (you are running websphere).
3) If using Sun and not using Windows, compare the java -client and
java -server version of the JVM. In some cases, 'java -server'
may perform slightly better than 'java -client' (10-20 percent?).
4) If you have time to nit-pick, you can profile the memory use of
your app and select values for -Xmx and -Xms that reduce heap
expansion and garbage collection. As you say your JVM is limited
to 512Mb, I would adjust this upwards.
5) Can you distribute processing across a pool of servers ? Hardware
is cheap and you can buy a lot of power for the price of a commercial
XSL-FO processing solution.
6) Search the list archives for more info on performance.
I like the Apache version of the archive even though search
results are displayed in random order.
http://nagoya.apache.org/eyebrowse/SummarizeList?listName=fop-user@xml.apache.org
7) Do your times include XSLT transformations ? Perhaps these can be
improved. Compare times required to do separate command-line
XSLT transformations and FOP formatting with time taken to do
integrated processing. If the XSLT times are large w.r.t. FOP
you may be able to find improvements for the XSLT portion.
--
John Austin <jw...@sympatico.ca>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-user-unsubscribe@xml.apache.org
For additional commands, e-mail: fop-user-help@xml.apache.org
Re: FOP being very slow.
Posted by Chris Bowditch <bo...@hotmail.com>.
Jignesh-NX01880 Kapadia wrote:
> Hi ,
> We are having here. We are using FOP here for our application it generates
> a 81 page PDF in the output. It takes a very long time to generate it almost
> more than 1 minute.
What sort of system are you running? how many CPUs, what o/s, (you
mentioned memory below), and what version of FOP?
The figures you quote sound reasonsable for a basic single CPU system. I
dont think you can do a lot to speed up processing time for a single
document. Actually I found FOP to be one of the faster XSL-FO formatters
around (mainly due to the fact that keeps and other difficult features
are missing)
> The user acceptance criteria is 15-20 seconds for such big
> PDF. if say more than 20 user try to generate the PDF file then we reach peak
> with our JVM and after that no user can do anything. We are using following FOP
> driver class.
>
> org.w3c.dom.svg.SVGDocument.
I dont quite follow this bit. Are you saying you are creating SVG and
XSL-FO in a DOM before presenting it to FOP for processing. This seems
somewhat inefficient.
> The websphere instance on which the application is running has 512MB of JVM
> size. We need that application can sustain a load of 60 user at a time to
> generate PDF document. The server has RAM of 3GB. The application is built with
> struts. Is there any way that FOP is can be made less memory intensive? so that
> it will not use much JVM but use CPU rather?
There have been some changes made to improve the memory consumption of
tables, but these changes have not been included in any release of FOP.
You will have to download the source from CVS maintenance branch and
compile it yourself.
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-user-unsubscribe@xml.apache.org
For additional commands, e-mail: fop-user-help@xml.apache.org