[jira] [Commented] (JCR-3892) Selective invalidation of MembershipCache

["Tobias Bocanegra (JIRA)" <ji...@apache.org>]

    [ 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)