openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Bauer (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OPENJPA-637) Significant performance degradation when data cache is enabled
Date Wed, 18 Jun 2008 20:27:45 GMT

    [ https://issues.apache.org/jira/browse/OPENJPA-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12606078#action_12606078
] 

Jeremy Bauer commented on OPENJPA-637:
--------------------------------------

Several attempts were made to tune the max size of the data cache with base 1.2.0 code. Performance
started to degrade at a certain point by further increasing the max cache size . The benchmark
showed better results with a max size of 5000 than it did for 10000+. (Default (1000) and
15000 were also tested, 5000 appeared to be optimal for this workload.) The database tables
used in the benchmark fluctuate around 35000 rows, which roughly equate to entities.

Out of curiousity, instead of using CacheMap as the cache store in ConcurrentDataCache, java.util.concurrent.ConcurrentHashMap
was used directly in its place (soft ref, write locking, and pinning support were removed
for simplification). This also eliminated the max size and null handling aspects of the cache.
Benchmark performance with this configuration was very similar to measurements taken with
the data cache disabled. Database (on a separate server) utilization was down considerably,
which was good & expected, but the benchmark was not showing a performance improvement.
In contrast, 1.2.0 using the 1.0.x code showed a ~20% improvement when the data cache (max
cache size 5000) was enabled.

> 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
>         Attachments: 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.


Mime
View raw message