RE: Corrupt index files

[Igor Brezac <igor@ipass.net>]

On Fri, 9 Aug 2002, Howard Chu wrote:

> > -----Original Message-----
> > From: owner-openldap-software@OpenLDAP.org
> > [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Isaac Cruz
> > Ballesteros
>
> > So, which is the most stable configuration in your opinion? Is it
> > openldap 2.0.25
> > + BDB 4.0.14 using ldbm backend?
> > Also, which is the fastest configuration in order to add about
> > 6500000 entries
> > with slapadd? I've tried openldap 2.1.3 + BDB 4, with nosync and a
> > lot of cache,
> > and it gets slower and slower (I have only one disk, and it writes
> > *a lot* of
> > logs), so I'm going to try 2.0.25 with ldbm backend (I suppose
> > this won't write
> > logs...)
>
> OpenLDAP 2.1 is faster than 2.0 in several areas. 2.1.3 with back-ldbm is
> much faster than 2.0.25 with back-ldbm, even with identical BDB 4 behind
> them. My profiles of 2.0.25 vs 2.1.3 (identically configured) with the same
> mix of read/search/add/delete operations shows 2.1 to be about 21% faster
> overall, with searches 30% faster, adds 25% faster, and deletes 23% faster.
> Most of the speedup is due to optimizations in the 2.1 front end, but even in
> the ldbm-specific code there is a speed difference: search 36%, add 7%,
> delete 14%.

I can confirm this.  I compared 2.0.25 ldbm and 2.1.3 bdb search
performance on Solaris 8/9 with a 100,000 entries dataset.  The 2.1.3
version was at least 30% faster.

My issue with 2.1.3 is that lib(ldap|lber) no longer have
ldap_build_filter() and ldap_url_search*().  John Morrissey ldap modules
for apache and proftpd fail to compile.  Although ldap_build_filter() is
fairly easy to replace, I am not certain what is the best way to deal with
ldap_utl_search functions.  Any ideas?

-- 
Igor