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
loads...