Is Socket.IO a reliable Chat server for large number of users, if yes what's your stack? [closed]

Question

I have been reading many blogs about Socket.IO these days and impressed by features of it. I am planning to use it one of chat applications and for normal number of users with minimal number of users it is working perfectly. But are there any pitfalls in Socket.IO when used in production networks? Is Socket.IO best fit for large scale messaging system where messaging flow will be very huge. If yes, what is the best technology stack to be used along Socket.IO to make it work "100% reliable even when load is more". Anyone have already have an experience with Socket.IO in implementing large scale messaging system. Stack I want to use is Socket.IO, Redis, Cassandra and MySQL.

As of now I have gone through many examples of Socket.IO and many people were trying to do in different ways. Some people used Array to store Socket ids while some using Redis. I understand that using Redis will help definitely. But I do not want to stop there. I would like to learn best architecture for Socket.IO application.

Please suggest me a path to it.

Edit

For me best stack is nothing but, something for which rate of failure is less compared to others.

Answer 1

You first need to understand that Socket.IO is merely an abstraction, and a very elegant one at that, for the WebSocket protocol. Being that it enjoys incredible support, the protocol itself is probably the best choice you can make today when you need two-way communication between your server and your clients across public networks, so you are definitely on the right track.

The resources required to operate a Socket.IO server mainly revolve around the total amount of connections and the data being transferred across at any given point in time. With that said, a Socket.IO server is bound to network I/O and will scale to as many clients your networking hardware can handle.

Whats worth taking into account is the fact that Socket.IO is built on top of asynchronous networking libraries. Blocking I/O from other services is deferred, enabling the server to continue handling other communication. The memory footprint usually contains the in-memory representation of the connections and the immediate data being transferred--even though one client may be relaying megabytes of data to other clients, it will stream the data in discrete chunks and as soon as one chunk is transmitted successfully to all parties the resources are immediately released.

Of course, even when managing straightforward communication, like chat messages between multiple users across multiple rooms, it's impossible to be able to scale to the size of, say, Freenode, which can have hundreds of thousands of users in thousands of rooms, with just a single server.

This is where services like Redis come in to play, where you can use a highly available central storage for some intermediary, representative connection data to scale horizontally by seamlessly distributing clients across several Socket.IO instances.

You can get to 99%+ reliability today, by using stacks like CoreOS to describe each distinct parts of your architecture as units which can be distributed across available hardware, introducing new instances as the load increases, services like etcd for discovery when these come on or suddenly go dark, and distributed WebSocket proxies like hipache to keep all of your Socket.IO instances saturated, but never allowing any to exhaust all of it's available resources.