[Date Prev][Date Next]
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.
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
Symas: Premier OpenSource Development and Support