benetfits of ejabberd versus socket.io+redis

Question

I am in developing of a web service that we are expecting will scale massively soon. The service is now build using clusters of socket.io communicating through a redis layer.

What I am wondering is if there is any benefits of switching over to ejabberd? Will the XMPP-server handle more concurrent users than a node.js+socket.io server?

What is it using socket.i and redis for? Chat? If I knew what it would be used for, I could better answer the question. — James Parsons, Apr 01 '15 at 00:27
Yes, chat: both private chat and chat with multiple users. It is important that all the messages/threads gets stored in the server. — Jing Kjeldsen, Apr 01 '15 at 00:29

score 2 · Accepted Answer · answered Nov 23 '15 at 09:57

Socket.io is very hard to scale like XMPP current solutions (especially ejabberd).

Even if you decided to scale socket.io using Redis Store as most of articles are mentioning That store concept of Socket.IO is build on the idea of syncing all the connection data between every connected node within your cluster. It doesn’t matter which kind of store you are using in Socket.IO as they are all using this concept as it’s build in to Socket.IO store interface, not the stores that you are using.

In order to understand why syncing is bad for Socket.IO stores we first need to know what is synced. We can find this information in the initstore function of the Socket.IO manager. So this is:

Handshake data, the handshake data includes ALL request headers, query strings, ip address, information, urls and possible custom data that you’ve added during authorization.
Ids of all connections that are open, connected and even closed.
Room names and each id that has joined the room.

All this data will be synced through pub/sub to every connected Socket.IO server. So if you have 2 node processes and they both use Socket.IO stores they will both have all the data of all connections in their own process memory. Not in redis as you might assume. It might not be an issue if you have 500 connected users, but once you approach 5.000> connections this can add up quickly.

Check the following articles that might be helpful:

Cluster fucks when scaling Socket.IO

Redis Store and Socket.io

How do I scale socket.io servers?

score 1 · Answer 2 · edited May 23 '17 at 12:09

Honestly, I would say that number of concurrent users is going to depend on more than just your implementation. Googling gave me no definite answer as to which is more robust. XMPP is a standard, and therefore has rules. Web Socket is also a standard, but it does not have a very specific set of rules that govern messaging. My opinion would be to test the two, see which one you prefer. If you need ultra control of messages and what happens to them I would suggest socket.io, if you want a tried and tested standard, and do not need super control, try out XMPP.

Also, check this out: Chat server with websocket+node.js vs a native client with xmpp

score 1 · Answer 3 · answered Apr 02 '15 at 08:48

The benefit of XMPP is that it is standard and it offers a huge number of ready made features. Depending on the scope and ambition of your project you may have to reinvent many stuff in socket.io.

About scalability, all I can say is that we have good result with ejabberd regarding scalability. I never tried node.js / socket.io so I cannot say.

It finally end up depending on the features you need.

benetfits of ejabberd versus socket.io+redis

3 Answers3