Authorization Extension - Get Group Members performance

Help
1

Hello,
I’ve noticed the performance of GET /groups/{group_id}/members is really bad.
I’m calling it with per_page=15&page=1 and it takes about 5.5-6 seconds.

There are only 12 users in this group, so I find it bizarre it takes so long to return.
What I find even weirder, is that if I use “per_page=10&page=1” it returns in 200ms.

Any idea what is happening?

2

Hey there!

Can you record us a HAR file of that so we can investigate it? Thanks!

3

get_members.har (6.4 KB)

Thank you

5

Woah indeed that’s a huge response time. Are you able to reproduce that? Are you sure that it’s not an issue with your Internet? Please make sure to check it and once we have it confirmed I’ll raise an issue to the engineering team.

6

I get the same results when sending the request from my local computer (Israel) as well as a remote machine on AWS (Ireland), so I think this rules out everything ISP or location related.

I’ve noticed a couple of things regarding the high latency:

  • I do not see high latency for groups that have a small number of users (<10), although 12 is sufficient to reproduce the problem.
  • Contrary to my first message, setting “per_page” to a lower number does seem to help, but only temporarily. I do get very fast responses for per_page < 10 but occasionally it’s 5-6 seconds just as I see with per_page = 15.
  • I thought maybe the problem was with rules that add to user_metadata, so I turned those off. It didn’t help.

Please let me know if you have any leads.

7

Gotchya! Let me open an internal engineering ticket for that to have some reasoning from appropriate engineering team.

8

Once I have any update on that front I’ll let you know. Can you also send me your tenant name via private message if it can be of any help to the team? Thank you!

9

Got an update on this one.

One of our engineers the code and here’s why there’s a different between per_page=10 and per_page=15:

The endpoint logic goes through the list of users in the group and calls our management API to fetch them one by one (auth0-authorization-extension/users.js at master · auth0/auth0-authorization-extension · GitHub) - The first 10 requests happen “in parallel”, but the other 5 don’t, they have to wait (link to code is public)

In the internal logic, it’s also trying to handle requests that are being rate limited and retry after some time to avoid errors on the front end - auth0-authorization-extension/apiCall.js at master · auth0/auth0-authorization-extension · GitHub (link to code is public)

Increasing the per page has a negative effect as it does more requests in less time (and without much benefit as we only do 10 in parallel)

10

Thank you.
If I understand correctly, setting per_page to 10 will yield the optimal result, as long as I don’t make too many calls in a short period of time so as not to trigger rate limiting.

If possible it would be great if you could:

  1. add some info on best practice for configuring per_page in the documentation
  2. when implementing groups functionality in authorization core, build it so it doesn’t have such a bottleneck.

Is there an estimate for when the groups feature would be releases in authorization core?

11

Yep that’s correct.

To address your points:

  • Yep I’ll relay that feedback to our docs team in a minute
  • I’ll relay that feedback to the engineering team

No ETA for releasing the groups feature. I’ll let you know as soon as I know something