Re: Open letter from an OpenJPA performance perspective
I doubt anyone has done much performance analysis of stock OpenJPA, especially without caching. BEA's performance efforts obviously focus on Kodo instead. Which is why we all appreciate the performance work you're doing now, even if we (well, mostly just me) might harp on the details. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Open letter from an OpenJPA performance perspective
Hi, There have been several requests about the performance analysis that we've been doing. This performance analysis has resulted in three JIRA Issues thus far (OPENJPA-115, OPENJPA-138, and OPENJPA-141) with more to come, I'm sure. We're not ready to go public with the specific results yet, but here's a response from our performance lead... I think we're all interested in making OpenJPA the premier JPA implementation. == Apache Group, We have been testing the performance of the OpenJPA runtime under various application servers as well as in stand alone mode and have been working diligently to make sure that OpenJPA's performance out of the box in the common customer scenarios is superior to other products in the market place. We took the testing approach of starting our testing of the OpenJPA runtime from the very simplest test case in both SE and running under an application server and then working into more complex query and update scenarios making improvements along the way. Some of these improvements have been committed already and others we are still debating... Out of the box performance for the SE version of the runtime was excellent and excelled past the competing products (in some scenarios). However, out of the box performance on two separate application servers when running the 0.9.6 snapshot of the OpenJPA runtime showed that we were not able to drive the test case of a simple single row entity finder (Find by Primary Key) scenario to anything more than 70% CPU on a two way system when the runtime had no caching enabled. The CPU bottlenecks and issues showed up on multiple JVM's as well which we swapped out under the application servers to ensure that we were not running into runtime issues. This lead to performance that was up to 2x slower than the competing JPA implementations (also with no caching enabled) while running underneath an application server. We investigated with the issues with code profilers as well as simple things such as thread dumps and came up with a variety of fixes for the obvious issues. The fixes that Kevin has integrated addressing these issues now improve that initial result by a little over 2.1x putting us now in front of the competitors in the FBPK case! These fixes have also improved the much more complex cases performance as well an amount that we will disclose later along with other fixes to make those scenarios faster as well. I am curious who else out there has been testing the performance of the OpenJPA runtime on any type of scenario as I believe these issues would have been fairly easy to spot and I have to imagine are affecting others when running the OpenJPA runtime underneath an application server as the issues are fairly high-level and pervasive. If you are not seeing the issues I am concerned as to why we are -- given that the testing we have completed is on two completely different application servers and code bases. We will continue to work diligently to provide an OpenJPA runtime that is enterprise class in both features and performance for the Apache community. I look forward to any comment and really would love to hear what others are doing for performance testing. ==