[Fwd: Re: Performance questions about ECM]

[Berin Loritsch <bl...@apache.org>]

(My SMTP server is cracking up)



-------- Original Message --------
Subject: Re: Performance questions about ECM
Date: Fri, 08 Mar 2002 10:04:28 -0500
From: Berin Loritsch <bl...@apache.org>
To: Avalon Developers List <av...@jakarta.apache.org>
References: <03...@octovma>

Vincent Massol wrote:
 > On our J2EE project, we have fully switched from using standard java
 > classes to using Avalon components. They are heavily used. This project
 > is a very high performance one, which is what is bringing the following
 > questions.
 >
 > 1/ Is ECM performant ? Looking at the code, I can see that
 > BucketMap.java is doing synchronization ... Is that performant ? I don't
 > see why this would be needed for ThreadSafe components (single instance)
 > as they are initialized at initialization time and then you only need to
 > return a reference to them. Or maybe, should I say that I don't see a
 > need to synchronization provided you don't need to decommission them
 > during the lifetime of the application, which is probably the most used
 > scenario !

ECM is performant when a low number of threads are used in the system.
Low = ~20 threads.

BucketMap is smart about synchronization: it only synchronizes on a
portion of the entries at any one time.  This allows multiple threads
to use the same map implementation with a low chance of thread
contention.  BucketMap is more performant than placing synchronization
calls around a Map object.



 > 2/ Do you know of anyone who has implemented a "performance mission
 > critical" ECM, i.e. designed for performance rather than feature ?

:)  Funny you should mention that.  One is in the works right now!

In Excalibur Scratchpad, we have a package called:

org.apache.avalon.excalibur.system

It container ContainerManager and AbstractContainer.  There is a test
case that shows how to set it up, and compares the performance of
the ECM and the ContainerManager.

It is *much* more performant and scalable than the ECM.  Leo and I
are working on it, and as soon as we are happy with the API we will
make it available for general consumption.

Keep in mind that when the number of threads in you system are down
around 20 or below, there is much less difference between the two
implementations.  However, when there are upwards of 100 or even 1000
threads working on the system we start to see ContainerManager operating
113 times as fast.

 > 3/ Would you recommend using the provided ECM for our need or would you
 > say we need to implement our own ECM if we wish to get performance
 > results ?

I would suggest looking into the ContainerManager code.  Most of the
hard work is done for you (even setting up the ContainerManager is
easier than the ECM), and you can get started sooner.



 > Note: I've seen lots of messages on the ML saying that ECM is not
 > performant and I'm a bit worried ... I know there is always the
 > possibility of implementing it ourselves but I'd rather not ... :-)


It is currently used in Cocoon, and it depends on how many lookups
you perform on it.  If you use a lot of components that perform
dynamic lookups in order to process the results, you will see more
issues than if you held a reference to the external component for
the life of your component.


-- 

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


-- 

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


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>