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(a)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(a)gmail.com
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user