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