Performance issue with large number of LDAP group

Hi,

We have more than 10K groups and the user login requires more than 6sec due to 1 query per group on the database.

We tried to disable the Import User but groups are still imported and are not refreshed from LDAP on login.

Is there a way to completely disable the database storage of user and groups and query LDAP directly on login?

Thanks,
Luigi

1 Like

Keycloak is not able to handle user with many user groups/roles assigned efficiently…

As you said, for a user login, it takes much time to fire SQL to fetch user group one by one into memory/infinspan cache . What make it worse is that, for each user group, it also take another SQL to fetch the group attributes…

For example, if a user is assigned to 20 groups, it will fire 40 SQL (20 + 20)…

After those user information is cached into infinspan after initial login, it take less time for subsequent login…however, if later the user info is evict from cache, you will suffer again…

I also hit this issue and I have redhat sso subscription and report the problem but seems redhat isn’t responsive / not willing to fix the issue (they classify this to be a request for enhancement)…

If you search the keycloak bug db, this issue is reported around 2019 and there is still no fix for it…

If you have a closer look / check the source code, you will find keycloak is not able to cater effectively for situation where you have many user groups / user roles…likely it is not able to handle other complex situation as well…

I guess it is difficult to fix due to keycloak’s caching mechanism…

So, you’d better to fix it yourself if you need fast initial user login …

2 Likes

Hi ping,

I opened a bug as well KEYCLOAK-17349 with the analysis I have conducted.
In the analysis I saw that Keycloak, regardless how many groups the user have, fetches every group one by one.

Do you have developed something by yourself to fix this?

Thanks,
Luigi

Hi Luigi,

as i am using the redhat sso (commercial version of keycloak), i am still waiting for redhat to fix it…management don’t want to take risk to fix it (may void the commercial support) but rely on vendor…

having a check of the keycloak source code, personally, i think keycloak don’t take much to optimize for initial loading performance, especially for searching for user/user groups/user role…they frequently iterate a long long list to get what they want…

for example, they try to check the whether a user’s LDAP groups are imported into keycloak, they use the code below (pseudo)


for (AD group: user.getLdapGroups()){ //say 100 LDAP groups

for (Group g : realm.getTopLevelGroups()){

/*say 10K groups and fetching each group do trigger one SQL reading group table (and one SQL for group attribute table)…
this is a really bad that it don’t take into account of the DB operation…they assume everything is in infinispan cache which isn’t the case as memory is limited and keycloak likely cannot horizontally scale well [each instance need much memory to cache the data]
*/

//perform group matching, which can takes up to another 1 million (=100 x 10K) comparison for such case.

}
}

We, too, don’t want keycloak’s default behavior of importing groups, even where importing of users has been disabled. We’re currently testing with 12.0.1, but will be moving to a latest release soon. Was this problem ever addressed/fixed? Thanks!

Hi tlemons,

I don’t know if this problem was addressed, I know they threw away the bug I opened!

You can try to adopt this changes,

I hope this can help you.

Thank you very much for this information!

This bug isn’t fixed….redhat reply not able to fix before RHSSO 8…but we don’t know exact date…they don’t give commitment