Loading group details from LDAP is incredibly slow

Openfire Openfire Support
1

Hi,

I installed Openfire a few days ago and hooked it up to our corporate LDAP server. All user and group details are detected find during the configuration tests.

We have 128 Group objects in our tree, but loading the “Group Summary” page in the admin console takes tens of minutes.

If I click on one of the group names once they’'ve appeared, it again takes ages (tens of minutes) to display the group details. I tried to enable Roster sharing by adding a contact list group name and clicking “Save Contact List Settings” but stopped it after 15 minutes or so of no action.

Originally the there was a problem with the cache running out of memory so I added some system properties:

cache.ldap.size = 10MB

cache.ldap.expirationTime = 10 minutes

cache.userGroup.size = 10MB

cache.userGroup.expirationTime = 10 minutes

Are these values high enough?

The debug log is now filled with:

2007.04.04 14:46:06 Created hashtable with context values, attempting to create context…

2007.04.04 14:46:06 … context created successfully, returning.

2007.04.04 14:46:12 Creating a DirContext in LdapManager.getContext()…

2007.04.04 14:46:12 Created hashtable with context values, attempting to create context…

2007.04.04 14:46:12 … context created successfully, returning.

Our LDAP is otherwise highly performant, so we don’'t think that is the cause. Any suggestions?

BTW, our groups are stored in a tree alongside the user tree (i.e. ou=Group, o=…) and we have 20,000 users so the search is probably wildly inefficient - is there any way we can point the group config at the group ou rather than the base ou?

2

OK, so given that I’'ll look into the code and fix this myself - should loading the group summary when the groups are in LDAP take a very long time anyway?

3

Hi there,

same problem here. Our LDAP directory contains about 60.000 users (although only about 200 of them use instant messaging).

We also have one OU which contains users only, and one which contains groups only.

We have created special groups for the messenger service.

Isn’'t it possible to search for the groups first and then use the uniqueMember field to get the related user information?

Is there any chance we can play with the LDAP filters in searchFilter and groupSearchFilter configuration directives?

Thanks for any suggestions!

Greetings!

4

my install was similarly slow when I was loading every user and group from active directory into openfire. I now have it filtered to show only users of certain groups and only show me the groups that I want. it loads much faster now. I had to do this for licensing for the enterprise version.

5

The User Summary page appears in seconds, but the Group Summary page is just a dead loss. We’‘ve already filtered down to the group types that we need - I don’‘t think we have much more than 100 groups in total, although some of those groups do contain a lot of users. Other than hacking the source to see if I can optimise it myself I don’‘t know what I can do - we certainly can’'t roll it out.

6

One thing people having this problem might want to consider is the filter they are using for distinguishing Openfire Groups from other kinds of Groups. In my implementation, I created a custom objectClass and I filter for it.

If you filter by some other attribute and that attribute is not indexed, then you will see significant slowdown. If user details load quickly, but groups are slow, then all signs point to an indexing problem. Do you have a custom filter for groups?

7

I’'ll check that out.

However I will say that I’'ve downloaded the Openfire source, extracted the relevant LDAP code for doing lookups and written some test cases, and even the slowest ones return in under five seconds.

As far as I can see it’‘s not the LDAP lookup that’'s slow, but some part of the Openfire architecture.