I'm dealing with a situation here on a high volume multi-tenant web app with over 100k users from companies who do not appreciate performance issues. We have a need for "real-time" updates.. we're basically sending out a request to a 3rd party system, and we'd like to see the results real-time, there's about 5 statuses returned, and the first three statuses happen very quickly (within a minute or so)..
Our current implementation is to have a refresh cycle which happens every five minutes.. (partial page postback with Jquery), the user can override this by clicking on a refresh button..
The reason we went with this approach is because of the potential server load with "long-polling", or frequent post backs (every 2 seconds), and the burdon it would put on our server (we have a few Databases and Webservers, so maintaining a changelog is out of the question) at the time we hadnt looked into node.js / socket.io, which brings me to my question:
if socket.io only works on modern browsers and has to revert to either Flash or Long-polling if the required functionality is not available in the browser, is there really any benefit to using this technology today (as opposed to 2 years from now when the last of the i.e 6 users are forced to update)? the problem is we dont want to bring the server to it's knees because worst case this thing is going to keep the http connections open for an extended duration and really mess up our users experience (our apps on the webserver, i did not design the system)
Best Answer
Use socket.io and configure it to do polling over a 5 minute interval as the websocket fallback.
Seriously websockets are awesome, use them if possible and fallback to something that has an acceptable server load.
If this brings your web server to it's knees then your web server is a crap one. Get one that can handle open sockets and scale.