powered by Jive Software

Converse.js Login Performance

Recently deployed a new Openfire server on Rocky 8.4, connected with LDAP. We have about 850 users across maybe 32 groups. The admin pages for users and groups can take a couple minutes to load (the user page is worse).

When connecting to to the server with /inverse (converse.js plugin), the login process can take a couple minutes and then the page will sit on “connecting” indefinitely. If you wait 10 minutes and reload the page it will load and you can use the interface.

Is there a way to improve performance of LDAP user/roster enumeration with these web services? Other clients like spark, pidgin, and xabber, don’t seem to have this long login time.

The only tweak I have made was to set the LDAP cache to 1Mb due to warnings in the logs during service startup. We are using about 50% of that cache now with no warnings in the logs.

Let me know if you need any more information, thanks!

Groups, and particularly nested groups, have been a known source of contention in older versions of Openfire. That has been fixed in later releases. Are you using the latest release?

It’s weird that this is a problem with Converse, but not other clients. I’d expect this to be a problem that occurs while obtaining the roster. Converse does that in the same way as other clients (unless some client-sided caching / roster versioning is in play maybe), so I wouldn’t expect much of a difference there.

Can you dump the traffic that Converse receives, including timing, and see what takes a few minutes to complete? That might give us a hint as to what is causing this delay.

Openfire Version: 4.6.4 (openfire-4.6.4-1.x86_64.rpm)
Inverse Plugin Version: 7.0.6 Release 2

Interesting you mention nested groups because in testing I couldn’t get nested groups to work. I could have overlooked something but settled on below configuration.

ldap.groupSearchFilter = (&(objectClass=group)(cn=xmpp-*-users))
ldap.searchFilter = (&(objectClass=organizationalPerson)(memberOf=CN=xmpp-users,OU=XMPP,OU=Application Access Groups,OU=Security Groups,DC=domain,DC=tld))

It’s only a little annoying that I need to add any given user to two different groups for them to be able to login and be placed in a group… think this can be causing performance issues, or is there a better way? I’d much prefer recursive/nested groups for administration but like I said it’s mostly a minor annoyance. Management of users and groups will be automated.

Let me know what you think of the above and I’ll do some more testing to confirm that it doesn’t actually impact other clients in different ways and I’ll see if I can collect some more information from browser console on login.

Thanks, Guus!