Is there a server cost to using WebSockets?

I've been moving away from my comfort zone in PHP/MySQL because the syntax/encapsulation/procedural stuff can get frustrating.

Last week, I started played around and followed some tutorials to use Node.js/Socket.IO to create a live chat application. Up until this point, I've never done anything with WebSockets, and they seem really cool -- instant communication between server and client is awesome.

Now, forgive my lack of understanding here, but HTTP is set up so that you aren't supposed to be able to keep connections open between client and server -- and my rudimentary understanding of Comet is that it forces the connection to remain open by never terminating the write stream and just sending NUL bytes. This sounds... server-intensive.

How do WebSockets work, then? If I had a couple hundred people on my chat app at once, wouldn't the server be overloaded? When I use PHP/MySQL on a server, the server only processes one request at a time -- and if I were to use AJAX and poll, say, every one second, I imagine that it would escalate quickly as you'd have thousands of requests a minute.

My question is, do WebSockets scale for large applications? Is it practical without having a really high-bandwidth server?

I guess it comes down to: is there a significant server load/user experience difference between AJAX polling at a frequent interval, Comet, and WebSockets?

Thanks!

Solution 1:

There are lots of good overview sites to read about how websockets generally work like here and here.

In a nutshell, they initiate a connection with a certain type of HTTP request and then after that, they are a direct TCP bi-directional connection between client and server.

There is some server overhead to maintain an open socket to a client so if you were anticipating tens of thousands of these at once, you would have to make sure your server infrastructure was capable of that scale. The CPU load would only be proportional to how many sockets were busy at any given time as an idle socket doesn't take any CPU.

Is there a server cost to using WebSockets?

It really depends upon what you're comparing it to. webSockets are typically used when the server needs to be able to send data to a client when the data comes available (often called "server push"). The usual alternative to using a continuously connected webSocket is to have the client polling repeatedly, asking the server over and over if the server has anything new. If you compare a webSocket to repeated client polling, then the webSocket is generally way, way more efficient and you could scale your server a lot higher using webSockets than with frequently polling clients.

Servers can be properly configured to support hundreds of thousands of simultaneous (and mostly idle) webSocket connections such that the server scalability limit is limited by how much traffic you're sending to all these connected clients. If you're sending data to a client every few seconds and you have hundreds of thousands of connected clients, then that will take a lot of server horsepower (and bandwidth) to do that with any technology and webSockets would still likely be better than any competing technology. But, if webSocket connected clients are mostly just idle and data is just occasionally sent to them, then a webSocket implementation can scale hugely and efficiently.

Here are some other references on the topic:

Websockets and scalability

websocket vs rest API for real time data?

Websocket vs REST when sending data to server

Ajax vs Socket.io

Why to use websocket and what is the advantage of using it?

HTML5 WebSocket: A Quantum Leap in Scalability for the Web

Push notification | is websocket mandatory?

The Comet library attempts to support a WebSocket-like interface, even when there is no direct WebSocket support. This is where the somewhat inefficient hacks start showing up as it tries to simulate a bi-directional TCP socket by keeping an open HTTP connection. If you are using real WebSockets, this is not an issue.

Solution 2:

Considering bandwidth, websockets should be better or at least not considerably worse than all the workarounds with Comet or AJAX long-polling. The websocket protocol allows you to only send data when you need to and only applies minimal padding (8 - 14 byte, plus the obligatory TCP and IP framing) to each message you send.

It is correct that every active client will have an individual connection open. So when you have a lot (many thousands) of simultaneous clients, you might hit a connection limit of your webserver, framework or operating system, but these limits are usually configurable.

Solution 3:

A good place to start learning about WebSockets and how it works is here. WebSocket connections "never" terminate except in case of unexpected network issues or the client or server explicitly decides to end the connection.

Node.js can handle a lot of open connections (provided your OS open file descriptor settings are high enough), so usually a single system/thread can get you pretty far. However if you need to scale beyond one thread, you could always use the 'cluster' module and/or load balance between multiple systems if one system is not enough.

If anything, overhead can be less with WebSockets since you are not creating and tearing down connections as is the case with long polling or similar solutions.