cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Royal <>
Subject Re: Cocoon 2 RC2 performance disappointment
Date Mon, 26 Nov 2001 15:28:14 GMT
On Friday 23 November 2001 02:38 pm, you wrote:
> Next we started a project to perform migration to Cocoon 2. I think we use
> all mechanisms (at least the ones I know) to create a site that performs
> well. But... under heavy load, the performance of the Cocoon 1 site remains
> stable (slow but stable) and the Cocoon 2 site collapses. The initial
> performance of the Cocoon 2 site is higher, but under "heavy load", it will
> not do very much anymore.
> Mechanisms we used:
> - Split pages in multiple parts based on caching posibilities. Ie. parts
> that can use the same cache strategies (ie same key and validity) are
> grouped together.
> - The parts that can be cached are also translated to HTML using XSL as
> much as possible.
> - The XSL files are kept as small as possible. We tried to minimize the
> amount of templates (initially there were about 60 templates).

We just did load testing on our application here a few weeks ago. Things to 
look for:

* Run in debug mode and look for "decomissioning instance of" messages. That 
means that an object pool's maximum size is not large enough and it has 
turned into a factory. Creating & destroying objects for each request *kills* 

* Watch the cachability in logs, and make sure things are being fed from the 
cache. All of our pages are dynamic, and such, none of them can be cached 
100%. I was err'ing in inserting the dynamic data in the generator -> BAD!! 
The I18nTransformer is fairly slow and pages were taking 10s on average to 
come out of cocoon. I reorganized our pipeline and did as much as I could up 
front and cached it (similar to what you said above) and its down to 500ms-2s 
depending on page size and complexity. Its "fast enough" now, but the next 
thing I was going to look at was a GZipSerializer to compress the data going 
over the wire. I'm not sure how else to compact down a selectbox with 500+ 
entries, its just a lot of data :)

* Move static content out of Cocoon's control. I got a *huge* user-perceived 
speedup by moving our static content out of the Cocoon servlet context and 
into its own context (just letting Tomcat serve directly). An even better 
approach would be to use a front-end webserver to serve the static, but 
installing Apache + tomcat + our app would be a bit much wen tomcat + our app 
is doing fine.

On a side note, we deployed our Cocoon-based application at our first 
customer last week and it all went very smoothly! Kudo's to the dev team for 
making such a solid product :)

peter royal ->

To unsubscribe, e-mail:
For additional commands, email:

View raw message