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@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
==============================






--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users