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 13:52:52 GMT


> ----------
> 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.

> 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


Mime
View raw message