LDAP browsing is extremely slow!

I have successfully setup a connection to our ldap server but when navigating in the admin console to the “Users/Groups” menu items, it takes about 3-4minutes to load the page. Then when I finally select groups, its another 3-4minutes to respond.

When I finally find the group in question, this group has 279 users linked to it, it takes forever and seems never to respond at all. I am still waiting as I type this for it to show the list of users in the group.

What gives? Any suggesstions?

1 Like

Are you connecting to your LDAP server over SSL?

I am experincing the exact same problem (even with the latest 3.7.0 release) and I don’t know what the cause of this is. It would take a good 5-10 min before the group information would come back and would seldomly return (before timeout) when actually viewing group members. Which, is a real pain in the event you want to do group sharing. It gets so bad, the Java memory fills up after some time and locks up the server.

Our network admin put wireshark on our domain controller and saw a constant flow of network traffic from/to the Openfire server. I checked my caching settings and everything looked ok. We have many different applications hitting or domain controller without issue.

I was so happy to see the release notes of 3.7.0 indicating fixed issues with LDAPS but alass it did not fix my issue.

Right now, I simply stay out of the Groups/Users web interface and we are looking at Cisco for future considerations. Too bad, Openfire worked flawless on non-LDAPS connections.

Yh, I have given up on OpenFire! LDAP is just not working properly in our environment either. It takes EXORBENTLY long to simply list the Groups and then when you even find a group with 1 user in it, it takes 5-10min.

Also, I have found that when the group DOES eventually open, it takes FOREVER to add the users to the shared list for contacts and then sometimes, not even all the users have been added. I have found that some users are missing.

I mean, support hasn’t even responded on the above since I opened this thread. They wait for someone else to experience the same problem first!

Ignyte really needs to look in to this if they want this wonderful free product to have a long lifespan!

This LDAP performance issue was originally reported in 2008. Obviously, it has not been addressed since then. We are at the point where we are thinking of getting our hands dirty and taking a peak at the user and group management source code to see what’s going on… It almost feels like Openfire is fetching ALL groups or ALL users for every single look-up even though we are requesting information related to a single user, not the entire list. We are not using LDAP over SSL.

We have the exact same problem. It takes a while to bring up users (2-3 minutes) but it takes 3 times as long to bring up the groups. You can forget about clicking on the group itself. Openfire will most likely time out. We are using LDAP over SSL but the 389 works just as slow…

I use stunnel on my openfire servers to do SSL - It listens on 127.0.0.1:8389, and connects out to my Active Directory environment using SSL. Openfire connects to the local end of the tunnel, so it isn’t doing SSL itself. Works really nicely, and since it is only listening on the loopback interface it doesn’t have many security concerns.

Do you have LDAP connection pooling enabled? What LDAP server are you talking to?

We backend Openfire with AD, and it takes about 30s to pull the list of 2,000 users right after the service has been restarted. We also tweaked some system properties so the whole user list can fit in cache, which helps a lot.

Yes, ldap.connectionPoolEnabled is set to true. We have a 2008 R2 server that runs in the 2003 functionality mode. I also pointed to a different LDAP server (2003 SP2) just to test with the same slow results.

David, where did you tweak the cache and what exactly was changed? Maybe this will help us with the slow speeds.

Thank you.

I set these:

cache.username2roster.size

10485760

Click to edit this property
Click to delete this property

cache.vcardCache.size

5242880

Do you have referral chasing disabled also?

Where is the "referral cahsing’ option? Is it on the DB side or in OpenFire?

It’s an openfire property - You can configure it on the ldap wizard, or this system property. Probably want it set to false.

ldap.autoFollowReferrals

Changing ldap.autoFollowRefferals didn’t help but I appretiate the effort. Thank you.

Hi guys,

Do you have some luck (AKA ‘lot of work to find out’) with it?

I’ve just configured Openfire 3.8.2 with AD and I’m stuck in the same problem: Slow LDAP browsing in users and groups.

Cheers!

I’ve just tried again and it worked…

Withou SSL (389) and with ldap.autoFollowReferrals and ldap.connectionPoolEnabled seted to ‘false’ worked just fine!

Cheers!

Try using the global AD port to connect with

3268