我注意到当我通过SpringLDAP调用modifyAttributes时，执行此操作所需的时间随着LDAP中对象的增长而增加。起初我认为是导致这种情况的是LDAP，但是在打开Ldap审计之后，我注意到情况并非如此。
当我在ldap对象中没有任何东西时，seeAlso属性，在其中添加一些东西需要大约200ms（在Java中，这是在ldap上测量的3ms），但是，当我在seeAlso属性中有大约1000个项目时，我看到在我的ldap审计中大约7秒（在Java中）和不到一秒的时间。
我只能假设SpringLdap由于某种原因增加了这个时间。无论如何，我可以进一步调查，看看真正的瓶颈在哪里，或者我可以优化SpringLdap以避免这种情况吗？
DirContextOperations ctx = ldapTemplate.lookupContext(organizationalRole.getDn());
ctx.addAttributeValue(LdapConstants.ATTR_SEEALSO, applicationRoleDN.toString());
ldapTemplate.modifyAttributes(ctx);
答案 0 :(得分：1)
事实证明，有代码记录了我们从LDAP返回的响应。随着对象的增长，记录的时间增加了。一旦删除，就像我们的问题一样。
作为第二步，我还查看了代码并确保我们现在使用AttributesMapper执行任何lookup / search / searchForObject，以确保我们不会始终查询整个对象的LDAP，而只是查询属性我们感兴趣的是。
答案 1 :(得分：0)
我想知道你看到的是SpringLDAP是否实现了一些错误检查。
大多数目录（eDirectory，Active Directory以及可能还有OpenLDAP）都不允许您向多值属性添加两次相同的值。
也就是说，您不能拥有值为1974的MV attr acmeMyList，然后向其添加第二个值1974。这是一个错误案例。
随着值的数量增加，检查此值的成本会增加，这符合您的模型。
通常索引属性会影响性能。事实证明，如果您在任何对象上拥有超过25个值的任何属性，eDirectory将自动为您添加索引。这是因为维护索引的成本低于向属性添加值的成本。