(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 <[EMAIL PROTECTED]> To: Avalon Developers List <[EMAIL PROTECTED]> References: <03d301c1c6a0$3e0952f0$6b53c5cb@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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
