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]
