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.
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:
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]
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
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
