[
https://issues.apache.org/jira/browse/FC-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn McKinney updated FC-307:
------------------------------
Description:
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.
was:
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 in LDAP. There are mitigating factors 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 membership, 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 are slow, because pulling
those entries back may contain 1000's even hundreds of thousand of members.
Think University group of 'student' or alumni'. This requires pulling back a
bunch of data across which is very expensive to do. So, what we're trying to
do here, is only pull back the members when absolutely necessary, when
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.
This method replaces the role validation, constraint and hierarchical
processing that occurs in the AdminMgrImpl class.
> 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.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
