Leo, First thanks for the quick answer.
The problem with our application is that there is a very very strict requirement : 99.97% of user requests must not take longer than 1 second (it's not a web application and we do control the maximum number of users that come in the system, lucky us !). Thus, if we add only a few ns for every lookup call then when you multiply by the number of objects you look up then it still adds up and gives us less time to perform other tasks within the 1 second. To summarise, you are right and the relative time the ECM takes when compared to other things like DB access, network calls, etc is negligible. However, the absolute time is adding up and that's our problem (we have to be always under the 1 second barrier and we'd rather use the remaining time to perform some business related stuff rather than technical ones ... :-)). I was wondering really about why we have to use synchronized in BucketMap.get(). It seems to me the only reason is for decommissioning the components. However, decommissioning is a rare event (which do not happen during the whole life of most application). Lets' say I don't care about releasing ThreadSafe component; why would I need a synchronized block in lookup() ? I thought I read a post a while back from someone who had implemented an ECM that was not releasing components ? (if so, was it also not releasing SingleThreaded components ?). Thanks a lot -Vincent > -----Original Message----- > From: Leo Sutic [mailto:[EMAIL PROTECTED]] > Sent: 08 March 2002 19:11 > To: Avalon Developers List > Subject: RE: Performance questions about ECM > > > > > From: Vincent Massol [mailto:[EMAIL PROTECTED]] > > > > 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 ? > > Yes. Very. Don't worry about Berin's profiling and reworking and the > ContainerManager and all that. > > ECM is far from being the performance bottleneck. ContainerManager & co. > is being written to make sure the CM never will be the bottleneck, even > if your code looks like this: > > while (true) { > manager.release (manager.lookup (MyComponent.ROLE)); > } > > > 2/ Do you know of anyone who has implemented a "performance mission > > critical" ECM, i.e. designed for performance rather than feature ? > > I have not done that, but I have increased performance by an order of > magnitude in Cocoon2 by writing my own components. > > In my experience, the ECM is *never* the bottleneck. The time I spend > looking up components is always negligible relative to the time > I spend using the components. > > As a matter of fact, the speedup I mention above would not be > possible without a feature-rich ECM: It allowed me to plug in > my component easily. > > > 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 ? > > That depends very much on what your application will do. What components > will you use? Are the components themselves performant? > > For example, if you lookup a component in the ECM, and that component > does a remote call, it doesn't matter how performant the ECM is: You > spend 99.9% in the remote call. So if any of your components do > a database lookup, or an SQL query, you will spend about 1000 times longer > in the lookup than in the ECM. (I am not making these numbers up.) So > even if the ECM operated instantaneously, you'd only get a 0.1% speedup. > > A way around the ECM: > > If you can keep a reference to a component throughout the life of > the client, do so instead of looking up every component as it is about > to be used and then released. (You won't have any pooling, but if a > component > is being used by the client *all the time*, pooling will not do you any > good anyway, as the components do not spend any time in the pool.) > > But first - make sure that the ECM really is the bottleneck. > > /LS > > > -- > To unsubscribe, e-mail: <mailto:avalon-dev- > [EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:avalon-dev- > [EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
