openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Evan Ireland" <eirel...@sybase.com>
Subject RE: [jira] Updated: (OPENJPA-637) Significant performance degradation when data cache is enabled
Date Tue, 17 Jun 2008 21:58:41 GMT
It would be interesting to identify the characteristics of the JPA
ConcurrentHashMap implementation that make it preferable to the JDK one, so
that possibly the JDK one can be improved.

> -----Original Message-----
> From: Jeremy Bauer (JIRA) [mailto:jira@apache.org]
> Sent: Wednesday, 18 June 2008 4:52 a.m.
> To: dev@openjpa.apache.org
> Subject: [jira] Updated: (OPENJPA-637) Significant performance degradation
> when data cache is enabled
> 
> 
>      [ https://issues.apache.org/jira/browse/OPENJPA-
> 637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
> 
> Jeremy Bauer updated OPENJPA-637:
> ---------------------------------
> 
>     Attachment: OPENJPA-637.patch
> 
> Attaching a patch for 1.2.0 which adds-back and utilizes the OpenJPA
> ConcurrentHashMap implementation.  Based on benchmark results and
> additional testing with the Java 5-based implementation, use of the
> OpenJPA implementation appears to be the best course of action.  Comments,
> please.
> 
> > 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