This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I stumbled on something that is extremely counter intuitive. I wrote an EJB client that implements two different methods of invoking a normal EJB method. The first one employs the conventional way ie., to get home, create bean and call the method. The second one on the other hand, uses EJB metadata and reflection to invoke the EJB method. Here is the code -
I wrote a stateless session bean, deployed it on WebLogic and ran my client invoking the same bean method using both mechanisms. Much to my surprise, I noticed a significant difference in the response times involved between the two methods. Now comes the surprising part - using reflection actually performs better, way better than the conventional mode. My small benchmark on WebLogic shows - Normal invoke took 9754 ms Reflection invoke took 41 ms I have always been told to avoid using reflection because of the extra involved in runtime introspection. However my little experiment shows otherwise. What am I missing here?
Open Group Certified Distinguished IT Architect. Open Group Certified Master IT Architect. Sun Certified Architect (SCEA).
What are you missing? Nothing. You've just got the overhead of the JNDI calls, container overheads and so on. I usually find that if you only call an EJB once, you get hit badly on performance. Subsequent requests are usually much, much quicker. Have you tried measuring the average, min and max response times? That should present a more realistic picture. Simon
Joined: Mar 17, 2000
Ok, I am going to try to measure the min, max and average times. But I should tell you the results are consistent. No matter what the first way of invocation is( I have tried swapping the two method calls), the reflection-way always performs way better than the conventional way. By the way JNDI lookup is done in the getHome() method and as you can see in the code, getHome() is common to both the methods. [ March 25, 2003: Message edited by: Ajith Kallambella ]
Ajith & Simon, This is a really interesting out come and i really am amazed that this behaviour which is totally the anti thesis of what we have been made to understand occurs. And the overhead of the JNDI call is still there in both the methods. If you look at the way both the methods call the getHome method, i am assuming that that method does the JNDI look up. Ajith what would really be interesting is if u could run the JProbe Profiler on this snippet and compare what methods in the 2 codes are taking how much time. I suppose that will give us a good idea about who is doing what.
Ajith - I am very new to this, so I apologise if I am totally offbeat. I see in your normalInvoke() method, you have done the narrowing twice. Can't we do that only once while acquiring the home interface, and with that just call the home's create method. Like, Trader trader = home.create(); I'm following the EJB-Monson-Haefel's book; nowhere I see calling the PortableRemoteObject.narrow twice. Thanks, Sudd
Ajith, I think when you use conventional mechanism to call a business method, EJB remoteObject might be using the reflection over the network to invoke any business method,but it might be faster if you write your own reflection mechanism without network overhead using EJB metadata on client side and network might be used only to inovke a business method. [ April 02, 2003: Message edited by: deena Janarthanam ] [ April 02, 2003: Message edited by: deena Janarthanam ]
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com