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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
