Adding a group containing a large number of users as subgroup is very slow

Description

When adding a group with a large number of users as a subgroup of another group, the request takes a long time to be completed. For example:

Child_Group contains 6000+ users. Adding this as a sub group to Parent_Group via REST API take more than 30 seconds.

Steps to Reproduce

Using the REST API (Postman Collection is attached):

  1. Create two groups child_group and parent_group

  2. Create 6000+ users and add them to child_group

  3. Add child_group to parent_group

The above can be reproduced using any public API (Java, REST, or JavaScript)

Observed Behaviour

It take a significant amount of time return from step 3. For a child_group with a smaller numbers of users the time taken is shorter. It seems that as the number of users grow, so does the time taken to add child_group as a subgroup of parent_group.

Expected Behaviour

The performance of adding a child group should not be impacted by the number of users inside that child group.

Environment

None

Testcase ID

None

Activity

Show:
Yves Prignon
February 11, 2021, 10:32 AM

Great work Eva! Thanks a lot for your involvement, the result are very impressive from 30s to 4s you exceeded my client’s expectation!

Yves Prignon
February 4, 2021, 10:07 AM
Edited

We spend the afternoon with Eva thinking on a solution to replace group by roles. She found a track of solution that is interesting follow, I’ll discuss it later today with the developer at the client site. We will not remove the use of group entirely, there are still some case where it will be required. And in a big repo having to work with a group of 4000 users is not uncommon. Linked to this MNT, there is another MNT talking about the same issue. So this issue still need to be fixed and our client is looking forward this fix before going in production.
Whatever my current action are, my client need to go in prod in March and he will not have the time to do the role modification before that. As presented yesterday to Eva the business is very complicated, it is not going to be cheap neither fast to fix the current client’s solution. I emphasis on the urgency of the situation and the risk they face when they reach production, the change is going to be integrated in the next Project Increment and we have added analyses task to this sprint and the next one to find a good solution to go from a group based solution to a role based solution.

So please proceed with the fix of this issue on the timeline that has been proposed, I already told my client it was going to be fixed.

Alex Mukha
February 3, 2021, 1:36 PM

I think that is on the right track.
The use cases that are connected to the code (as far as I remember, it was quite a long time ago) are the following:

  • Admins are always authorised. So any new member that is added to admin hierarchy of groups needs to be authorised.

  • It should not be possible to add a deauthorised user to the admin hierarchy

It is not possible to remove these features, so adding a check for parents to be in admin group looks like a valid solution. My only concern is that it may not be possible to improve performance due to limitations of the user/group graph architecture.

Fixed

Assignee

Eva Vasquez

Reporter

Sandeep Reehall

Labels

None

Security Issue

None

Escalated By

CSO

Hot Fix Version

ACT Numbers

01020671

Build Location

None

Regression Since

None

Premier Customer

Yes

Work Funnel End

None

Patch Attached

None

Dependent Version/s

None

Prioritization Score

None

Delivery Team

Customer Excellence

Bug Priority

Category 3

Components

Fix versions

Affects versions