Stefano Mazzocchi a écrit :
>
> Michael told me privately the numbers that he has been experiencing
> along with a description of his environment and I now agree with him, we
> have a serious scalability problem.
>
> He refers to 2.0RC2 but since nothing that could improve performance
> changed between 2.0 and 2.0RC2, I think it's still up there.
>
> For "serious", I mean something important that should be fixed ASAP,
> otherwise, Cocoon 2.0 will rarely have any use in high-load
> environments.
>
> The numbers say, more or less, than the same functionality ported from
> Cocoon 1.8.2 to Cocoon 2.0RC2 resulted in 20 times slower performance!
>
> Yes, guys, we're not talking about 20% slower but 2000% slower.
>
> WAIT, STOP, SIT DOWN!
>
> Before you rush to your boss to tell that Cocoon 2.0 sucks and you
> shouldn't place your million-dollars worth project on it, let me explain
> what I believe the problem is.
>
> 1) their Cocoon 1.8.2 application has been up for a long time and they
> carefully tuned the system for it. Their Cocoon 2.0RC2 version is an
> early implementation.
>
> 2) they admit the Cocoon 2.0 cache system is likely to provide huge
> benefits for them, but they are not sure they are using it properly.
>
> 3) they don't use a transparent proxy on top so the Cocoon cache is
> continously stressed.
>
> 4) they report much better "perceived" performance on a single browsing
> experience: this seems to show that Cocoon 2.0 isn't slow by itself, but
> there is an hidden bottleneck someplace.
>
> 5) they use XSP. I'm aware of performance issues with XSP load and
> execution under heavy load (some forgotten locking or synchronized
> method?). This is the place where I'd concentrate profiling effort.
There's a CPU/memory eater in ServerPagesGenerator : each startElement
is stored in a stack in order to properly close all opened elements in
case of premature end of the XSP (return statement or exception). Cocoon
1 didn't have this because of the use of DOM : even if partially
generated, the DOM is always a valid XML document.
This stack is a LinkedList to which EventData objects are appended. This
means for each element, 2 objects are allocated : the EventData object,
and a LinkedList node. We can change this stuff to use a single
ArrayStack (from excalibur.collections) and no EventData object, which
should significantly reduce CPU consumption.
But the real question is : can an XSP be considered valid if it contains
a "return" statement ? I personnaly never saw such XSPs. Also, this
stuff is only a half protection against bogus code in the XSP : it will
take care of having as much closed elements as opened ones, but doesn't
check proper balancing nor do anything for constructs like a "break" in
a loop inside an XML element.
So my opinion is remove this costly stuff and forbid return statements
in xsp:logic. This will make a speedy XSP engine.
Your thoughts ?
> Net Result: I think Cocoon 2.0, as it stands, doesn't scale, but the
> data provided it's not sufficient to understand *what* slows Cocoon
> down.
>
> Michael, I'd love if you guys could perform some more load tests for us:
0) before disabling logging, search for messages such as
"decommissioning instance of...". This reveals some undersized pools
which are corrected by tuning cocoon.xconf and sitemap.xmap. Undersized
pools act like an object factory, plus the ComponentManager overhead.
> 1) disable logging. If log is DEBUG, it could generate Gigabytes of
> information and disks could become the bottleneck.
>
> [I think log might be the bottleneck]
>
> 2) disable resource reloading. Same as above, the disk I/O system could
> become the bottleneck.
>
> 3) try to come up with some logarithmic stress tests: 1 req/sec, 2
> req/sec, 4 req/sec, 8, 16, 32, 64, until your machines saturate.
>
> 4) turn the cache off/on. [this, compared to the logaritmic approach
> should give us information on the caching system]
>
> 5) try to get the generated source code of one of your XSP, compile it
> as a generator and use it as a normal generator instead. [this should
> remove the XSP loading/handling phase]
And will also avoid the stack management mentioned above.
> With this data we will know where the problem is and if it really
> resides in Cocoon.
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <[EMAIL PROTECTED]> Friedrich Nietzsche
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
