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.
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.============================================================
389 users mailing list