On Mon, 2004-01-12 at 13:10, Jignesh-NX01880 Kapadia wrote:
> I had attached one .TXT file.in my last e-mail. That was the main
> generate method which generates the output to write in to a .PDF file. I am
> attaching again.
Doh! Sorry I missed that.
>>From the listing I note you are running on Windows, so
you won't be able to use the 'java -server' optimizing JVM.
Performance hint:
The Cocoon people say that logging kills performance. Be prepared to
turn it down if not completely off.
One item that can be changed in your program:
Instead of writing the transformer output to a file using the
second arg to transformer.transform()
and feeding the written XML file back in through driver.setInputSource()
Try the following:
File xsltFile2 = new File( xsltFileName2);
Source xsltSource2 = new StreamSource(xsltFile2);
Transformer trans2 = transFact.newTransformer( xsltSource2 );
Source xmlSource2 = new StreamSource(out1);
//*** Generate PDF file ***
File pdfFile = new File( namePart + ".pdf" );
Driver driver = new Driver();
driver.setRenderer( Driver.RENDER_PDF );
try {
driver.setOutputStream( new java.io.FileOutputStream( pdfFile ) );
Result res = new SAXResult(driver.getContentHandler());
trans2.transform( xmlSource2, res );
}
catch( IOException ioe ) {
>>From your listing I note that you recreate the Transformer and Driver
objects for every invocation. (In a servlet) It is possibile to re-use
the XSL transformation which may or may not be useful to you. I can't
tell you how much benefit that would provide because I have to work from
measurements of execution times of your XSLT vs your FOP formatting.
For comparison, I have a program which reads an XML file generated from
a database and applies an XSLT transformation which produces an XSL-FO
document. Rather than create the XSL-FO file, my program sends the
XSLT output to the FOP driver.
This program read an XSL file representing 400 names and addresses and
generated a customized form letter in a PDF file of some 800 pages.
As I recall the program ran in less than one minute on a 800 MHz Athlon
with 512Mb SDRAM.
> Subject: Re: Re[2]: FOP being very slow.
> Author: [EMAIL PROTECTED]
> Date: 1/12/2004 10:52 AM
>
> On Mon, 2004-01-12 at 12:09, Jignesh-NX01880 Kapadia wrote:
> > Hi Chris & John ,
> >
> > Thanks a lot for your responses. I' m answering your questions and the
> > info
> > you have asked as below.
> >
> > For Chris
> >
> > This application was developed by third party for us and delivered to us.
> Now
> > since it is very slow we need to modify it to make it less memory intensive.
> The
> > approach they have used is as follows.
> >
> > 1) The data retrieved from database is converted in to XML.
> >
> > 2) That XML file with the help of -it is converted in PDF.
> >
> > 3) The FOP version used is 0.20.4rc
>
> Of more interest, which JVM and what version are you using ?
>
> Does it employ 'java -server' version of the JVM ?
>
> >
> >
> > For John,
> >
> > we do have load balancing of application servers. Both the servers have
> single
> > CPU and JVM size on each can be extended to 1GB at max. We have XSLT
> > transformations also as I mentioned above in Chris's response.
Throwing hardware at a slow implementation is not my favorite solution
but it is always an option. You can get an inexpensive Linux box with
dual processors, a fast disk and several Gigs of DDR memory for under
USD $3000.
> >
> > Do you guys think 0.20.5 will have a better performance time then 0.20.4rc.
>
> It's worth measuring in your environment.
>
> > I am attaching a sample code from one of the main method which generates PDF
> > file from our PDF Servlet. and please do suggest any alternative if you
> > think
> it
> > can be done in better way to improve processing speed.
> >
> >
> >
> >
> >
> > and then it is written to output as follows:
> >
> >
> >
> Following 'generate' is part of the package written for you ?
>
> I don't recognize it off the top of my head.
>
>
> > byte[] content = generate(contextRoot, contextRootURL, generateParams,
> > templateType, templateName,
> > targetLanguage, xmlPriceBook, cover, pdfCharts, false);
> >
> > // session.setAttribute("LAST_PDF", content);
> > File outFile = new File(baseDirectory + "cache/" +
> > userProfile.getUserId() + ".pdf");
> > FileOutputStream 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]
