Re: FOP being very slow.
John Austin wrote: and similar treatment for the StreamSources used to read in the XML and XSLT files. That's usually uncritical, because XML parsers tend to buffer themself. IIRC recent Xerces uses an 8k buffer by default (which means you get long stretches of XML text as a series of characters() events, each dumping 8k text on you). J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP being very slow.
On Tue, 2004-01-13 at 17:49, Jeremias Maerki wrote: > Talking about performance: It might be a good idea to buffer to > OutputStream. > > driver.setOutputStream(new BufferedOutputStream(new java.io.FileOutputStream( > pdfFile ))); > > On 12.01.2004 21:51:09 John Austin wrote: > > driver.setOutputStream( new java.io.FileOutputStream( pdfFile ) ); Well spotted! It also needs: java.io.PrintWriter pw = new java.io.PrintWriter( new java.io.BufferedWriter( new java.io.FileWriter( inputFile ) ) ); and similar treatment for the StreamSources used to read in the XML and XSLT files. There might be some improvement there, but it is down near the noise. -- John Austin <[EMAIL PROTECTED]> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP being very slow.
Talking about performance: It might be a good idea to buffer to OutputStream. driver.setOutputStream(new BufferedOutputStream(new java.io.FileOutputStream( pdfFile ))); On 12.01.2004 21:51:09 John Austin wrote: > driver.setOutputStream( new java.io.FileOutputStream( pdfFile ) ); Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: FOP being very slow.
Yes, logging appears to be overdone within FOP, even if a NULL logger object is chosen, a lot of function calls are still being made. I haven't researched Xalan much yet, but their system may be a good guide on the amount of logging appropriate for our system. Glen --- John Austin <[EMAIL PROTECTED]> wrote: > > I also pointed out that LOGGING is a performance > hog. This is > mentioned on the Cocoon list from time to time. In > one case > I got a 20% improvement for an 80 page PDF. > __ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP being very slow.
On Jan 13, 2004, at 10:33 AM, John Austin wrote: I also pointed out that LOGGING is a performance hog. This is mentioned on the Cocoon list from time to time. In one case I got a 20% improvement for an 80 page PDF. Just out of curiosity, is there a way (perhaps via avalon?) of logging every nth (10th, 100th, 1000th, etc.) rendering? That way, one might be able to gather aggregate data, but not have as much of a performance penalty. Web Maestro Clay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: FOP being very slow.
On Mon, 2004-01-12 at 20:36, John Austin wrote: In summary, I sent him my sample program and then reworked some of that program to eliminate communication through files. The sample program reads an external XML file generated from an Access DataBase. Transformation 1 generates a DOMResult which contains up to about 400 records from the DB. They only add about 1k each to the memory requirements. Transformation 2 reads a new DOMSource( theDOMResult.getNode() ); and generates a SAXResult() that uses the FOP Driver to write a PDF file. This demonstrates enough performance improvements to cut down his execution time significantly. I also pointed out that LOGGING is a performance hog. This is mentioned on the Cocoon list from time to time. In one case I got a 20% improvement for an 80 page PDF. When he absorbs this, (and if he comes back) I might point him towards some material on servlets and re-using his compiled XSLT stylesheets. -- John Austin <[EMAIL PROTECTED]> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: FOP being very slow.
On Mon, 2004-01-12 at 19:56, Roland Neilands wrote: > > Well we are running this application on UNIX machines. From where did you > > get > > hint that its running on windows.. Then we can use the " java -server" > > optimizing JVM. But where exactly to use it. > > fop.sh, last line, just add " -server" after "java" I forgot that he is running in websphere. Anyone know which servlet container is used by websphere ? Does it use the SUN or IBM SDK ? [Sent him a program offline ... and explained that I saw a DOS (I mean WINDOWS) file name in his Code.] -- John Austin <[EMAIL PROTECTED]> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: FOP being very slow.
> Well we are running this application on UNIX machines. From where did you > get > hint that its running on windows.. Then we can use the " java -server" > optimizing JVM. But where exactly to use it. fop.sh, last line, just add " -server" after "java" Cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP being very slow.
Stream fos = new FileOutputStream(outFile); > > fos.write(content); > > fos.close(); > > > > response.sendRedirect(baseHTTP_URL + "cache/" + > > userProfile.getUserId() + ".pdf"); > > So you build the file, write to disk and then redirect the user to > that file. Useful only if the user access the result more than once > AND there isn't any caching on your server or the browser. > > > Thanks and your help will be really appreciated, > > > > Jignesh > > I would look again at the FOP Servlet examples and also look at the XSLT > transformations to make sure they are not poor performers. > > > > > > Reply Separator > > Subject:Re: FOP being very slow. > > Author: [EMAIL PROTECTED] > > Date: 1/12/2004 9:18 AM > > > > 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 > > __ -- John Austin <[EMAIL PROTECTED]> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: FOP being very slow.
>I had attached one .TXT file.in my last e-mail
The code sample you sent is OK.
A remark :
"org.apache.fop.apps.Driver" : this is the FOP driver
"Class.forName("org.w3c.dom.svg.SVGDocument");" loads the SVGDocument
class. It might be used by FOP to render SVG (vector) graphics. I don't
see why it is helpful to write this line here.
As John said it before, you must determine what takes time and memory :
XSLT transformation or PDF rendering. While rendering, it is difficult to
know what happens, but you should try to desactivate charts and see what
happens. If your charts are SVGs, you should try plainer shapes.
Mathieu.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP being very slow.
Jignesh-NX01880 Kapadia wrote: Do you guys think 0.20.5 will have a better performance time then 0.20.4rc. I believe there is about a 10% performance improvement between 0.20.4 and 0.20.5 due to revised property handling. Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: FOP being very slow.
>Is there any way that FOP is can be made less memory intensive? Memory usage is discussed here : http://xml.apache.org/fop/running.html#memory I've encountered memory problems because my pdf included large SVG graphics. I've used smaller graphics, rather than big ones. SVG rendering is still slow, but at least memory consumption is smaller. >org.w3c.dom.svg.SVGDocument This is not a FOP driver class, this is a Java representation of a SVG document (extending org.w3c.dom.Document). If you want to handle SVG graphics before rendering, you'd better use a SAX parser, if possible, rather than creating a SVGDocument. You'll gain speed and memory. But it won't change the rendering performances. Mathieu. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP being very slow.
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]
Re: FOP being very slow.
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
