On Apr 18, 2012, at 11:15 AM, Rich Megginson wrote:
You mean, with SunDS? On Linux or Solaris?
The Sun DS instance I'm talking about is on Sun v440 machines.
The 389 instance is on relatively new servers with RedHat Linux 6.
Yeah, this particular operation has not been optimized. I believe
SunDS added explicit optimizations for this particular case.
It is becoming painfully apparent as I write more detailed tests. 389 takes time to add
or delete uniquemember values proportionate to the number of values being operated on and
is using about twice as much time to delete as it does to add. Sun DS appears to have
perhaps an almost O(1) algorithm in play on both adding and deleting values.
Is there perhaps some kind of referential integrity setting that is being used and forcing
some kind of lookup of each value, one that we could perhaps turn off? We wouldn't
need such a check because our metadirectory process handles the integrity/consistency
This behavior is especially surprising given that I can run ldapdelete on the entry
followed by ldapadd and the changes are almost instantaneous. I can delete and then
re-add all 852 groups, some with 80K+ unique member attributes, in about ten minutes
Why would membership changes on the group take forever to process if the entire group can
be reconstructed in an instant?
Could this operation be optimized internally by turning the ldapmodify into a two-step
process of ldapdelete followed by ldapadd (locking the entry during the processing and not
actually replicating it that way so the group never appears to be missing)?