The good peoplr who administer the LDAP servers for my Enterprise are complaining that periodically my BusinessObjects servers bring their servers to their knees. I suspect this corresponds the LDAP Graph Refresh process (about which I know very little). The queries coming from the BusinessObjects servers are not optimal, in fact, they’re VERY BAD, and causing extremely poor performance both in the BusinessObjects environment (LDAP authentication fails during the long refresh) and in the Enterprise LDAP world (which is very bad, and not appreciated by my colleagues).
Anyone experienced similar? Is it possible to control the LDAP Graph refresh? Is it possible to optimize the queries generated by this process?
Thanks in advance.
benjaminbrill (BOB member since 2008-04-25)
Some additional information about the LDAP query, and the complaint from the LDAP support team:
The query:
Bind name:cn=busobj,ou=admin,ou=services,o=COMPANY, version:3, authentication:simple
Sending operation result 0:"":"" to connection 0x1a7ec340
DoSearch on connection 0x1a7ec340
Search request:
base: “o=COMPANY”
scope:2 dereference:0 sizelimit:0 timelimit:85 attrsonly:0
filter: “(&(objectclass=groupofnames)(|(cn=af34048)(cn=am95919)(cn=as27621)(cn=as76364)(cn=bl41091)(cn=dt62427)(cn=ec44511)(cn=eh25693)(cn=eh57905)(cn=jb93542)(cn=jh31391)(cn=kw42957)(cn=kw76465)(cn=lr24080)(cn=mb72947)(cn=mf29174)(cn=mh50991)(cn=mj11725)(cn=ml277”
attribute: “uniquemember”
attribute: “objectclass”
attribute: “cn”
LDAP Support comments:
You can see on the base - it is o=COMPANY; that is part of what is making it more costly.
You can also see it is querying for groupofnames where cn equals User IDs not group names.
These are all useless queries as they return nothing.
If, instead of querying for User IDs in the groupofnames objectclass, it could query for group names, it would be better.
benjaminbrill (BOB member since 2008-04-25)