You question raises the possibility of three different techniques:
- Websockets (Faye, Iodine, EM-Websockets or whatever websocket solution you prefer).
- Short-polling (client based 'pull' style notifications).
- Long-polling (client and server attempt at a persistent connection - pre websockets technology).
Although Websockets seem to be the most scalable and natural solution for push notifications, it is - as most things are - an application specific question. You will need to consider your resources and your demands and balance them the best way you can.
Websockets vs. Short-polling each carry a "price". While Short-Polling is easier to implement, Websockets allow for real "push" and their design is meant to conserve web and server resources.
As for Websockets vs. Long polling, the answer is quite simple - Websockets will be more efficient.
Long polling emulates a persistent connection by blocking the HTTP request sent by the browser until the server has data to "answer" with. This could block the whole server if it's concurrency isn't effective and it would obviously block the thread in charge of answering the request (how many threads are in your server's thread pool? 8? 24?).
In contrast, Websockets ARE persistent connections which don't block, but integrate with the server. It's a much more elegant and resource friendly solution.
You can find more information about long polling vs. short polling here:
In example:
Let's assume you expect 5,000 active clients connected to your website any given moment (if each client spends 30 minutes a day connected, this assumes ~ 240K clients in total, disregarding peaks and ebbs is usage times).
Now, let us compare resources just for the push/update part of the application:
Short Polling: If each client sends an update query every 2 seconds (not fast, but not too slow, depending what you need), you need to handle 2,500 requests/second only to answer the update query requests. Each request will impact the memory, performance and responsiveness of your app.
Long Polling: You will have 5000 connections blocked and waiting for a response. That's 5,000 tasks which probably use up a thread each... even if you manage to cycle the tasks using some async-response and a thread pool (which is super difficult with Rack servers), you will be eating up CPU and memory waiting for updates. Also, each update will require you to renew the 5,000 connections (or, if you're lucky, HTTP/1.1's keep-alive feature will save you from this inconvenience). These blocked connections will effect the responsiveness and performance of your app, using CPU cycles and taking focus from real requests. It might (or might not) be better than attempting to answer 2,500 requests per second... but not very effective. Pushing data is immediate.
Websockets: You will have 5,000 connections added to the server's IO reactor. The websocket callbacks will be called whenever there is any activity (which might never happen) and none of your threads are blocked. Updates sent using websocket connections don't cause the connections to close, so there is no need to renew the connections with every update. Pushing data is immediate.
to conclude:
By design, if you have your own server, you should be able to serve many more clients using Websockets than using Short or Long polling.
However:
Websockets (as well as long-polling) are harder to code than short-polling (they use a very valuable resource which is human coding hours);
some hosting services (i.e. Heroku) will limit the websocket clients count, making the "math" less certain... on the other hand, concurrency limits (req/sec) for these same services would probably end up in favor of websockets.
