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)

  • Do you have stats on what's hitting this site now? How many browsers urrently visit the page that support socket.io and how many don't? Jan 24, 2012 at 19:17
  • i dont have any stats.. all (broad generalization) browsers will support socket.io to some extent because it supports backwards compatibility (long-polling at worst case). the issue is going to be server performance not necessarily client support
    – hanzolo
    Jan 24, 2012 at 19:19
  • Ah, I didn't know that. Jan 24, 2012 at 19:23

3 Answers 3


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.

because worst case this thing is going to keep the http connections open for an extended duration

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.

  • i like that idea. scaling it back to do what we're currently doing is a fantastic proposal.. thanks.. as far as"web server is a crap one", be careful not to draw assumptions not knowing the application at hand.. 10000 users posting every 3 seconds is quite a lot of posts per minute, and since our application is built on a framework that has a large audit trail requirements, a post is going to be extremely more expensive than a read only site.
    – hanzolo
    Jan 24, 2012 at 21:06
  • @hanzolo I'm implying that open sockets bring one thread per socket web servers down. Use a web server that uses a proper thread pool or uses an event loop
    – Raynos
    Jan 24, 2012 at 21:44
  • @hanzolo That is a lot of concurrency and storage you must need. It sounds like an intriguing project to be working on. Call me a masochist but I love performance tuning :)
    – maple_shaft
    Jan 25, 2012 at 2:24

So you have a web application with over 100k users and you do not already have performance stats? Shame shame.

The issue with polling overloading your web servers is likely not going to be fixed with a single solution. A Flash object will still need to communicate with a server somewhere but even with this approach you cannot be verified that all users have Flash installed. I don't have Flash on my workstation, and iPad users will likely not be able to correctly use your site (if that is even an issue). You are guaranteed that in a few years IE6 will virtually disappear but there will always be browser clients who do not accept Flash.

HTTP communication for polling is expensive but you may want to check the User Agent and use that information to decide which polling method you can use. TCP/IP socket communication has slightly less overhead and is preferable.

  • well, the stats are actually available.. just not to me easily, lol!! at least they're far enough away that it's a last resort.. Also, socket.io actually handles the correct polling method, the problem is that it defaults down to the worst possible scenario.. and actually as i type, i realize that i can do some impact assumptions based on user browsers, but i hate making assumptions... thanks for your answer
    – hanzolo
    Jan 24, 2012 at 21:04

Where all this fanboyism is comming from? "Crappy servers" because not "thread pool", "event loop", "scale"... at least I haven't seen any rant about external plugins yet, so only 8/10 trolling :)

Well i guess that alpha-websocket browsers and alpha-version event loop servers are not "crappy" :)

Just slogans not a real solution. Have all those "fashionable" devs even used some of those new technologies with cool names on anything beside localhost? :)

As for my solution: use nginx, lighty, etc. (eg. in reverse proxy mode or even normal with scripting as fcgi), assign each "task" an unique id, then check the server every 5 seconds (ajax) for a presence of static file that you'll create from your script in some predefined dir. When the file will be present you can run a script that'll get you results via ajax. Simple, and won't overload the server because you'll be checking for static file, doesn't do fallback in 50% of the browsers on market, translation for fanboys is "always works as it should".

Beside event loop webserver won't work if you won't have event loop scripting backend.

Then in 5 years when websockets status will change from fashionable to production ready you can use this without compromising usability. And of course new kids will rant because you won't use those "quantum", "cloudum", etc. servers and specs that doesn't work :)

I mean really guys? Are you serious? WebSockets is available in IE10 Preview and you want to write serious app using this TODAY when around 50% of your userbase will be IE? I know it's cool play toy and it'll work good in your Chrome, but you're not going to be the only user for something you write at work.

  • @Slawek- when i propose node, that's exactly the response i'm expecting. However, we need real-time updates in some instances in the app, and the problem at hand with a "changelog" type structure is managing all the different DB instances and ensuring the data is consistent.. my proposal was for a service layer responsible for maintaining the "changelog"'s integrety... the platform guys did not appreciate that i wanted to go around their system, so we'll see where it ends up.. Thanks for the insight!
    – hanzolo
    Jan 25, 2012 at 17:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.