Is EJB3 really as inefficient as dynaTrace indicated?
Hello Compuware staff,
We are running a standard EJB3 application. Our web server is a Linux machine running Tomcat. While our App server is a Linux machine running JBoss. Recently we closely studied the timing statistics of App server Stateless Session Bean call given by dynaTrace Purepath. Our study seems to indicate that EJB3's Stateless Session Bean calls are very inefficient. Only a tiny segment of the time is spent on the actual work. Most of the time is wasted in RMI overhead.
From the attachment one can see that the App server Stateless Session Bean call took 57.65 ms. This 57.65 ms approximately equals the sum of "defineClass0" (8.68) + "getCallerClassLoader()" (8.68) + "getMACSOptions()" (18.11) + "socketRead0()" (10.54) + "copyOf()" (11.64). Among them, only "getMACSOptions()" (18.11 ms) does useful work. The rest are all overhead. So the efficiency of EJB3 Stateless Session Bean call is only 31% !!!
I am wondering whether my observation is correct. I am also wondering whether you have similar past experience.
Thanks in advance.
Troy
Andi,
Thanks for your information. I have checked other Purepathes. I can see similar behavior there. The overhead time for each Stateless Session Bean call is always around 30ms.
Troy
in the PurePath dashlet click on "show all nodes". It will show you additional trace levels from Auto Sensors. The "copyOf" method call for instance might be from some other component.
My point is - you may want to see whether there is anything else going on in that request that is not Bean-related that causes this overhead. But - it might very well be that it has a certain amount of overhead
Hi Troy
I am not sure if looking at a single purepath should lead to this conclusion. It seems that classes are created on the fly here. This "overhead" might just be a one-time thing. After starting your app your app still needs to fully initialize. Therefore I suggest to look into several PurePaths and see whether this pattern stays the same or changes over time.
Andi
