Pierangelo Masarati wrote:
I haven't investigated this issue yet but would exploiting multiple CPUs
allow faster slapadds (with -q, i.e. with less consistency checks) if, for
instance, the entry and the indices are generated concurrently? Much like
the ancient ldif2index. This comes from the consideration that on the
machine we're testing giant slapadds, we have 75% to 87.5% of the CPU
idle...
Does anybody see any big stopper to this approach?
I actually added multi-threading code to slapadd in a previous
experiment. It's probably still in CVS, but I removed the code because
it yielded no measurable improvement. I think the problem is that this
will be I/O bound regardless of what CPU resources are available.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
