cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lewis, Andrew J" <Andrew.Le...@jbosc.ksc.nasa.gov>
Subject RE: Cocoon scalability continued
Date Wed, 02 Jan 2002 15:45:58 GMT
I am getting ready to recommend Cocoon for a very large project where it will need to handle
immense load. In reality, XSP is more than I need and I don't expect to be using it. From
what I have read, most of the scalability problems seem to be XSP related - can anyone confrim
or reject that thought for me? 

> ----------
> From: 	Michael Homeijer[SMTP:M.Homeijer@devote.nl]
> Reply To: 	cocoon-dev@xml.apache.org
> Sent: 	Wednesday, January 02, 2002 5:03 AM
> To: 	'cocoon-dev@xml.apache.org'
> Subject: 	Cocoon scalability continued
> 
> Hi,
> 
> This mail is a follow-up to the following mails:
> 
> (Cocoon 2 RC2 performance disappointment).
> http://www.mail-archive.com/cocoon-dev@xml.apache.org/msg06455.html
> 
> and
> 
> (Cocoon 2.0 Scalability Disappointment)
> http://www.mail-archive.com/cocoon-dev@xml.apache.org/msg06751.html
> 
> 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
> consuming)
> - 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
> C2.
> 
> I don't have a clear idea on what this should look like, but maybe someone
> can comment on our experiences.
> 
> TIA,
> Michael Homeijer.
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message