cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
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
>>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
> 
> .
> 
> 



-- 

"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