OpenLDAP Faq-O-Matic: Can more indexes improve performance?

	OpenLDAP Faq-O-Matic : OpenLDAP Software FAQ : Configuration : SLAPD Configuration : Performance Tuning : Can more indexes improve performance?
	In general, yes. But each index requires time to maintain and uses additional memory. General rule: index attributes you frequently search for. index cn,sn,givenname,mail eq
	Each attribute index can be tuned further by selecting the set of index types to generate. For example, substring and approximate search for organizations (o) may make little sense (and isn't like done very often). And searching for userPassword likely makes no sense what so ever. General rule: don't go overboard with indexes. Unused indexes must be maintained and hence can only slow things down.
	See Also: How do I add an index after populating the database?
	To understand how indexes improve performance at all, you must understand the following points. The information below explains why the indexes that you maintain depend on the search patterns that will be used most often by LDAP clients. (1) One set of operations supported by LDAP is the interrogation operation, which allow LDAP clients to search a directory for data. Don't worry about the details of the operation -- clients will probably take care of the details for you. The search parameter that we care about, is the search filter. The filter expression is quite flexible -- see other documentation for details. I recommend the book "Understanding and Deploying LDAP Directory Services" by T. Howes et al. Valid LDAP search filters include, for example, equality, substring, and presence. (2) Indexes are generally used to improve the performance of searches. OpenLDAP supports various indexes. For a complete list of OpenLDAP index types, see the man page on slapd.conf. With these points in hand, it should be clear how to use indices: index exactly those attributetypes that your clients will search for most often. Further, create index types that match the types of searches being performed (or, in other words, that match the search filters being used). Conveniently (and, I'm sure, by design) the OpenLDAP index types map EXACTLY onto the LDAP search filter types. So, if clients are going to do lots of trailing substring searches on the cn attributetype, then you will probably want to generate an index to facilitate EXACTLY this type of search. Add the following line to your slapd.conf file: index cn subfinal Then, use the slapindex utility to regenerate your indices.
	If, after you add any indexes your slapd still appears to be really slow, try adding an equality index for objectClass. Reindex using slapindex and try again.
	Additional note to above mentioned.. This doesn't always work. The syntax for the parsing engine I believe is rather picky.. I've had lots of things for indexes look like they would work but didn't. I also had a lot of them that worked in 1.X that didn't in 2.X. Wierd quirks are the bane of OpenLDAP. Anyways, IBM has a lot of good LDAP stuff I found on lookups I've done on google. So here's the goods... If you're using qmail-ldap or just about anything these indexes work well for authentication/mail lookups... index objectClass eq index mailAlternateAddress pres,eq index cn pres,eq index mail pres,eq or for sendmail index objectClass eq index mailLocalAddress pres,eq index cn pres,eq index sn pres,eq index mailroutingaddress pres,eq Uhh, I'm going to slap some keywords on here and maybe get the google rating up for people looking for this kind of information: slapd help qmail-ldap slow ldap lookups. index slapd.conf sendmail slapd. qmail-ldap help slow ldap lookups index slapd.conf.
	Indexing in OpenLDAP: The types of indexing available map 1 to 1 with the types of filter comparisons available in the LDAP protocol. Yes, you should create indices to match the actual filter terms used in search queries. Almost no applications use presence filters in their search queries. Presence indexing is pointless when the target attribute exists on the majority of entries in the database. In most LDAP deployments presence indexing should not be done, it's just wasted overhead. Here's the capsule summary of how a search works - if you're searching on a filter that has been indexed, then the search reads the index and pulls exactly the entries that are referenced by the index. If the filter term has not been indexed, then the search must read every single entry in the target scope and test to see if each entry matches the filter. Obviously indexing can save a lot of work when it's used correctly. But assuming your application actually does use presence filters, if the target attribute exists on the majority of entries in your target scope, then all of those entries are going to be read anyway, because they are valid members of the result set. In a sendmail MTA subtree, where 100% of the entries are going to contain the sendmail attributes, the presence index does absolutely NOTHING to benefit the search because 100% of the entries match that presence filter. So the resource cost of generating the index is a complete waste of CPU time, disk, and memory. Don't do it unless you know that it will be used, and that the attribute in question occurs very infrequently in the target data. The most common message you'll see that you should pay attention to is: "<= bdb_equality_candidates: (foo) index_param failed (18)" That means somebody tried to use an equality filter (foo=<somevalue>) and attribute foo does not have an equality index. If you see a lot of these messages, you should add the index. If you see one every month or so, it may be acceptable to ignore it. ghenry@suretecsystems.com, hyc@openldap.org
	[Append to This Answer]

Previous:	What system parameters factors in performance?
Next:	Can I tune logging to improve performance?

This document is: http://www.openldap.org/faq/index.cgi?file=42

	[Search]	[Appearance]
This is a Faq-O-Matic 2.721.test.