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:55:32 GMT
My performance target is 250 requests/second. I can spread that out over multiple servers though.

> ----------
> From: 	Tom Klaasen (TeleRelay)[SMTP:tom.klaasen@telerelay.com]
> Reply To: 	cocoon-dev@xml.apache.org
> Sent: 	Wednesday, January 02, 2002 10:53 AM
> To: 	cocoon-dev@xml.apache.org
> Subject: 	RE: Cocoon scalability continued
> 
> http://www.scoot.be is C2-powered and is tested under quite some load
> (100 requests/sec, IIRC) and has also quite some load IRL. No XSP's,
> indeed, but also no caching (MRUMemoryStore seemed to be leaking in
> those days. Maybe this has improved in the mean time).
> 
> Unless your going to develop an even bigger app, I'd dare to say: go for
> it.
> 
> Success,
> tomK
> 
> 
> > -----Original Message-----
> > From: Lewis, Andrew J [mailto:Andrew.Lewis@jbosc.ksc.nasa.gov] 
> > Sent: woensdag 2 januari 2002 16:46
> > To: 'cocoon-dev@xml.apache.org'
> > Subject: RE: Cocoon scalability continued
> > 
> > 
> > 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
> > 
> > 
> 
> ---------------------------------------------------------------------
> 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