[
https://issues.apache.org/jira/browse/RANGER-5614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18088726#comment-18088726
]
Ramachandran Krishnan commented on RANGER-5614:
-----------------------------------------------
Merged into ranger-2.9 branch commit
details:https://github.com/apache/ranger/commit/9a9b117788bc15343676d5eafdba7ca12b418564
> Role creation/updation takes more time when there are more users,groups,roles
> -----------------------------------------------------------------------------
>
> Key: RANGER-5614
> URL: https://issues.apache.org/jira/browse/RANGER-5614
> Project: Ranger
> Issue Type: Task
> Components: Ranger
> Affects Versions: 2.8.0
> Reporter: Ramachandran Krishnan
> Assignee: Ramachandran Krishnan
> Priority: Major
> Fix For: 3.0.0, 2.9.0
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> In high-scale enterprise environments deploying Apache Ranger, administrative
> tasks often involve creating or syncing massive hierarchical structures
> consisting of thousands of roles, users, and groups. In the unoptimized
> legacy runtime path, when a new role assignment or update was processed via
> the API, the business logic engine executed individual, standalone queries
> against the relational store for every single principal listed in the
> membership array.
> This design resulted in severe performance degradation due to the {*}N+1
> query execution pattern{*}. Specifically, for a role containing $U$ users,
> $G$ groups, and $R$ referenced sub-roles, the relational engine was forced to
> execute distinct lookup operations followed by iterative insertion calls for
> each member. This architecture exhausted open database thread pools, caused
> elevated query latencies, and induced transactional locks during large
> automated sync updates.
> By leveraging configuration flags like ranger.admin.role.create.batch.enabled
> and refactoring data access paths inside RoleRefUpdater.java, lookup loops
> were replaced with collection-level map pre-fetching. Iterative single-record
> creations were updated to utilize underlying database batch extensions,
> drastically minimizing JDBC network overhead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
