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

Re: back-bdb IDL limitations

Hm, I think you're right, it was probably only around a 5-10% difference. I was misremembering some things. The current slapadd is around 30% faster than before, but most of that came from fixing str2entry. Would have to dig up my notes to be sure (and they're not handy at the moment).

Jonghyuk Choi wrote:

From experiments, I didn't see a significant reduction in the population time by the removal of the transactions. The experimental data shows instead that it is the number of database operations which has more effect on the performance of the directory population.
- Jong-Hyuk

David Boreham wrote:

> >
> A transaction begins and commits on a cluster boundary as well. If
> something bad happens in the middle of slapadding, the database
> will remain intact up to the previous cluster commit. I don't see
> this as a limitation as long as the administrator is given the
> information on the point his/her slapadd progressed to and as long
> as the cluster size is not too large.
> I see. I missed the point that this was for slapadd. I thought you
> were descibing a mechanism that would be used for regular
> LDAP operation processing (ADD, MOD...). I don't think you
> need transactions (nor locking) in slapadd.

Agreed. The '-q' quick flag for slapadd in 2.3 turns off transactions
and locking. It makes things quite a bit more tolerable for large bulk

 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support