Michael Hartle wrote:
> Sylvain Wallez wrote:
>
>>> 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.
>>
> Just a thought, as not tuning the pools is probably going to be a common
> and easy mistake for people who are starting to evaluate Cocoon and get
> bad performance results, what about an adaptable pool which starts
> tuning its configuration after a while depending on usage ? Is this
> achievable at all ?
It is achievable. I have not gotten around to doing it yet. I created the
current pooling implementation--and the reason I chose the ResourceLimiting
approach is so that the JVM doesn't hold an uncontrolled number of references
which can be damaging to GC collection cycles later. Clearly, the resources
have to be controlled, but it can be done in a smarter manner.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
