Autoscaling question: Does adding new node to cluster helps in reducing the load on existing muc rooms ?

[aadimurthy]

Hi, Currently, we have a server running cluster 2, exclusively utilizing MUC rooms and not single chats. As far as I understand, both nodes run Erlang processes related to these MUCs and handle message routing for respective participants on their respective nodes.

For instance, assuming an ideal scenario where nodes equally receive requests for creating rooms: if there are 10 existing MUC rooms in the cluster, I expect the Erlang processes of 5 MUC rooms to reside on node 1 and the other 5 processes on the second node make the ideal scenario of share the load.

However, over time, we expected that the number of participants in MUCs would likely increase in huge numbers, and new MUC groups would also be created.

My question would be:

1. Will adding a new node to the cluster help distribute the load on existing nodes? Is there a possibility of migrating existing MUC processes to the new node to alleviate the load on the current nodes?

2. Moreover, as the number of participants grows, more routing will be necessary within the MUC Erlang processes. Will this routing be distributed and utilize the additional computing power introduced by the new node?

3. Also If I delete a node from the cluster will it bring down MUC rooms running on that node?

[badlop]

we have a server running cluster 2, exclusively utilizing MUC rooms and not single chats. As far as I understand, both nodes run Erlang processes related to these MUCs and handle message routing for respective participants on their respective nodes.

Right. In ejabberd, a MUC room is represented by an erlang process. That process is created in the node where the XMPP client is connected when he requests the room creation. The room name and the process identifier is stored in the table muc_online_room.

For example I have two nodes that i joined using "join_cluster". Then a client logins to a node and creates a room. I check in an erlang shell in that node:

ets:tab2list(muc_online_room).
[{muc_online_room,{<<"room1">>,<<"conference.localhost">>},<0.726.0>}]

In the other node I get:

ets:tab2list(muc_online_room).
[{muc_online_room,{<<"room1">>,<<"conference.localhost">>},<30503.726.0>}]

That other node knows that the room exists, knows the erlang process identifier, and we can see that the process is located in another node (because its process identifier does not start with <0..

assuming an ideal scenario where nodes equally receive requests for creating rooms

Right, that would be ideal: that clients request room creation in the node with lower load, or at least randomly. In general a room process lives in the node where the room was created.

1. Will adding a new node to the cluster help distribute the load on existing nodes?

Not for the existing rooms, as they continue in their corresponding nodes.

Is there a possibility of migrating existing MUC processes to the new node to alleviate the load on the current nodes?

I couldn't find anything like that in mod_muc.erl or mod_muc_room.erl

2. Moreover, as the number of participants grows, more routing will be necessary within the MUC Erlang processes. Will this routing be distributed and utilize the additional computing power introduced by the new node?

Most of the routing for a room will be done by the process that runs the room, which lives in the node where it was created (or in the node where it is first accessed, in case it already existed)

3. Also If I delete a node from the cluster will it bring down MUC rooms running on that node?

Yes. And when a user attempts to join one of those rooms, it is started in the user node, as mentioned in the mod_muc documentation:

This module supports clustering and load balancing. One module can be started per cluster node. Rooms are distributed at creation time on all available MUC module instances. The multi-user chat module is clustered but the rooms themselves are not clustered nor fault-tolerant: if the node managing a set of rooms goes down, the rooms disappear and they will be recreated on an available node on first connection attempt.

Sidenotes: chatrooms may be used for chatting (sending messages) and/or sharing presence (available or offline, chatty or away, ...). If you are only interested in chatting and don't care about presence, then maybe you don't need MUC.

For example, if your clients join/leave frequently, there are many occupants in a room, but you don't care about presence information, then the MUC service is distributing presence information that is useless, right?

In that case, you may be interested in MucSub, which is a method to get messages from a room without joining it (and avoiding presence broadcast overload).

Another method to broadcast messages to subscribers and avoid presence broadcast is PubSub