cocoon-dev mailing list archives

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

Berin,

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.

Giacomo

>
> 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.
>
>
>


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


Mime
View raw message