# $OpenLDAP: pkg/openldap-guide/admin/tuning.sdf,v 1.8.2.2 2007/01/02 21:43:43 kurt Exp $# Copyright 1999-2007 The OpenLDAP Foundation, All Rights Reserved.# COPYING RESTRICTIONS APPLY, see COPYRIGHT.H1: Performance TuningNote: this chapter needs to be updated to discuss BDB tuning.There are several things you can do to tune the performance ofslapd for your system. Most of them have to do with the LDBMbackend. LDBM uses an index mechanism to store and retrieveinformation in slapd. Each entry is assigned a unique ID, used torefer to the entry in the indexes. A search for entries with asurname of "Jensen", for example, would look up the index entry"=JENSEN" in the surname index. The data returned is a list ofIDs of entries having that value for the surname attribute. Wehave found several things to be useful in improving theperformance of this indexing scheme, especially on modifyoperations.H2: The allIDs thresholdSome index entries become so large as to be useless. Forexample, if every entry in your database is a person entry, the"=PERSON" index entry in the objectclass index contains everyentry. This returns very little useful information, and can causesignificant delays, especially on updates. To alleviate thisproblem, we have introduced the idea of an allIDs index entry.The allIDs entry stands for a real index entry containing the IDsof every entry in the database, but it takes up very little space,never needs updating, and can be manipulated quickly andefficiently. The trade-off is that it does not prune the set ofcandidate entries at all during a search. This must be doneusing other, more "high-powered" index entries.You can set the minimum number of IDs that an index entry maycontain before it turns into an allIDs block by changing the{{EX: SLAPD_LDBM_MIN_MAXIDS}} variable in the{{EX: include/ldapconfig.h}} file. The actual number is determined atruntime by the LDBM backend, depending on the block size ofthe underlying device (i.e., the number you provide is rounded upto the nearest multiple of a block size).H2: The entry cacheThe LDBM backend can be configured to keep a cache ofentries in memory. Since the LDBM database spends much of itstime reading entries from the id2entry file into memory, this cachecan greatly speed performance. The trade-off is that the cacheuses some extra memory. The default cache size is 1000entries. See the discussion of the cachesize option in Section5.2.3 on LDBM configuration.H2: The DB cacheThe LDBM backend uses a number of disk-based index files. Ifthe underlying hash or B-tree package supports in-memorycaching of these files, performance can be greatly improved,especially on modifies. The size of this in-memory file cache isgiven by the dbcachesize option, discussed in more detail insection 5.2.3 on LDBM configuration. The default {{EX: dbcachesize}} is100K.H2: Maintain the right indicesFinally, one of the best performance tune-ups you can do is tomake sure you are maintaining the right indices. Too few indicescan lead to poor search performance. Too many indices canlead to poor update performance. For example, the LDBMbackend would be perfectly happy to maintain substring andapproximate indices for the {{EX: objectclass attribute}}, but this wouldnot be useful and would just slow down update operations. Ifyour database has many entries and is handling queries forsubstring equality on the surname attribute, you should makesure to maintain a surname substring index so these queries areanswered quickly.So, take a look at the index lines in your slapd configuration file toensure that only those indices that make sense and are neededare being maintained.