How do you improve User Search performance for an LDAP federator with many users? #9733
Unanswered
SomeDeveloper13
asked this question in
Q&A
Replies: 1 comment 1 reply
-
|
If you Enable Periodic Sync, it will no longer attempt to sync on every request. |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
The above response was only partially correct. It still hits LDAP, just lest frequently. See original code for reference:
@Override
public UserModel validate(RealmModel realm, UserModel local) {
logger.debug("========== validate ==========");
/* Bypass LDAP Search Piece. */
return proxy(realm, local, false);
}
private UserModel proxy(RealmModel realm, UserModel local, boolean newUser) {
logger.debug("========== custom proxy ==========");
UserModel existing = userManager.getManagedProxiedUser(local.getId());
if (existing != null) {
return existing;
}
// We need to avoid having CachedUserModel as cache is upper-layer then LDAP. Hence having CachedUserModel here may cause StackOverflowError
if (local instanceof CachedUserModel) {
local = session.userStorageManager().getUserById(realm, local.getId());
existing = userManager.getManagedProxiedUser(local.getId());
if (existing != null) {
return existing;
}
}
UserModel proxied = local;
switch (editMode) {
case READ_ONLY:
if (model.isImportEnabled()) {
proxied = new ReadonlyLDAPUserModelDelegate(local);
} else {
proxied = new ReadOnlyUserModelDelegate(local);
}
break;
case WRITABLE:
case UNSYNCED:
// Any attempt to write data, which are not supported by the LDAP schema, should fail
// This check is skipped when register new user as there are many "generic" attributes always written (EG. enabled, emailVerified) and those are usually unsupported by LDAP schema
if (!model.isImportEnabled() && !newUser) {
UserModel readOnlyDelegate = new ReadOnlyUserModelDelegate(local, ModelException::new);
proxied = new LDAPWritesOnlyUserModelDelegate(readOnlyDelegate, this);
}
break;
}
if (!model.isImportEnabled()) {
proxied = new UpdateOnlyChangeUserModelDelegate(proxied);
}
return proxied;
}
|
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I'm using an LDAP Federator. When the number of users is low, search performance is fine, however as the number of users increases, performance sharply degrades to the point where searching by only first name times out before the search can finish.
How can I update the settings to improve performance? Or is there an SPI I can install/create to force it to only check the DB & not reach out to the federator for each search?
We currently pull in around150,000 users and that number will continue to grow as we onboard new groups.
If the LDAP Federator is disabled, search results return almost instantly, so the bottleneck is definitely in the Federator, but don't know if it's a setting, or if for some reason it's trying to hit LDAP instead of just searching the keycloak users.
Settings for User Federator:
Beta Was this translation helpful? Give feedback.
All reactions