[jdev] Minimising number of MUC rooms

[Theo Cushion]

On 29 May 2012, at 19:28, Kevin Smith wrote:

> On Mon, Apr 30, 2012 at 4:17 PM, Theo Cushion <theo at jivatechnology.com> wrote:
>> We use MUC rooms extensively within our site. They offer us a number of neat features that make them very useful. It gives us a central way to manage who talks to who, can accommodate groups of people chatting and gives us a neat way to deal with keeping a history of everything.
>> 
>> However we've started to see performance issues with using so many MUC rooms (we knew we would get stung by this eventually). Users who have had large quantities of chats need to log into a room for every conversation. We do this so that if a message is posted in one of these rooms, it gets pushed out to all of the recipients and we can then in realtime show "missed messages" (rooms they are not viewing, but are interested in). However, most rooms sit there totally unused.
>> 
>> Each use has a PEP node of rooms they are interested in, and when they log in to the site they get this list of rooms and join it.
>> 
>> The only solution I can think of is to have this PEP list updated so that only rooms which have more than one person in them are shown. The downside is I'm going to end up with a lot more logic hooked on for when people log in and out of the system.
>> 
>> How would you solve this?
> 
> Where are you seeing the performance problems with having many MUCs?
> It should make no odds to a client that it's present in many empty
> MUCs (although I guess if you're talking about thousands, the number
> of join stanzas would get onerous), and servers are likely to scale
> well (empty MUCs will be using almost no resources).
> 
> /K

The performance issue is in the client, every time we have a new connection it has to send a whole bunch of join stanzas. This may not sound like a big deal, but it causes a noticeable delay in all of the processing that has to be done when a page is first loaded.

Of course there are smarter ways of dealing with this, for example prioritising what must be done straight away, giving a nice responsive UI, and then backfilling things like joining the muc rooms. However, it seems unnecessary (for our application at least) for a couple of reasons; We KNOW people will want to join everytime - so why make them ask for it, it starts to step away from dumb client - smart server that I think is the mantra for XMPP implementations.

I imagine we are a fairly isolated in our application wanting clients to auto join rooms every time they connect, so there's no point in addressing this in the standard. However, linking in with the Muc/Pubsub (MEP?) could provide a great way to get around this issue, and be universally useful.

What do you think?

Theo