[
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
