[Date Prev][Date Next]
Re: Odd performance problem with substring index
I think what you see is the effect of the so-called allidsthreshold.
You can raise SLAPD_LDBM_MIN_MAXIDS in include/ldap_defaults.h to
lower the probability of being 'hit' by such queries in real life, but
you cannot completely avoid it.
This is a real problem for large directories (like ours, too :)).
Folks, wouldn't it be a good idea to implement a limit on the maximum
number of entries to be examined ?
iplanet offers such a setting, called lookthroughlimit.
IIRC it returns just an error whenever more than this number of entries
would have to be examined. This also prevents that someone kills your
server's performance, e.g. when querying for unindexed attributes.
Setting lookthroughlimit <= allidsthreshold would avoid the allidsthreshold
Oyvind Moll wrote:
> I have an odd problem with OpenLDAP 2.0.7 that I'd like some input on.
> I'm setting up a catalog with approximately a million nodes in it. My
> problem is that the performance of a substring index seems half arbitrary,
> dependent on where in the search string I put globs (*) -- _sometimes_
> OpenLDAP seems to do a linear search, even though the attribute searched on
> is indexed.
> To be more concrete, the relevant part of my catalog structure is like
> - uid: foo
> - mail: firstname.lastname@example.org
> - ...
> Now, I have eq and sub indexes on the mail attribute, so I expect the
> following searches to return the correct result pretty quickly:
> 1. (email@example.com)
> 2. (firstname.lastname@example.org*)
> 3. (email@example.com)
> 4. (firstname.lastname@example.org*)
> 5. (mail=foo@doma*in2.com)
> 6. (mail=foo@*domain2.com)
> 7. (email@example.com)
> My observation is that only searches 1 and 2 respond quickly (<0.1sec),
> while the others use several minutes, pretty much the same time as a search
> on a non-indexed attribute.
> However, if I add another glob to searches 5-7, I can get better
> performance. The following perform quickly:
> ...while the following are very slow:
> Is it a known issue? If so: is there a general work-around I can rely on?
> Apart from this issue, I'm happy with the performance of OpenLDAP with a
> million nodes. Even the write performance, with a couple of indexes and
> with the database files on a RAID5 volume, is pretty good.
> Øyvind Møll
tel;fax:++49 +5241 80-67867
tel;work:++49 +5241 80-7867