Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <14267580.97451284046652655.JavaMail.jira@thor>
Date: Thu, 9 Sep 2010 11:37:32 -0400 (EDT)
From: "Jukka Zitting (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Commented: (JCR-2699) Improve read/write concurrency
In-Reply-To: <575335.157691280930355704.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/JCR-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907656#action_12907656 ] 

Jukka Zitting commented on JCR-2699:
------------------------------------

Based on some profiling and other analysis based on the concurrent read performance tests I added, here's a few pointers for potential improvements:

* The bundle cache is hidden behind the synchronization layer of the bundle persistence classes, which causes a single cache miss to block access to the entire cache while the missing bundle is fetched from disk. We should revise the synchronization level to allow the bundle cache to serve concurrent requests even when the persistence manager is busy waiting for I/O.

* The synchronization overhead in DefaultISMLocking was pretty high. I was seeing some significant time spent there even though in a concurrent read test a thread should never get blocked by the ISMLocking implementation. I refactored the DefaultISMLocking class in revision 995411 for issue JCR-2089, which solved most of this problem. I didn't try it yet, but I suspect that the FineGrainedISMLocking class may be even worse in this regard.

* Path handling code shows up quite a bit (2-5% of active CPU time) in profiling results. We should be able to avoid that overhead as described in the follow-up issue JCR-2744.

* The synchronized cache blocks in ItemManager and SharedItemStateManager show up as contention bottlenecks in highly concurrent read scenarios.

* Access control checks with the DefaultAccessManager add significant amount of overhead when compared to the dummy SimpleAccessManager implementation. Even though ACL optimizations are somewhat orthogonal to concurrency improvements, the large number of usually very fine-grained content accesses done by the DefaultAccessManager puts significant extra pressure on the above-mentioned contention points, so we should see notable concurrency improvements also from optimized ACL evaluation.

> Improve read/write concurrency
> ------------------------------
>
>                 Key: JCR-2699
>                 URL: https://issues.apache.org/jira/browse/JCR-2699
>             Project: Jackrabbit Content Repository
>          Issue Type: Improvement
>          Components: jackrabbit-core
>            Reporter: Jukka Zitting
>            Assignee: Jukka Zitting
>         Attachments: ConcurrentReadTest.png
>
>
> I'd like to set up a few performance tests to help identify our worst bottlenecks for various kinds of concurrent read-only and read-write access patterns.
> Once identified, I'm hoping to fix at least some of those bottlenecks.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.