Page: http://wiki.cocoondev.org/Wiki.jsp?page=ConfiguringTheLogs , version: 16 
on Thu May 22 19:09:08 2003 by JoergHeinicke

- * be aware that the deault loglevel at logkit.xconf is ERROR
+ * be aware that the default loglevel at logkit.xconf is ERROR
?                       +



Page: http://wiki.cocoondev.org/Wiki.jsp?page=People , version: 135 on Thu May 
22 19:29:01 2003 by MichaelTiffany

+ * [Michael Tiffany|MichaelTiffany] -- Cocoon fanatic/Web developer/Full-time 
social critic


Page: http://wiki.cocoondev.org/Wiki.jsp?page=MichaelTiffany , version: 2 on 
Thu May 22 19:31:34 2003 by MichaelTiffany

- I've been in love with Cocoon from the moment I laid eyes on it. I'm a 
self-employed slacker. Cocoon has been a blessing for two sites I've been 
involved in: 
+ I've been in love with Cocoon from the moment I laid eyes on it. I'm a 
self-employed slacker. Cocoon has been a blessing for two sites I've been 
involved in creating/maintaining: 
?                                                                               
                                                                              
+++++++++++++++++++++



Page: http://wiki.cocoondev.org/Wiki.jsp?page=SamplesRefactor , version: 17 on 
Thu May 22 19:04:36 2003 by JoergHeinicke

- |poi| |no|no|I'm working on them (JH)
+ |poi| |yes|yes|The 2 samples in CVS work. Cocoon 2.0 had some more, I'm 
working on them. (JH)


Page: http://wiki.cocoondev.org/Wiki.jsp?page=FOPTuningGuide , version: 4 on 
Thu May 22 19:28:59 2003 by JoergHeinicke

- This guide is written by a semi competent sys admin who has tested FOP and 
read around the mailing lists to discover what to do. You may be able to 
achieve much more...if so please add to this guide
+ This guide is written by a semi competent sys admin who has tested FOP and 
read around the mailing lists to discover what to do. You may be able to 
achieve much more ... if so please add to this guide.
?                                                                               
                                                                                
       +   +                              +

- !!Tuning to exploit your hardware  
?                                  --

+ !!Tuning to exploit your hardware
- Having played around with FOP transformations i have found that large 
xml/xhtml to PDF transformations are very memory hungry. On a default tomcat 
install the transformations don't have to get very large before the java 
virtual machine (JVM) runs out of memory (i think jvms default to a max heap of 
256m, i may be wrong).
?                                               ^                               
                                                                                
                                                                                
                        ^       ^^^                                 ^

+ Having played around with FOP transformations I have found that large 
xml/xhtml to PDF transformations are very memory hungry. On a default tomcat 
install the transformations don't have to get very large before the java 
virtual machine (JVM) runs out of memory (I think JVMs default to a max heap of 
256m, I may be wrong).
?                                               ^                               
                                                                                
                                                                                
                        ^       ^^^                                 ^

- To tune up a tomcat install in order to exploit all the memory your  machine 
has you are first going to have to edit the catalina.sh file in the tomcat bin 
directory. You want to tune the CATALINA_OPTS variable so it sets up your jvm 
with as much memmory as you can spare (remeber to leave at least 20% for the 
operating system).
?              ^                                                     -          
                                                                                
                                                                        ^^^     
           -

+ To tune up a Tomcat install in order to exploit all the memory your machine 
has you are first going to have to edit the catalina.sh file in the tomcat bin 
directory. You want to tune the CATALINA_OPTS variable so it sets up your JVM 
with as much memory as you can spare (remember to leave at least 20% for the 
operating system).
?              ^                                                                
                                                                                
                                                                       ^^^      
                                     +

- just before it starts echoing your CATALINA_BASE, CATALINA_HOME etc variables 
(catalina.sh has changed between versions of tomcat so your mileage may vary)
? ^

+ Just before it starts echoing your CATALINA_BASE, CATALINA_HOME etc variables 
(catalina.sh has changed between versions of tomcat so your mileage may vary).
? ^                                                                             
                                                                             +

