On 04/18/2012 01:33 PM, Michael Gettes wrote:
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.
It's essentially the same problem - it doesn't matter if you use member
or uniquemember.
On Apr 18, 2012 2:10 PM, "Russell Beall" <beall(a)usc.edu
<mailto:beall@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 <mailto:beall@usc.edu>
==============================
--
389 users mailing list
389-users(a)lists.fedoraproject.org
<mailto:389-users@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users