cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom Klaasen (TeleRelay)" <tom.klaa...@telerelay.com>
Subject RE: Cocoon scalability continued
Date Wed, 02 Jan 2002 16:02:25 GMT
Our load tests where done on a single server.
IRL there are 2 servers behind a load balancer, but serving 2 sites
together (http://www.scoot.nl is the other one, with comparable load).

Don't know the actual load ATM, since I don't work for that firm
anymore...

tomK



> -----Original Message-----
> From: Lewis, Andrew J [mailto:Andrew.Lewis@jbosc.ksc.nasa.gov] 
> Sent: woensdag 2 januari 2002 16:56
> To: 'cocoon-dev@xml.apache.org'
> Subject: RE: Cocoon scalability continued
> 
> 
> 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
> 
> 

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


Mime
View raw message