Re: OpenLDAP 2.0.15 slower than 1.2.11

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 03:17 AM 2001-09-27, Ricardo J. Sousa wrote:
>Hi,
>
>We have been using openldap 1.2.xx for some time.
>We are now trying to migrate to openldap 2.0.15 but we are finding it
>dificult.
>Our searches on 1.2.xx take 0.007s on average with about 500 000
>objects.
>On a equivalent system using version 2.0.15 the same search lasts over
>5m (5m21.239s according to time).

Add:

        index objectClass eq

and then run slapindex.


>When debuging 2.0.15 (slapd -d 255) we get:
>
>=> equality_candidates
>=> ldbm_cache_open( "uid.dbb", 7, 600 )
>ldbm_cache_open (blksize 8192) (maxids 2046) (maxindirect 5)
><= ldbm_cache_open (opened 3)
>=> key_read
><= index_read 1 candidates
><= equality_candidates 1
><= filter_candidates 1
>=> filter_candidates
>        EQUALITY
>=> equality_candidates
>=> ldbm_cache_open( "s.dbb", 7, 600 )
>ldbm_cache_open (blksize 8192) (maxids 2046) (maxindirect 5)
><= ldbm_cache_open (opened 4)
>=> key_read
><= index_read 348908 candidates
><= equality_candidates 348908
><= filter_candidates 348908
><= list_candidates 1
><= filter_candidates 1
><= list_candidates 348908
><= filter_candidates 348908
><= list_candidates 348908
><= filter_candidates 348908
>entry_rdwr_runlock: ID: 1
>
>Which seems good (reading and parsing the indexes)
>
>but then:
>
>====> cache_return_entry_r( 1 ): returned (0)
>=> id2entry_r( 2 )
>=> ldbm_cache_open( "id2entry.dbb", 7, 600 )
><= ldbm_cache_open (cache 1)
>=> str2entry
><= str2entry(o="Zurich Seguros", c=PT) -> -1 (0x80d5d28)
>entry_rdwr_rlock: ID: 2
><= id2entry_r( 2 ) 0x80d5d28 (disk)
>=> test_filter
>    AND
>=> test_filter_and
>=> test_filter
>    EQUALITY
>=> access_allowed: search access to "o="Zurich Seguros", c=PT" "uid"
>requested
>=> access_allowed: backend default search access granted to ""
><= test_filter 5
><= test_filter_and 5
><= test_filter 5
>ldbm_search: candidate 2 does not match filter
>entry_rdwr_runlock: ID: 2
>
>
>And goes on to test all entries in id2entry taking a very long time. It 
>appears that all entries are candidates, regardless of their contents.
>This should be a configuration bug, but I can't really understand where.
>We have indexes for both (and some more) attributes with presence and
>equality. I don't really understand what is going on here but appears
>that slapd is ignoring the indexes.
>
>Thanks in advance,
>RJS
>-- 
>"Liberty is the Mother, not the Daughter of Order" - Proudhon
>Sys. Adm.                                       eServices/Consultadoria
>PGP Fingerprint: 5C 53 4B CC 90 6D 2E E7  60 54 6B 39 35 E9 28 C5
>Key available in a pgp key server near you