cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Possible points of scalibility issues
Date Wed, 13 Feb 2002 20:12:42 GMT

I have been performing some performance analysis of the Avalon Excalibur code, and I discovered
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 magnitude
more efficient than the current pooling implementations.  I have posted a VOTE to promote
it
from scratchpad to production.  When that happens, there will be less thread contention on
Pooled components.

Another, more serious point of contention is the ExcaliburComponentManager implementation
itself.
The reason is that there are some *potentially* long stretches of code that are blocking.
 This
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 CVS
version is functional (not in Cocoon's CVS, but Avalon's), but the API needs some sprucing
up.
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 the
precise number of instances available, which the ResourceLimitingPool is better suited for.
The alternative FixedSizePool is both ThreadSafe and the fastest implementation.

The new ContainerManager/Container abstraction does have a new Role configuration format,
and
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 implementation
to the Component implementation.  This is much more flexible, and I believe it will work better
in the long run.  The default ComponentHandler has been changed from Factory to PerThread
(Using
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 it.
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
will
allow to be used on Cocoon to around 40--but when the core is made better, we won't need to
have
those limitations.


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message