cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <>
Subject Re: Possible points of scalibility issues
Date Wed, 13 Feb 2002 21:38:35 GMT
On Wed, 13 Feb 2002, Berin Loritsch wrote:


Thanks giving us background information from Avalon land. It sounds very
interesting and I am very curious to see Cocoon performance number with
those new or rewritten classes.


> I have been performing some performance analysis of the Avalon Excalibur code, and I
> some serious points of thread contention.  In a web environment, there can be as many
as 150
> threads (or more) if the web server uses simple thread per connection technology
> (most common aproach for Java based servers like Tomcat).  I expanded the Profile tests
to work
> using 100 threads.  The default pooling implementation has some serious slowdown due
to thread
> contention.
> A new Avalon committer named Leif Mortenson has created a new Pool implementation called
> ResourceLimitingPool.  This pool implementation is very flexible, and many orders of
> more efficient than the current pooling implementations.  I have posted a VOTE to promote
> from scratchpad to production.  When that happens, there will be less thread contention
> Pooled components.
> Another, more serious point of contention is the ExcaliburComponentManager implementation
> The reason is that there are some *potentially* long stretches of code that are blocking.
> is particularly true if the ECM needs to initialize a PoolableComponent.  I have tried
to make
> the blocking portions as small as possible, but we still have some work to do.
> I am also in the process of the new ContainerManager/Container abstraction.  The current
> version is functional (not in Cocoon's CVS, but Avalon's), but the API needs some sprucing
> I also need to put in some Profiling tests.  In the new ContainerManager/Container abstraction
> we make use of a new ManagedPool.  The pooling implementation for the managed pool is
even more
> efficient than Leif's excellent ResourceLimitingPool.  It is less deterministic as to
> precise number of instances available, which the ResourceLimitingPool is better suited
> The alternative FixedSizePool is both ThreadSafe and the fastest implementation.
> The new ContainerManager/Container abstraction does have a new Role configuration format,
> does not pay attention to lifestyle interfaces.  It is an experiment to see if we can
live without
> them--and seems to be working well.  The RoleManager will match the ComponentHandler
> to the Component implementation.  This is much more flexible, and I believe it will work
> in the long run.  The default ComponentHandler has been changed from Factory to PerThread
> a ThreadLocal to manage component instances).
> I am very interested in making Cocoon much better, and the best way I can do that is
to work
> on the core Avalon stuff.  The future will require changes, but the payoff will be worth
> I wanted to point out the hotspots that Cocoon is facing, and why it is having a hard
time scaling.
> In the interim, I would suggest limiting the number of threads that your Servlet container
> allow to be used on Cocoon to around 40--but when the core is made better, we won't need
to have
> those limitations.

To unsubscribe, e-mail:
For additional commands, email:

View raw message