[Date Prev][Date Next] [Chronological] [Thread] [Top]

Very strange search performance problem...

I have finally gotten to the point of migrating our iPlanet directory to the
openldap (thanks to help from this list) and being able to run our
applications against the new LDAP.  I am seeing a very strange behavior with
searches.  For example, when I start a query, I see the following in the
LDAP log output:

conn=2 op=50 SRCH
base="uid=6225183,ou=People,o=myorg,myorgroot=top,o=myorg.com" scope=1
ber_flush: 629 bytes to sd 13
ber_flush: 521 bytes to sd 13
ber_flush: 543 bytes to sd 13
ber_flush: 520 bytes to sd 13
ber_flush: 524 bytes to sd 13
ber_flush: 532 bytes to sd 13
ber_flush: 534 bytes to sd 13
ber_flush: 524 bytes to sd 13
ber_flush: 559 bytes to sd 13
ber_flush: 526 bytes to sd 13

****3-4 second pause****   <-----------------------

ber_flush: 14 bytes to sd 13
conn=2 op=50 SEARCH RESULT tag=101 err=0 nentries=10 text=

There is ALWAYS a long delay before the last 14 bytes are flushed.
Obviously, this is causing poor application performance due to the large
number of queries of this type.  When I run the same query from a simple
LDAP browser, it does the same thing (long pause).  However, when I change
the filter from(objectClass=myorgservice) to (objectClass=*) it runs
instantly.  I assume this is some indexing problem, but I have an
objectClass index in my slapd.conf:

# Indices to maintain
index   objectClass     eq

Also, there are very few entries under this DN so even if it was an indexing
problem, I can't imagine why it would be taking so long to search the 5 or 6
entries under that UID.  Any idea how I can improve this situation?  I'm a
little new to LDAP indices -- are there any others that I should definitely
have turned on by default?

Thanks alot,
Andy Hofle