cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: Possible points of scalibility issues
Date Fri, 15 Feb 2002 15:37:51 GMT
giacomo wrote:
> 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.

I am in the process of writing a Profile test that compares ContainerManager code and
ECM code.  One of the coolest things is that the ContainerManager and AbstractContainer
implementations have a constant startup time (i.e. initialization is done asynchronously).
This allows expensive operations like initializing the DataSourceComponent to not affect
startup times.

With only three components in an Xconf file, I am seeing the ECM consistently in the 1.5
second range and ContainerManager in the 600-700 ms range.  I haven't gotten to the point
where I pound the ECM and ContainerManager's ComponentManager with 100 threads simultaneously,
performing lookup and release on all three components.  Currently, just startup times are
pretty cool.

There are usability issues, so I need to simplify the maintenance of ContainerManager (it
is somewhat of a bear right now), but it absolutely rocks from the client perspective.

> 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
>>A new Avalon committer named Leif Mortenson has created a new Pool implementation
>>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
>>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 up.
>>I also need to put in some Profiling tests.  In the new ContainerManager/Container
>>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
>>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
>>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
>>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
>>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:
> .


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

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

View raw message