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.
==========================================

Reply via email to