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

RE: ldapadd performance



Revisiting this email with a new set of numbers, back-bdb with transactions
completely turned off:

back-bdb
10000 entries
slapd 54.410u 7.210s 8:51.04 11.6%    0+0k 0+0io 1372pf+0w
ldadd 6.730u 1.580s 8:38.74 1.4%      0+0k 0+0io 261pf+0w

The CPU utilization is not much different (11.6%) than the transaction case,
even though the run time is much faster. This seems to imply that if you can
set up the database with the transaction log on a separate physical volume,
there should be much less performance cost for transactions. (Of course, my
test machine has only one disk. Anyone care to experiment with this?)

> -----Original Message-----
> From: Howard Chu [mailto:hyc@highlandsun.com]
> Sent: Monday, November 05, 2001 12:08 AM

> Here are some times running ldapadd against slapd on a PII-400 Linux box,
> adding thousands of entries. The machine has 256M RAM and no
> swapping has occurred on the system thus far.

> back-ldbm dbnosync
> 10000 entries
> slapd 236.250u 102.900s 11:29.12 49.2%        0+0k 0+0io 4866pf+0w
> ldadd 6.560u 1.090s 9:05.58 1.4%      0+0k 0+0io 2044pf+0w

> back-bdb dbnosync
> 10000 entries
> slapd 77.710u 46.730s 17:43.35 11.7%  0+0k 0+0io 2292pf+0w
> ldadd 6.660u 1.490s 14:30.48 0.9%     0+0k 0+0io 2131pf+0w

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