cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lewis, Andrew J" <Andrew.Le...@jbosc.ksc.nasa.gov>
Subject RE: Cocoon scalability continued
Date Thu, 03 Jan 2002 14:02:15 GMT
Very cool...I wasn't sure...thanks!

> ----------
> From: 	Morrison, John[SMTP:John.Morrison@uk.experian.com]
> Reply To: 	cocoon-dev@xml.apache.org
> Sent: 	Thursday, January 03, 2002 8:59 AM
> To: 	'cocoon-dev@xml.apache.org'
> Subject: 	RE: Cocoon scalability continued
> 
> 
> 
> > -----Original Message-----
> > From: Lewis, Andrew J [mailto:Andrew.Lewis@jbosc.ksc.nasa.gov]
> > Sent: Thursday, 03 January 2002 1:53 pm
> > To: 'cocoon-dev@xml.apache.org'
> > Subject: RE: Cocoon scalability continued
> > 
> > 
> > 
> > 
> > > ----------
> > > From: 	Stefano Mazzocchi[SMTP:stefano@apache.org]
> > > Reply To: 	cocoon-dev@xml.apache.org
> > > Sent: 	Wednesday, January 02, 2002 1:01 PM
> > > To: 	cocoon-dev@xml.apache.org
> > > 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.
> > > <stefano@apache.org>                             Friedrich Nietzsche
> > > --------------------------------------------------------------------
> > > 
> > > 
> > > 
> > > 
> > ---------------------------------------------------------------------
> > > 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
> > 
> 
> 
> =======================================================================
> 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: 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