POST token UMA ticket scalability

Configuring the server
22

I updated the JIRA ticket with all the JSON starting with a user. Hopefully, that helps shed some light on what’s going on.

I also pulled down your latest authz-perf branch, compiled it and overwrote the keycloak directory on my docker container. I’m still seeing 30-60 second response times on the token call to exchange for a RPT token.

Thanks for the tip on upping the authorization cache size. We’ll update that in our server configuration. However, the access patterns for our users in our application are very sporadic because it’s a passive IoT application on mobile. So, the mobile application’s normal use case is to login on app open and most likely the cache will not be primed.

Thanks again for all your help here. I’ll be a bit busy over the weekend due to the US holiday but will try my best to login and help in any way possible.

23

I tried reducing the number of users in a user policy to a cap of 64 users max and reducing the users in user policies did not help either.

24

I switched from MySQL 5.6 to Postgres 11.7 for the keycloak DB and the results were night and day. At 125k users with only 1 user in the user policy, I’m getting < 500ms response time to exchange access_token+permission ticket for an RPT token.

So, Postgres is able to make sense of the SQL orders of magnitude better than MySQL.

25

Do you have an easy reproducible example that I can replicate?

26

Unfortunately, I do not have an easy reproducible example. I’m basically calling the API calls in the JIRA ticket 125k times over. I could throw together a jmeter load test that calls the API calls per thread. That would let us tune the concurrency and throughput dynamically. Would that help?

27

If it’s possible, that’d be great.