[
https://issues.apache.org/jira/browse/JCR-3892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14631986#comment-14631986
]
Tobias Bocanegra commented on JCR-3892:
---------------------------------------
performance test that has 8 readers that constantly read the membership of a
users,
and it has 8 writers that constantly alter the memberships of a group.
test with 10k users, 300 groups, 5000 per group, we can see that reading is
either fast (<1ms) or rather slow (>1s) depending if the cache is hit or not.
{noformat}
-----------------------------------------------
Test time: 20000, Ramp-up time 1000
Number of users: 10000
Avg number of users/group: 5000
Number of groups: 300
Number of readers: 8
Number of writers: 8
Cache size: 304
Time to get memberships:
ns : 0.00% (0)
10ns : 0.00% (0)
100ns : 0.00% (0)
1us : 0.00% (0)
10us : 0.00% (0)
100us : 41.96% (94)
1ms : 12.50% (28)
10ms : 4.46% (10)
100ms : 4.46% (10)
1.0s : 36.61% (82)
-----------------------------------------------
Time to alter memberships:
ns : 0.00% (0)
10ns : 0.00% (0)
100ns : 0.00% (0)
1us : 0.00% (0)
10us : 0.00% (0)
100us : 0.00% (0)
1ms : 6.19% (42)
10ms : 68.04% (462)
100ms : 18.56% (126)
1.0s : 7.22% (49)
{noformat}
> Selective invalidation of MembershipCache
> -----------------------------------------
>
> Key: JCR-3892
> URL: https://issues.apache.org/jira/browse/JCR-3892
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-core
> Affects Versions: 2.6, 2.8
> Reporter: Tobias Bocanegra
> Assignee: Tobias Bocanegra
>
> The MembershipCache is invalidated whenever any group membership changes.
> this was a simple way to avoid complex transitive invalidation strategies.
> In a system with a large user, group and member based, the lookup of group
> memberships can be especially slow, due to the reverse lookup of the
> weak-references of the members - in those systems, a good cache is essential.
> If additionally the group memberships change ofter, maybe due to changing
> entitlements of groups, or when synchronizing with an external IDP, the cache
> is constantly flushed, thus causing performance problems for each membership
> lookup.
> there can be other remedies to speed up lookup, for example to properly
> enable the group-split-size; or to implement a custom principal provider for
> highly dynamic memberships.
> nevertheless, if the membership cache would only invalidate what has changed,
> it would help the performance for those authorizables that weren't affected.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
