> The most likely reason for slow performance is that one or more of the > attributes does not have a substring index in your directory server. In > general, end users may not have enough influence to convince the people > who run a corporate LDAP server to add new indexes... it seems like the > end user needs some way to control what kind of search filter is used.
Thanks for the reply Mark, I wanted to clarify one more issue. Looking at this more closely, the OID values of "cn" and commonname" are idential, similarily "fax" and "facsimiletelehonenumber" and "sn" and "surname" for the inetOrgPerson schema. So I presume the fact that we are selecting "cn, commonname" is itself a waste of bandwidth and generating a where clause of "(!(cn=*)(commonname=*)) would likewise be a waste of effort. thanks john. > > John Marmion wrote: > > We are investigating the following bug and I was > > wondering if anyone might want to comment: > > > > http://bugzilla.mozilla.org/show_bug.cgi?id=126749 > > > > The bug occurs because there is the possibility of > > having multiple ldap attributes for a single mozilla > > attribute. > > > > Typically we wanted to be able to translate the following LDAP > > query: > > > > Fax contains '123' i.e. (Fax=*123*) > > (!(fax=*123*)(facsimilenumber=*123*)) > > > > Or > > > > from > > name containg "Marm" i.e. (DisplayName=*Marm*) > > to > > (|(cn=*Marm*)(commnoname=*Marm*)(displayname=*Marm*)) > > > > i.e. use all the LDAP mappings available in the > > nsAbLDAPProperties.cpp > > > > When we run the latter query against our internal LDAP > > Servers then we get a severe performance problem compared > > to running against the existing mapping for this query i.e. > > (cn=*Marm*). > > > > We don't know if this is due to an indexing issue on our servers > > or if it is a general issue with LDAP data i.e is it somehow that > > the poor performance is down to the server sorting out > > duplicate results. > > > > We would be keen if anyone has any thoughts on this. Note the > > same performance behaviour can be observed by executing the > > command line utility 'ldapsearch' and thus is not related to > > mozilla. > >
