EJB 3.0 was actually available for some time on top of WAS V6.1 in the Feature Pack for EJB 3.0, but now it exists in WAS V7.0 as well. EJB 3.0 in my mind is all about making the developer's life simpler (annotations, test outside of container, etc.) along with giving us a better model for more performant persistence. You can see all new features added to EJB 3.0 in WAS V7.0 (including performance features) in Kevin's blog post. Given this is the second major release of EJB 3.0 for WebSphere, performance of EJB 3.0 on WAS is top notch. You'll also see that we've recently added an implementation using the standard JPA caching functions to allow caching via WebSphere eXtreme Scale (Formally known as WebSphere Extended Deployment Data Grid) which is a distributed in-memory data grid.
In working on persistence performance in WAS V7.0, we used the Apache DayTrader application with some IBM tweaks. There are two versions of DayTrader of interest (1.2 which uses EJB 2.1 and 2.0 which uses EJB 3.0). There are other changes as well to move DayTrader 2.0 to Java EE 5, but most don't have deep performance impacts. Really, the big change from a performance perspective is the implementation of the persistence layer.
The results of all of the new WAS V7.0 features is a very performant EJB 3.0 implementation that outpaces the EJB 2.1 performance by 23% as shown in the below chart. This is a rather impressive improvement considering the EJB 2.1 implementation has been grooved by years of leading IBM benchmark results in SPECjAppServer. It is also worth noting that the below chart is EJB 2.1 to EJB 3.0 heads up (actually both are measured on WAS V7.0). If you are migrating from WAS V6.1 or earlier the percentage improvement would be far greater.
Again, I'm interested in feedback from users who have tried the new engine.
5 comments:
Hi Andrew,
Have you got any ideas what the increase in performance might be for people just using stateless beans and not JPA or entity beans.
Chris
Chris,
Roughly, as it depends on the application, 10% or so. Simple create/use/remove scenarios would be higher. This is due to code path improvements in the container and J2SE improvements.
Andrew (and the crew),
I've revisited this article again and its drawn my attention to exteme scale. This might not be a question that can be answered in a simple posting, but . . . If I was using JPA and wanted to use extreme scale, is it easy to retofit extreme scale to the back of JPA based on what you guys have done ?.
Regards,
Chris
Chris,
The answer is yes in general, but there are some specific limitations in terms of full WebSphere Extreme Scale exploitation by OpenJPA. Billy Newport has said he'll try to explain the specifics in upcoming blogs/podcasts. If you don't see something very soon on the topic let me know.
Andrew,
I skimmed the eXtreme scale redbook, it appears that adding the @Entity annotation (and presumably some other config outside the code) does the job. Nice to see that some "Joined up thinking" has gone into this.
Chris
Post a Comment