"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.
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.
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.
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).
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*.
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.
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.
8) fine-tune your JVM settings (max heap-size, initial memory)
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)
10) consider prerendering or time-based batch-process the static parts
of your site: PDF reports, rasterized SVG graphs or things that change
regularly.
and finally
11) keep the pipelines small. Building a pipeline has a cost that is
proportional with the amount of components it has.
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.
--
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]