- This line tells tomcat to fire up in a JVM with 256meg  of memory (-Xms) and 
that that jvm can grow upto 1800meg (-Xmx). It also tells it to incrementaly 
garbage collect (-Xincgc) so as not to slow down too much when it decides it 
needs to look through all its memmory heap for stuff it can throw away. An Xmx 
of 1800m is about the maximum heap size you can have on a windows or linux box 
as the jvm can't grow any larger [Java bug 
report|http://developer.java.sun.com/developer/bugParade/bugs/4435069.html]. 
You may be able to get up close to 4 gig on a 32 bit sparc box. I have no idea 
about 64 bit systems. I have tested this with suns jdk, bea's ibm and blackdown 
and they all break close to 1900m max heap size.
?                 ^                                                             
         ^^^                                                                    
                                                                                
                         -                                                      
                                                                                
                                                                                
                                                                                
                                                                            ^   
 ^^^  ^     ^^^     ^

+ This line tells Tomcat to fire up in a JVM with 256meg  of memory (-Xms) and 
that that JVM can grow upto 1800meg (-Xmx). It also tells it to incrementally 
garbage collect (-Xincgc) so as not to slow down too much when it decides it 
needs to look through all its memory heap for stuff it can throw away. An Xmx 
of 1800m is about the maximum heap size you can have on a windows or linux box 
as the jvm can't grow any larger [Java bug 
report|http://developer.java.sun.com/developer/bugParade/bugs/4435069.html]. 
You may be able to get up close to 4 gig on a 32 bit sparc box. I have no idea 
about 64 bit systems. I have tested this with Suns JDK, Bea's IBM and Blackdown 
and they all break close to 1900m max heap size.
?                 ^                                                             
         ^^^                                                             +      
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                            ^   
 ^^^  ^     ^^^     ^

- !!Predicting FOP transformation load 
?                                     -

+ !!Predicting FOP transformation load
- Unfortunately there seems to be no way of predicting how much memory a FOP 
transformation will need. It can vary depeneding on what your stylesheet looks 
like. For instance it is advised on the mailing lists not to nest tables as 
this greatly increases the size of the DOM tree needed to represent your FO 
transformation.
?                                                                               
                                        -

+ Unfortunately there seems to be no way of predicting how much memory a FOP 
transformation will need. It can vary depending on what your stylesheet looks 
like. For instance it is advised on the mailing lists not to nest tables as 
this greatly increases the size of the DOM tree needed to represent your FO 
transformation.
- An example of FOPs thirst for memory can be seen by an example transfromation 
we did. We have a project to convert properly formated xhtml articles to pdf. 
An export of all articles produced a 3meg xml file. When we did a simple 
transformation on this to pdf it peaked at   530meg of memory and took 600 
seconds of processor time (it was a 4 processor machine so actually only took 
about 3 minutes). This produced a 920page 1.6meg  pdf file. Obviously this is a 
stupid example as there would rarely be a need to produce a 920 page pdf file. 
However this was as simple a transformation as we could make, a more complex 
transformation including tables, complex formatting etc etc  on a smaller 
document may require just as much memory.  
?                                                                       -       
                                                       ^^^^^             ^^^    
                                        ^^^                                     
                 ^^^             --                                             
                                                                                
                                 ^^^^                                           
                                                     ^^^                        
 ----------                                                                     
                                        -

+ An example of FOPs thirst for memory can be seen by an example transformation 
we did. We have a project to convert properly formatted XHTML articles to PDF. 
An export of all articles produced a 3meg XML file. When we did a simple 
transformation on this to PDF it peaked at 530meg of memory and took 600 
seconds of processor time (it was a 4 processor machine so actually only took 
about 3 minutes). This produced a 920page 1.6meg PDF file. Obviously this is a 
stupid example as there would rarely be a need to produce a 920 page PDF file. 
However this was a transformation as simple as we could make, a more complex 
transformation including tables, complex formatting etc etc on a smaller 
document may require just as much memory.  
?                                                                      +        
                                                    +   ^^^^^             ^^^   
                                         ^^^                                    
                  ^^^                                                           
                                                                                
                                ^^^                                             
                                                   ^^^                          
              ++++++++++

- I plan on producing a demo app that uses xsp to dynamically generate xml of 
various lengths,  this will then be transformed to pdf. This way you will be 
able to see how large a file your server is capable of transforming.       
+ I plan on producing a demo app that uses XSP to dynamically generate xml of 
various lengths, this will then be transformed to PDF. This way you will be 
able to see how large a file your server is capable of transforming.
- 
- 
- 
- 
- 


Reply via email to