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/[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
