Repository navigation
Replies: 2 comments 1 reply
|
Hello, |
1 reply
|
Please, note that we are running version 16.1.0. |
|
Thank you for your response. I was there but unfortunately there is no
detailed instruction to set up a cluster in quarkus. Or i missed something.
…On Thu, Apr 7, 2022, 11:04 Nikolas Laskaris ***@***.***> wrote:
Please, note that we are running version 16.1.0.
However, they have a extensive documentation here
<https://www.keycloak.org/guides#getting-started>, which should have what
you need. There is no equivalent documentation for the "high availability"
mode, since this mode is a wildfly-specific mode.
—
Reply to this email directly, view it on GitHub
<#11145 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKZDKIRAY6GDL7RUK3NDQ2TVD2QI5ANCNFSM5SVZN7UQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8000
Uh oh!
There was an error while loading. Please reload this page.
Hi all.
In our production environments, we have a keycloak setup running in HA mode (with a couple of kc nodes) and a load balancer (nginx) sitting in front.
In our environments, all the keycloak clusters serve a large federation of Identity Providers, currently counting more than 4k IdPs.
We use custom themes (like this one), to show a different WAYF login page to our users, since the keycloak's default does not cope well with such large numbers of IdPs (no paging, no searching, etc).
We also use a few optimisations on the core side, (like this one), which fetches the IdPs in a paged manner (just like the Clients and the Users), and also removes the Idps and the IdpMappers from the Realm serialization sent to the browser (also mended the realm export function).
Up to the recent days, our keycloak instances (v16.1.0) work like a charm in the production environment.
However, we face a large problem whenever an admin updates anything in the realm (even on a 'simple' IdP mapper property) from the admin UI.
This update triggers a full realm invalidation, which means that the realm needs to be reloaded on all of our keycloak nodes.
Our realm contains apart from the 4k IdPs, a couple of mappers for each one of these IdPs, making the reloading from the database even worse. The problem is, that during the reload, all nodes stop responding, which is quite bad for any end user who tries to use keycloak (i.e. tries to login). With some fine tuning we have made, it takes around 10 seconds to reload the realm after each update.
This is expected to increase, as the number of Identity providers increase.
We have considered different approaches:
Option (3) is consistent with the current Keycloak design for Clients and Users and it scales as the number of IdentityProviders and their mappers increase in terms of memory consumption and queries speed. Would you be interested in a PR implementing this? Is there anything else you would propose to address the issue?
All reactions