[
https://issues.apache.org/jira/browse/OPENJPA-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Bauer resolved OPENJPA-637.
----------------------------------
Resolution: Fixed
With the OpenJPA ConcurrentHashMap cache implementation back in place,
benchmark results with data cache enabled are back in-line with the 1.0.x
release. Future work regarding a data cache implementation configuration
option will be handled through OPENJPA-643.
> 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
> Assignee: Jeremy Bauer
> Attachments: CacheImplTest.jar, OPENJPA-637.patch
>
>
> 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.
