[Tickets #10882] Performance Problem with calender Shares

[bugs at horde.org]

BITTE NICHT AUF DIESE NACHRICHT ANTWORTEN. NACHRICHTEN AN DIESE  
E-MAIL-ADRESSE WERDEN NICHT GELESEN.

Ticket-URL: http://bugs.horde.org/ticket/10882
------------------------------------------------------------------------------
  Ticket           | 10882
  Erstellt Von     | Klaus.Steinberger at Physik.Uni-Muenchen.DE
  Zusammenfassung  | Performance Problem with calender Shares
  Warteschlange    | Kronolith
  Version          | 3.0.13
  Typ              | Bug
  Status           | Unconfirmed
  Priorität        | 3. High
  Milestone        |
  Patch            |
  Zuständige       |
------------------------------------------------------------------------------


Klaus.Steinberger at Physik.Uni-Muenchen.DE (2011-12-23 09:12) hat geschrieben:

Hi,

we discovered a massive performance problem with LDAP groups.

The main problem seems to be related to "attrisdn" parameter in the  
horde LDAP groups settings. We need this setting as in Novell  
edirectory the group membership is a full DN in the "member" attribute  
in the group.
It looks like horde scans for the group membership for every entry in  
a calender which is shared by group.
a calender share with a reasonable number of entries takes minutes to  
show up. A calender shared by user do not show this problem.

The group caching in horde is switched on!

Second problem:  the search for the user DN uses the search base given  
by the group driver parameters. so we have to use the full tree as  
search base inside the group drivers. But as we have groups for many  
other purposes besides the relevant part of the directory for horde,  
this deteriorates the problem massively as many unneccessary groups  
are found.

So a first help would be to use the parameters from the LDAP  
configuration pane to search for the User DN
instead of the parameters from the Group Pane.

Attached is a wireshark dump.