From dev-return-8480-apmail-openjpa-dev-archive=openjpa.apache.org@openjpa.apache.org Mon Jun 23 19:37:07 2008 Return-Path: Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: (qmail 97786 invoked from network); 23 Jun 2008 19:37:05 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 23 Jun 2008 19:37:05 -0000 Received: (qmail 88106 invoked by uid 500); 23 Jun 2008 19:37:07 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 88001 invoked by uid 500); 23 Jun 2008 19:37:07 -0000 Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openjpa.apache.org Delivered-To: mailing list dev@openjpa.apache.org Received: (qmail 87990 invoked by uid 99); 23 Jun 2008 19:37:07 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 23 Jun 2008 12:37:07 -0700 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 23 Jun 2008 19:36:25 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id EC75F234C13C for ; Mon, 23 Jun 2008 12:36:44 -0700 (PDT) Message-ID: <1975778757.1214249804953.JavaMail.jira@brutus> Date: Mon, 23 Jun 2008 12:36:44 -0700 (PDT) From: "Jeremy Bauer (JIRA)" To: dev@openjpa.apache.org Subject: [jira] Updated: (OPENJPA-637) Significant performance degradation when data cache is enabled In-Reply-To: <634931873.1213647945085.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/OPENJPA-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Bauer updated OPENJPA-637: --------------------------------- Attachment: CacheImplTest.jar I've attached a standalone test for running some tests using various cache implementations and configurations. It behaves similarly to the benchmark that exposed this problem. The test allows configuration of number of threads, max data size, max cache size, whether external locking is enabled, and the cache implementation type. This test is showing similar results as to what I've previously posted; a write lock causing contention when the cache becomes full. When the external write lock (a reentrant lock over and above internal cache locking) is enabled and the data size is ~5000 entries larger than the max cache size performance drops significantly. The external lock simulates the reentrant lock used by DataCacheStoreManager to ensure the cache does not get updated with an old version of data. This test should provide a better idea of what I'm seeing. Aside, there is an option to run directly with java.util.concurrent.ConcurrentHashMap and it performs very well - although there is no null masking or maximum size on the cache. To get a list of options: java -cp CacheImplTest.jar;commons-collections-3.2.jar cachetest.Main Patrick - What behavior/environment does your benchmark test? Is it possible that your cache size is very near the size of your data so you are not hitting the problem? > 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: 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.