Search Times and Multi-valued Attributes
Search times in Sun Java System Directory Server 5.2 can be adversely affected by the presence of many multi-valued attributes. The impact is a result of a number of different factors:
- candidate list construction for the search filters
- filter verification on each entry
To service LDAP search requests, Directory Server constructs a "candidate list". The search filter supplied as one of the parameters for an LDAP SRCH operation is applied to each member of the candidate list to determine which item(s) in the list are returned to the LDAP client. The larger the number of items in the candidate list and the more complex the search filter, the more time is used evaluating each item in the list.
When an entry has a multi-valued attribute, each of the values of the multi-valued attribute that is named in the search filter must be evaluated by the search filter as described above. The larger the number of values of a multi-valued attribute the lengthier the candidate list, with the result that more time is spent evaluating the search results before they are returned. A common example of the scenario is a static group. Applications use the object class "groupOfUniqueNames" and the multi-valued attribute "uniqueMember" to group distinguished names - typically UIDs.
The effect on Directory Server operations is predictable and straightforward. Threads allocated to searches and the accompanying search filter evaluation take longer to return results, and these threads are occupied and cannot be used by other search operations.
nsslapd-search-tune is an attribute new to Directory Server 5.2 (not available and not necessary in DSEE6 ). This new parameter is used to modify verification of search filters. The parameter nsslapd-search-tune is constructed as a bit mask by adding the following values:
| Value | Description |
|---|---|
| 1 | bypass filter evaluation for simple search filters |
| 2 | ? |
| 4 | ? |
| 8 | Bypass filter evaluation even if attributes in the filter are to be returned |
| 16 | Bypass complex filter evaluation |
| 32 | Continue evaluation of filter even if candidate list is small |
For example, 17 (16+1) means bypass filter evaluation for simple and complex search filters.
Sign up or Log in to add a comment or watch this page.