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