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
|