Hi Team, this is an actual thread in the Cocoon user list. There are some _interesting_ questions how to _scale_ Cocoon best.
I know there are better once then I, which can answer this. I'm only the Store guy ;-). TIA Gerhard "Some people say I am a terrible person, I'm not, I have the heart of a young boy, in a jar, on my desk. (Stephen King)" >-----Original Message----- >From: Peter Hargreaves [mailto:[EMAIL PROTECTED]] >Sent: Friday, January 25, 2002 1:57 PM >To: [EMAIL PROTECTED] >Subject: RE: C2 Memory Settings - Xms, Xmx, freememory, and heapsize > > >Hi Gerhard, > >Many thanks for your time and the extra tips. So, following on the same >thread, if you will bear with me? My 'real world' has the following >'special case': > >I want to deploy multiple independent cocoon applications in the same >servlet container (Tomcat 4.0.1). Is this wise? I assume it means that >my servlet container, and my cocoon applications will all be sharing the >same jvm and the same heap. > >Method 1 - I could use sub-sitemaps. But, can this be done while using a >separate WAR file to deploy each application? I couldn't find out how. > >Method 2 - Alternatively I could deploy cocoon within each application's >WAR file. Although this is expensive in hard disk space, I don't mind >the price in return for independence. However, it will result in >multiple cocoon instances and I'm not so sure about multiple instances >sharing the same java heap!! Should I be avoiding this? It might be >incredibly expensive in RAM???!!! > >If I do create multiple instances of cocoon in the same jvm then what >memory settings should I use? > >Xms - the initial size of the jvm heap. There seems to be no issue with >this setting, I just set it to zero to avoid confusion and let the jvm >increase the heap as it needs it. > >Xmx - the maximum size of the jvm heap. Again, I just set this to the >maximum my system can make available to my servlet container and cocoon >applications. > >But, I now have multiple instances of the store-janitor (don't I?), they >are all monitoring the same jvm heap, but each with their own >'heapsize', 'freememory', 'cleanupthreadinterval' and 'priority' setting >and running asynchronously. They will each set-off finalization and the >garbage collector every interval, won't they? Although each >cleanupthreadinterval could be increased, they will not be synchronised, >so could all fire off close to each other leaving an unreasonable gap. >This worries me, could it explain why my garbage collector occasionally >takes over the system and crashes it (observed through Optimizeit)? > >Each store-janitor has its own store to look after, but is it possible >to balance their demands without one taking outright priority over the >others? > >store-janitor parameter 'heapsize' - Should all the heapsize params be >set the same, or is there a case for setting them differently? I think >the same, unless one application should be more concerned about it's use >of memory than another. > >store-janitor parameter 'freememory' - Should all these be the same, or >is there a case for setting them differently on each store-janitor. >Again I think the same, as the results of setting them differently are >harder to imagine! > >It seems to me that I should be avoiding multiple cocoon instances under >the same jvm because the store-janitor is not really designed for it. >Even if Xms is massive because of the over enthusiasm of garbage >collection. Is this a reasonable conclusion? > >By the way, I tried just playing with the parameters and wasn't getting >very far, but now I've become analytical as well, I'm making progress - >in reducing my RAM requirement. > >Yes, Gerhard please make use of my notices for the documentation if you >can but I suggest you use the following caveat: "Listen to what I mean, >not what I say." - pdh. > >Oh, I've just turned off logging and my application is transformed from >"Sluggish" to "Greased Lightning"! - Wow!! > >Looking forward to your comments Gerhard. Comments from others also welcome. > >Regards, >Peter. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
