cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Homeijer <>
Subject Cocoon scalability continued
Date Wed, 02 Jan 2002 10:03:15 GMT

This mail is a follow-up to the following mails:

(Cocoon 2 RC2 performance disappointment).


(Cocoon 2.0 Scalability Disappointment)

In the last weeks we observed that Cocoon performance and scalability are
greatly influenced by a number of factors, to name a few:
- Complexity of pipelines (slows down pipeline composition)
  > Stefano mentioned to me that entire pipelines can be pooled. 
  > Can anybody give me some directions on how to accomplish this?

- Size of the documents going through the pipeline (slows down translations)
- Size of the documents that will be cached (caching appears to be very time
- Number of templates in the XSL translation (xsl tuning is very difficult)

To tune our C2 based site we tried three ways of implementing our website,
all with different approaches. The approach we thought should be the one
with the best performance/scalability turned out worse than the C1
implementation (performance of the three range from several times slower
than the C1 implementation to 10% faster).

Luckily, with the new component approach it was just a few days work (mainly
changing places of caching and XSL translations) to get a better
performance(10% on the C1 approach, and we think we can get further now we
know which strings to pull. Furthermore we didn't try the generator based
approach yet instead of XSP).

But then again, I don't think every project will get this far... 

and I think that new versions of Cocoon will show a very different
performance/scalability profile (once the new cache,
sitemap approach or new Xalan versions are released), this could also be
dangerous without some sort of performance prediction model.

In the weeks we tried to tune our C2 based site, we went from designing and
implementing to a more trial and error approach in configuring the
pipelines. Because of the unpredictable results (because of complexity or
lack of experience on our side?) and the pressure from our customer the team
spirit went down. Furthermore it's hard to derive best practices or some
golden rule from our work.

Because of this I think it is not enough to have a cache that tunes itself
or a profiler. It will help but only once your site is up and running.
Because of the many ways of implementing a C2 site, I think there should be
some kind of prediction model that shows how to structure functionality in

I don't have a clear idea on what this should look like, but maybe someone
can comment on our experiences.

Michael Homeijer.

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

View raw message