Hello,
I’m running OpenLDAP 2.4.40 on two multi-master servers with replication enabled. Today we switched over to this instance, imported all users from the old ldap server, and configured an ldap client to use this instance.
Everything is working well, users are authenticating and able to access their assigned groups.
However, we noticed that while on the ldap client and as a regular user we type “w” to see who is logged on this machine, it takes a while before we get a response with the results. If we type “w” again the response is very fast due to caching.
In looking at ways to improve performance of ldap, is slapindex a tool to use? Meaning after importing users accounts from an older ldap, should slapindex be ran? Or is this tool is used when you want to modify/add entries found in the slapd (cn=config.ldif) and database ((olcDatabase={2}hdb.ldif) configuration files not when users are added to the ldap database.
If slapindex is not a tool to use to monitor performance, what do you recommend?
Thank you, Liz
On 12/14/2016 10:05 PM, Real, Elizabeth (392K) wrote:
However, we noticed that while on the ldap client and as a regular user we type “w” to see who is logged on this machine, it takes a while before we get a response with the results. If we type “w” again the response is very fast due to caching. [..] In looking at ways to improve performance of ldap, is slapindex a tool to use?
I'm not sure whether changing indexing configuration is the right way to really improve things. Hint: Adding indexes can make search performance worse.
So you should first carefully analyzes which LDAP search queries are sent to the LDAP server.
You also did not provide any information about the LDAP-enabled NSS client used and its configuration (which is better discussed on the mailing list of that software though).
Ciao, Michael.
On 14/12/16 22:05, Real, Elizabeth (392K) wrote:
However, we noticed that while on the ldap client and as a regular user we type “w” to see who is logged on this machine, it takes a while before we get a response with the results. If we type “w” again the response is very fast due to caching.
One way to avoid slow responses is to index whatever you will support searches for, and then set the "unchecked" limit. That's the limit for how many candidate entries a search is willing to examine after consulting indexes, scope etc. If there are more, the search fails immediatly with adminSizeExceeded.
That way you get a quick failure instead of a uselessly large result slowly - provided you take care to index the attributes the user may search for. "Uselessly large" as in - if the user got 100 entries in response to the "w", he'd likely rather type in another character than then browse through the list of results.
openldap-technical@openldap.org
-
Hallvard Breien Furuseth -
Michael Ströder -
Real, Elizabeth (392K)