It's really like Andrew understood! When I used the term group was to specify a node in the tree (objectclass type groupOfUniqueNames). Group members are uniquemember attributes. We have over 50000 uniquemembers in a single groupOfUniqueNames. We have not set the sortvals, but I will provide. (When configured is necessary to make a new load of data?)
As the management tool, it makes the inclusion or deletion of a single uniquemember attribute at a time. But is not fast these operations thus need some tuning in OpenLDAP and so I'm using you!
As for replication, I'm using delta, because as I read, and get it right, it only replicates the operations on the attributes of the node, and not all its value as is done in other types of replication. I like it to be faster.
Alessandro
-----Mensagem original----- De: openldap-technical [mailto:openldap-technical-bounces@openldap.org] Em nome de Michael Ströder Enviada em: sexta-feira, 30 de janeiro de 2015 09:48 Para: openldap-technical@openldap.org Assunto: Re: Large Number of Transactions x Low performance
Andrew Findlay wrote:
We have a tool (BMC Identity Management (formerly Control-SA))
Check how it modifies the groups.
First of all it's not clear to me whether the original poster really meant group entries.
If it rewrites the whole set of 'member' attributes each time then you are forcing the server to re-index every value.
Not only that it's horribly inefficient. With this approach you run into the famous security issue back in those Windows 2000 days where removed group members were accidently re-added because of concurrent write access.
The efficient way to do this is to specify the value that you want to remove or the one you want to add. It should be very quick.
Additionally LDAP PDUs manipulating many values at once grow very big.
Also look at your replication setup. With this sort of data you really do need delta mode.
delta-syncrepl would only help if group membership is changed only for a few members in one modify request.
Ciao, Michael.