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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
