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