[
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 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.
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.
Reads are slow, because pulling entries back with 1000's even hundreds of
thousand members is actually pulling a bunch of data across. So, what we can
do, is only pull back the members when absolutely necessary.
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 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.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
