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