Very cool...I wasn't sure...thanks! > ---------- > From: Morrison, John[SMTP:[EMAIL PROTECTED]] > Reply To: [EMAIL PROTECTED] > Sent: Thursday, January 03, 2002 8:59 AM > To: '[EMAIL PROTECTED]' > Subject: RE: Cocoon scalability continued > > > > > -----Original Message----- > > From: Lewis, Andrew J [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, 03 January 2002 1:53 pm > > To: '[EMAIL PROTECTED]' > > Subject: RE: Cocoon scalability continued > > > > > > > > > > > ---------- > > > From: Stefano Mazzocchi[SMTP:[EMAIL PROTECTED]] > > > Reply To: [EMAIL PROTECTED] > > > Sent: Wednesday, January 02, 2002 1:01 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: Cocoon scalability continued > > > > > > "Lewis, Andrew J" wrote: > > > > > > > > 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? > > > > > > First disclaimer: I don't have first-hand numbers on big > > machines. But I > > > made some small tests on my machine. Some results are obvious, some > > > might not be. > > > > > > 1) XSLT is what makes the difference: there are several > > ways of doing > > > the same stuff in XSLT, test the difference between them. > > > > > understood - I've seen this in the past. > > > > > 2) logging kills performance. Consider disabling logging > > entirely from > > > Cocoon (leave only the ERROR channel) and let Apache or the servlet > > > container log accesses and stuff. > > > > > not a woe isolated to Cocoon. > > > > > 3) consider turning your XSPs into generators by hand and call them > > > directly. Don't need to do this for all pages, but only for > > those who > > > are heavy loaded. > > > > > I'm actually planning on using generators exclusivly - no XSP. > > > > > 4) use a transparent proxy in front of your web server: the fastest > > > response is the one that is not even processed. Cocoon is > > *very* slow > > > (compared to a proxy server) to read resources such as > > stylesheets and > > > images. A transparent proxy (SQUID, for example, don't use Apache's > > > mod_proxy because is not HTTP/1.1 fully compatible and disables > > > connection keep-alive). Make sure you tune how long the > > static resources > > > that Cocoon "read"s from the sitemap are cached (look into > > the readers > > > code to find out more). > > > > > I'm probably Wintel bound as a production platform - I'll > > have to look at my options for this. > > Squid can be run on windows - check out either Cygwin or the Squid.org site > (it has links to a compile of Squid as a NT service). > > > > 5) consider browser-dependent targetting to perform > > client-side XSLT: > > > Cocoon is *very* fast if it doesn't do transformations. IE > > 5.5 and 6 are > > > pretty compliant and might be something around 30% of your hits > > > (probably more on some popular public web sites like > > Nasa's): reducing > > > one/third of the transformations might speed up a *LOT*. > > > > > Defintately a good idea - I hadn't been planning this, but > > I'll give it a serious look. > > > > > 6) consider using a good JVM on a good OS. Scalability is a very > > > different beast than pure speed: an Apple DualG4 866 seems > > to run faster > > > than a Sun Enterprise 4500 (and costs a fraction), but try > > hitting them > > > with 2000 concurrent cocoon requests. > > > > > Again, probably Wintel bound, but high end wintel - SMP, lots > > of RAM, RAID. I can defintely look at VMs though. There are several. > > > > > 7) fine-tune your cacheable logic and make sure you revert > > control: if > > > you have a database, instead of going to check if the stuff > > > has changed, > > > write some triggers that let your database tell Cocoon when > > and what was > > > updated. Consider writing your own 'database-view' component that is > > > updated by the database directly when something changes. Of > > course, you > > > do this only if you think that caching has some effect > > since the current > > > cache system is not yet adaptive. > > > > > I'll look at this - the high load section may not be heavily > > database bound, os it might not be needed, but cool idea anyway. > > > > > 8) fine-tune your JVM settings (max heap-size, initial memory) > > > > > always :) > > > > > 9) fine-tune the cocoon settinigs for the store and the other stuff > > > (maybe others might give suggestions on the numbers here, I > > can't really > > > tell since I didn't write those parts. In the future, hopefully, the > > > system will tune itself up) > > > > > This is the voodoo I don't have a solid feel for yet. > > > > > 10) consider prerendering or time-based batch-process the > > static parts> > > > of your site: PDF reports, rasterized SVG graphs or things > > that change > > > regularly. > > > > > if I am able to prerender entire sections - is there any > > value at that point in serving them up via Cocoon versus > > directly via the web server? > > > > > and finally > > > > > > 11) keep the pipelines small. Building a pipeline has a cost that is > > > proportional with the amount of components it has. > > > > > I'd seen the mentioned on the lists recently - definately. > > > > > In the future, we might try to change this by allowing the entire > > > pipelines to be pooled, and not the single components, > > anyway, this is > > > stuff that needs internal changes. > > > > > > So hope this helps for nwo. > > > > > > > > Much help, many thanks! > > > > > -- > > > Stefano Mazzocchi One must still have chaos in oneself to be > > > able to give birth to a dancing star. > > > <[EMAIL PROTECTED]> Friedrich Nietzsche > > > -------------------------------------------------------------------- > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, email: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, email: [EMAIL PROTECTED] > > > > > ======================================================================= > Information in this email and any attachments are confidential, and may > not be copied or used by anyone other than the addressee, nor disclosed > to any third party without our permission. There is no intention to > create any legally binding contract or other commitment through the use > of this email. > > Experian Limited (registration number 653331). > Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
