Hi thanks for your answer! My concern is not primary about performance, because documents are generated only a few times per week. And performance is pretty ok, since the cgi script does basicly only start some external programs to convert the document. Currently I'm calling saxon or xalan with this script, because performance was better, than calling it from a pipeline, but I'planning to reimplement these tasks into one pipeline.
I just thought, that there could be a nicer solutions, then doing it with the script. Fop is out of question, because I'm instructed to take a commercial converter for pdf conversion, because of hyphenation, orphans, widows etc. in then output. Regards Dominik -----Urspr�ngliche Nachricht----- Von: John Austin [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 9. Dezember 2003 18:49 An: [EMAIL PROTECTED] Betreff: Re: woody + dynamic document generation "Ulrich, Dominik" <[EMAIL PROTECTED]> wrote: > Hello everyone! > > I'm using cocoon currently for a few weeks now. > My goal is to build a web application, which dynamicly creates > documents (xml -> pdf,rtf,html) for my company. These documents are very large > and need about half an hour to be created (pdf). There are a few things you can do to address performance of the FOP Serializer in particular and Cocoon in general. 1) Check whether your JVM is running the -server version of the JVM. Benchmark both versions (-client and -server) and choose the one that works best for you. The -server one works best for my PDF documents but is not the best choice in all cases. It does not pay off for building Cocoon or Fop using ant. This is an option that has to be coded when you start the Servlet container (Jetty, Tomcat, et. al.). It is NOT the default for all containers, Cocoon's bundled Jetty is one example (see cocoon.sh for example). 2) Make sure you give it enough memory. i) Watch for memory exhaustion on the physical machine e.g. run /usr/bin/top on Linux shows very little free memory, kswapd runs a lot, your java process using lots of memory + Fix this by adding RAM to the system ii) Don't overdo worrying about (iii) as (i) is more important iii) You can control the max and starting heap sizes for Sun's JVM by specifying -Xmx<value1>m -Xms<value2>m to cut down some garbage collection and heap expansion. Value1 is some big number approximating the observed requirement of your workload. Value2 can be some number up to value1 chosen to reduce the overhead of a continually growing heap. 3) If possible, delegate work to other machines. If you have spare capacity, redirect large workloads to a dedicated machine or machines. A dedicated server running 'Jetty' is trivial to set up. 4) If necessary, generate the Formatting Objects file on Cocoon and use FOP stand-alone to create your PDF. This goes against current Cocoon philosophy but it could get the job done by allowing you to move some work off to the user's machine. Try: java -server -cp $whatever org.apache.fop.apps.Fop <and parameters> 5) Special measures are only warranted where there are BIG reasons for taking them. Having users wait half an hour to generate a PDF probably counts as one. 6) Check into different versions of software. I think there were more performance issues in earlier versions of Cocoon and FOP. > I build an front-end with woody in which the user can > choose the document parts. All this is stored in the container. > There are some saxon calls for building the fo file(pdf), > the xml file(html) or the rfk file (for a special rtf converter). > > Here is the ugly part I rather want to change: > > a cgi script is started which calls the rtf converter and a pdf converter(not fop)to > process > the document creation. these are no java apps. > Is there a possibility to do this somehow different? > I want to integrate this somehow into cocoon, but don't know how. > At the moment the user has to leave the browser window open until the end of the > creation > because of the cgi process. I played around with other means of generating docbook documents on Linux. There are some native commands like docbook2pdf on RedHat 9. They might be in C/C++ and therefore faster. Your mileage may vary. In general, I find Cocoon to be excellent although there are issues around FOP that will be solved in the future. > thanks for all ideas > > regards dominik > > ______________________________________________________________________ -- John Austin <[EMAIL PROTECTED]> --------------------------------------------------------------------- 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]
