Hey russ, I've got the same problem for large groups using member... We are
coming from an openldap world so not much use of uniquemember yet.
On Apr 18, 2012 2:10 PM, "Russell Beall" <beall(a)usc.edu> wrote:
Does anybody have a pointer to any performance comparisons between
Sun DS
and 389?
I was extremely happy with the performance boost using 389 on a Linux VM
which is 5-8 times faster for ldapsearch operations than the older Sun
machines with Sun DS 6.3.
In testing one of our most important use cases just now, I find that the
ldapmodify speed is many many times slower. This doesn't make much sense,
so I think I'm doing something wrong or having something misconfigured.
Earlier I improved the write performance by using large db cache sizes and
moving the nsslapd-db-home-directory to tmpfs. Now most modify operations
have very little I/O wait except when occasionally flushing the index files
and such, and yet, there is a CPU pegged for very long periods of time,
orders of magnitude higher than on Sun DS.
Is there any documentation on ldapmodify performance that I could review?
Google searching seems eerily silent on the issue… (which also leads me
to believe I have something misconfigured if nobody has been asking about
the issue…)
The particular use case I am working with involves replacing large
quantities of uniqueMember values on entries in ou=groups.
Thanks,
Russ.
==============================
Russell Beall
Programmer Analyst IV
Enterprise Identity Management
University of Southern California
beall(a)usc.edu
==============================
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users