RE: Ximian Evolution vs OpenLDAP

["Howard Chu" <hyc@highlandsun.com>]

Many of those attributes are phone numbers and other such things that should
only have numeric values (maybe with hyphens and some other punctuation
thrown in) as opposed to regular text. Perhaps a large number of them can be
eliminated as bad filters. But really, this looks like a prime example of
garbage-in-garbage-out. It seems wrong to put much effort into making
OpenLDAP accomodate a braindamaged client.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Andrew Findlay
> Sent: Wednesday, March 20, 2002 3:46 PM
> To: openldap-software@OpenLDAP.org
> Subject: 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*)(p
rimaryPhone=*bradley*)(telephoneNumber=*bradley*)(homePhone=*bradley*)>
(mobile=*bradley*)(carPhone=*bradley*)(badfilter)(homeFacsimileTel
ephoneNumber=*bradley*)(otherPhone=*bradley*)>
(otherFacsimileTelephoneNumber=*bradley*)(internationaliSDNNumber=
> *bradley*)(pager=*bradley*)(radio=*bradley*)(telex=*bradley*)(assi
stantPhone=*bradley*)(companyPhone=*bradley*)(callbackPhone=*bradley*)>
(tty=*bradley*)(o=*bradley*)(ou=*bradley*)(roomNumber=*bradley*)(t
> itle=*bradley*)(businessRole=*bradley*)(managerName=*bradley*)(ass
istantName=*bradley*)(postalAddress=*bradley*)(homePostalAddress=*bradley*)>
(otherPostalAddress=*bradley*)(badfilter)(displayName=*bradley*)(s
pouseName=*bradley*)(note=*bradley*)(anniversary=*bradley*)(birthDate=*bradl
ey*)> (mailer=*bradley*)(fileAs=*bradley*)(categories=*bradley*)(badfilt
> er)(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        |
> -----------------------------------------------------------------------