[jira] [Closed] (FC-307) Performance problem with roles many members

["Shawn McKinney (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/FC-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shawn McKinney closed FC-307.
-----------------------------
    Resolution: Fixed

> Performance problem with roles many members 
> --------------------------------------------
>
>                 Key: FC-307
>                 URL: https://issues.apache.org/jira/browse/FC-307
>             Project: FORTRESS
>          Issue Type: Improvement
>    Affects Versions: 2.0.7
>            Reporter: Shawn McKinney
>            Assignee: Shawn McKinney
>            Priority: Major
>             Fix For: 2.0.8
>
>
> This issue brings performance improvements to situations where the role.occupants is enabled on role entries.  The problem, is groups with many members can be costly to update and even read.  Insertions are slow because large groups are expensive to process in LDAP.  (There are mitigating and aggravating factors to consider on the server side that are beyond the scope of this discussion)  
> We can also set 'role.occupants' flag to false, as already mentioned.  This sidesteps this issue by not storing member information on the Role entry rather storing on the User entry only.  
> To be clear, Fortress always store's the user's role membership on the user entry.  The role.occupant flag controls the behavior of also storing the reverse, i.e. user membership on the role entry.  There are pros/cons of each approach, and has to do with from what perspective the query is from.  For example, given a user, return their roles will be more efficient by storing the membership on the user.  Given a role, return the users will be more efficient storing the membership on the role.
> In any case, performing 'Reads' on very large groups is slow, because pulling those entries back may contain 1000's even hundreds of thousand of members.  Think University group of 'student' or 'alumni' or a Bank's 'customer' role.  This requires pulling back a bunch of data across, which is very expensive to do, even in LDAP.  So, what we're trying to do here, is only pull back the role's members when absolutely necessary, iff the role.occupant is enabled.
> This issue addresses this by adding a method to the RoleP and RoleDAO classes called readConstraints.  It only pulls back the constraints and parents on the entry and not its members or properties.
> This method replaces the role validation, constraint and hierarchical processing that occurs in the AdminMgrImpl class.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org