Significant performance degradation when data cache is enabled
--------------------------------------------------------------
Key: OPENJPA-637
URL: https://issues.apache.org/jira/browse/OPENJPA-637
Project: OpenJPA
Issue Type: Bug
Components: datacache, lib
Affects Versions: 1.2.0
Reporter: Jeremy Bauer
Performance testing is showing a severe data cache performance degradation when
moving from 1.0.x OpenJPA code to 1.2.0 level code. Profiling showed the
problem to be in the new random eviction scheme which runs when the cache
reaches its maximum number of entries. This code was changed significantly
when OpenJPA moved to Java 5 java.util.concurrent.ConcurrentHashMap and away
from the OpenJPA implementation of ConcurrentHashMap. A macro-benchmark showed
a 20% performance degradation from base 1.2.0 code when the cache reaches its
maximum size; prompting eviction in order to add new cache entries.
I've found that the new random eviction code appears to be improved in the very
recent 666903 commit, but data cache performance remains considerably slower
than the 1.0.x implementation. Profiles with the 666903 changes show test
threads to be waiting on the reentrant write lock in the CacheMap wrapper
(which now wrappers a max size capable, null handling, subclass of
java.util.concurrent.ConcurrentHashMap). Investigation is underway to
determine whether the write lock is necessary (ie. can
java.util.conncurrentConcurrentHashMap manage the cache without the need for
external locking) and/or if changes could be made which would result in a
significant reduction in contention for the lock. Any thoughts/ideas on that
would be extremely helpful.
Performance tests run with the 1.2.0 code base, using the OpenJPA version of
ConcurrentHashMap (instead of the Java 5
java.util.concurrent.ConcurrentHashMap-based implementation) have shown that
performance of the data cache is significantly better when the legacy OpenJPA
implementation is used. Based on the results, it appears that OpenJPA should
be using the the legacy ConcurrentHashMap instead of the Java 5-based
implementation -- or the new Java 5-based implementation needs to be improved
considerably in order to perform as well as 1.0.x.
I am opening this as a 1.2.0 issue, although it very likely affects 1.1.x as
well. Testing has not been performed on 1.1.x to confirm the problem exists on
that release.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
