Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Date: Tue, 11 Oct 2011 10:13:12 +0000 (UTC)
From: "angela (Commented) (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Message-ID: 
 <1889828965.144.1318327992056.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <381907238.6202.1314870369984.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (JCR-3064) Concurrent access performance drop
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

angela commented on JCR-3064:
-----------------------------

applied the patch with modifications.
note however, that the patch doesn't address the performance issue we are facing which
IMHO is caused by another problem.

since i originally suspected that performance would suffer from the new permission 
evaluation (see JCR-2887),  i spent some time looking at the current performance degradation. 

based on my findings, profiling results (see also findings posted by alex above), looking at the 
concurrency test and selectively excluding parts of the permission evaluation i came to the 
conclusion that there might be other sources for the issue than just privilege handling.

here some preliminary observations:

- collecting the relevant access control entries (which was reported to be a major hotspot)
  is executed with a SystemSession thus omitting any kind of permission evaluation.

- while heavy node reading to collect access control content has been identified as one 
  of the problems of the current default implementation (see also JCR-2842) this isn't
  any new and does IMO not explain the current performance loss.
  the same amount of Session.getNode calls was present in jackrabbit 2.2 where 
  performance is way better.
  -> here the patch makes some limited improvement by reducing the amount of 
      items being read with the system session.

- the current implementation of concurrent*test don't create access control content and 
  thus are executed with a single acl at the root node. i would therefore expect an minor 
  impact of permission evaluation s.str.  (and accordingly omitting it altogether didn't
  show an improvement on the overall performance).

- so, the big difference between executing the Concurrent*Test with "admin" instead of
  an anonymous user is the amount of nodes being retrieved with the system
  session upon item access.

having said that,  i have the impression that what we are seeing with our current Concurrent*Test 
are performance degradation due to an issue with excessive item access made by one SystemSession. 
i still don't fully understand what was the difference between jackrabbit trunk and jackrabbit 2.2 branch (both 
2.2.0 and 2.2.10-SNAPSHOT show much better performance) with respect to item retrieval.
while the changes made to permission calculation most probably have an effect as well
i couldn't so far identify them with our concurrency tests.

                
> Concurrent access performance drop
> ----------------------------------
>
>                 Key: JCR-3064
>                 URL: https://issues.apache.org/jira/browse/JCR-3064
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>            Reporter: Jukka Zitting
>            Priority: Blocker
>             Fix For: 2.4
>
>         Attachments: ConcurrentReadTest.png, ConcurrentReadWriteTest.png, JCR-3064-EntryCollector.patch, visualvm-ConcurrentReadTest-2.2.png, visualvm-ConcurrentReadTest-2.3.png
>
>
> Our performance tests show a pretty bad drop in concurrent access performance (both read and write) in the latest trunk when compared to Jackrabbit 2.2. We need to track down the cause and fix it before the 2.3 release.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira