[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Ximian Evolution vs OpenLDAP
I am having problems getting good search performance for the
combination of Ximian Evolution and the OpenLDAP server. The database
is not large (just over 1000 entries), yet searches take several
seconds. The problem seems to be the form of search that Evolution
issues. Here is a typical log entry:
Mar 20 17:38:39 server ldap[2120]: conn=11 op=22 SRCH base="dc=contacts,dc=netproject,dc=com" scope=2 filter="(&(mail=*)(|(cn=*bradley*)(sn=*bradley*)(mail=*bradley*)(primaryPhone=*bradley*)(telephoneNumber=*bradley*)(homePhone=*bradley*)(mobile=*bradley*)(carPhone=*bradley*)(badfilter)(homeFacsimileTelephoneNumber=*bradley*)(otherPhone=*bradley*)(otherFacsimileTelephoneNumber=*bradley*)(internationaliSDNNumber=*bradley*)(pager=*bradley*)(radio=*bradley*)(telex=*bradley*)(assistantPhone=*bradley*)(companyPhone=*bradley*)(callbackPhone=*bradley*)(tty=*bradley*)(o=*bradley*)(ou=*bradley*)(roomNumber=*bradley*)(title=*bradley*)(businessRole=*bradley*)(managerName=*bradley*)(assistantName=*bradley*)(postalAddress=*bradley*)(homePostalAddress=*bradley*)(otherPostalAddress=*bradley*)(badfilter)(displayName=*bradley*)(spouseName=*bradley*)(note=*bradley*)(anniversary=*bradley*)(birthDate=*bradley*)(mailer=*bradley*)(fileAs=*bradley*)(categories=*bradley*)(badfilter)(badfilter)))"
This one returned three entries, with elapsed times of 3s, 4s, 9s
respectively. The final search result was logged 17s after the query!
I have indexing on a few attributes:
index default pres,eq,sub
index objectClass eq
index cn
index sn
index uid
My reading of the query shown is that it is looking for any entry
containing the substring "bradley" in any one of 41 different
attributes (several of which are not in our schema) where the entry
also contains a mail address. This is really hard to optimise with
indexing: the best that would happen is that every entry with a mail
attribute would be extracted by index and then compared with the rest
of the filter, but this only cuts out about 10% of the database!
To me, the search strategy is ridiculous, but it is what Evolution
currently does. Can anyone think of a way to configure OpenLDAP to
respond quickly to such queries without having to keep indexes for
every attribute mentioned?
Andrew
--
-----------------------------------------------------------------------
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| Andrew.Findlay@skills-1st.co.uk +44 1628 782565 |
-----------------------------------------------------------------------