[keycloak-user] Performance issues with large number of realms (500+)

Stian Thorgersen sthorger at redhat.com
Tue Oct 18 10:04:51 EDT 2016


Keycloak was not designed to support multi-tenancy directly. We made the
decision early on that we can't support true multi-tenancy and that has to
be done through separate instances. This is for security reasons as well as
the fact that we can't sandbox everything (like custom providers, custom
themes, etc.).

In that regards we have never tested with high amounts of realms as we
expect there to be few realms (up to 10 most likely). Nor will we test
this. We won't fix any issues related to high number of realms for this
reason either.

I'm not saying that we don't appreciate your case, but we have other
priorities that we need to work on.

However, if you are able to provide PRs that do not have any side effects
(and also doesn't significantly complicate things) we would be happy to
accept them.

On 18 October 2016 at 15:49, Gabriel Lavoie <glavoie at gmail.com> wrote:

> Hi,
>      our Keycloak setup is being used in a multi-tenant fashion with a
> large number of realms assigned to different instances of our application
> (multiple customers). We are now seeing a few performance issues with the
> startup and administration.
>
> First question: Do you have guidelines on a maximum number of realms that
> Keycloak should support before we split in smaller clusters?
>
> I traced at least 2 things in the KC code that could be improved. Should I
> open tickets for both?
>
> 1 - Slow startup (5 minutes with 500 realms):
> In the KeycloakApplication class constructor, the "isNewInstall()" test to
> check if the master realm must be created triggers the loading and caching
> of all realms. This loading seems to be hit with a similar issue that I had
> in the past with realm export: https://issues.jboss.org/
> browse/KEYCLOAK-2413
>
> The named query that gets executed a lot of times in
> RealmAdapter.getAuthenticationExecution() triggers a flush within
> Hibernate
> every times. If the flush mode gets set to "COMMIT" (can't be changed by
> default but I tested it), the loading time goes down to approximately 30
> secs which is acceptable.
>
> It would likely be a good idea to create a read-only transaction with the
> flush mode set to COMMIT during startup to pre-fill the cache, then
> continue with the rest of the initialization. When the cache is filled,
> accessing info on all realms seems to be fine.
>
> 2 - Slow display of the master realm admin screen.
> When accessing the admin screen, AdminConsole.whoAmI() eventually process
> all the roles on all the realm for the admin
> user. KeycloakModelUtils.searchFor() gets called a lot of times to navigate
> through all the composite permissions. With 500 realms, the user has about
> 6500 total permissions available. This part of the code would likely
> benefit a lot from a cache of the exploded composite permissions.
>
> Thanks,
>
> Gabriel
>
> --
> Gabriel Lavoie
> glavoie at gmail.com
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>


More information about the keycloak-user mailing list