[
https://issues.apache.org/jira/browse/USERGRID-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Todd Nine updated USERGRID-270:
-------------------------------
Description:
Forever ago, I changed a branch in 1.0 to being using permissions caching. I
never finished it because our priorities changed. We should try to resume the
work on this branch, and fix caching for permissions. See the line in the
profiler results.
[Wall Time]
org.apache.usergrid.security.shiro.Realm.doGetAuthorizationInfo(PrincipalCollection)
Realm.java
As you can see, a cache would eliminate the graph traversal for permissions
calculation. This is 20% of every API invocation. I propose the following
simple implementation to start with.
# A bucketed cache per application. The number of buckets is always static and
configured via properties
# Users are consistently hashed into these buckets based on their userId (which
is immutable)
# When a group, role, or permission changes for an application, all shards in
the cache are deleted.
# When permissions are calculated on the first initial call in the realm, they
are inserted into the cache
Note that invalidating an entire app's cache is not efficient, but this is an
easy first step towards a system which can later more intelligently invalidate
caches.
Improvement derived from GetUsersSimulation in the loadtests
was:
Forever ago, I changed a branch in 1.0 to being using permissions caching. I
never finished it because our priorities changed. We should try to resume the
work on this branch, and fix caching for permissions. See the line in the
profiler results.
[Wall Time]
org.apache.usergrid.security.shiro.Realm.doGetAuthorizationInfo(PrincipalCollection)
Realm.java
As you can see, a cache would eliminate the graph traversal for permissions
calculation. This is 20% of every API invocation. I propose the following
simple implementation to start with.
# A bucketed cache per application. The number of buckets is always static and
configured via properties
# Users are consistently hashed into these buckets based on their userId (which
is immutable)
# When a group, role, or permission changes for an application, all shards in
the cache are deleted.
# When permissions are calculated on the first initial call in the realm, they
are inserted into the cache
Note that invalidating an entire app's cache is not efficient, but it is an
easy first step towards a system which can later more intelligently invalidate
caches.
> [SPIKE] Re-investigate permission caching
> -----------------------------------------
>
> Key: USERGRID-270
> URL: https://issues.apache.org/jira/browse/USERGRID-270
> Project: Usergrid
> Issue Type: Improvement
> Components: Stack
> Reporter: Todd Nine
> Attachments: Realm.zip
>
>
> Forever ago, I changed a branch in 1.0 to being using permissions caching. I
> never finished it because our priorities changed. We should try to resume
> the work on this branch, and fix caching for permissions. See the line in
> the profiler results.
> [Wall Time]
> org.apache.usergrid.security.shiro.Realm.doGetAuthorizationInfo(PrincipalCollection)
> Realm.java
> As you can see, a cache would eliminate the graph traversal for permissions
> calculation. This is 20% of every API invocation. I propose the following
> simple implementation to start with.
> # A bucketed cache per application. The number of buckets is always static
> and configured via properties
> # Users are consistently hashed into these buckets based on their userId
> (which is immutable)
> # When a group, role, or permission changes for an application, all shards in
> the cache are deleted.
> # When permissions are calculated on the first initial call in the realm,
> they are inserted into the cache
> Note that invalidating an entire app's cache is not efficient, but this is an
> easy first step towards a system which can later more intelligently
> invalidate caches.
> Improvement derived from GetUsersSimulation in the loadtests
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
