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