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:[EMAIL PROTECTED]] > Sent: woensdag 2 januari 2002 16:56 > To: '[EMAIL PROTECTED]' > 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:[EMAIL PROTECTED]] > > Reply To: [EMAIL PROTECTED] > > Sent: Wednesday, January 02, 2002 10:53 AM > > To: [EMAIL PROTECTED] > > 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:[EMAIL PROTECTED]] > > > Sent: woensdag 2 januari 2002 16:46 > > > To: '[EMAIL PROTECTED]' > > > 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:[EMAIL PROTECTED]] > > > > Reply To: [EMAIL PROTECTED] > > > > Sent: Wednesday, January 02, 2002 5:03 AM > > > > To: '[EMAIL PROTECTED]' > > > > 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: [EMAIL PROTECTED] > > > > For additional commands, email: [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, email: [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, email: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
