"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]
