From cocoon-dev-return-20508-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org Wed Jan 02 13:57:48 2002 Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 83651 invoked by uid 500); 2 Jan 2002 13:57:47 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 83640 invoked from network); 2 Jan 2002 13:57:46 -0000 From: "Carsten Ziegeler" To: Subject: RE: Cocoon scalability continued Date: Wed, 2 Jan 2002 14:59:22 +0100 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <9916289167D2D411BD0700508BB4A527E66FA4@dvntex01.devote.nl> X-MIMETrack: Itemize by SMTP Server on PBSN1/Systeme und Netzwerke(Release 5.0.8 |June 18, 2001) at 02.01.2002 14:57:45, Serialize by Router on PBSN1/Systeme und Netzwerke(Release 5.0.8 |June 18, 2001) at 02.01.2002 14:57:45, Serialize complete at 02.01.2002 14:57:45 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Michael Homeijer wrote: > > 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? Do you mean pooled? AFAIK this is not possible. Complete pipelines can be cached but not pooled. Carsten > > - 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