Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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)

share|improve this question
    
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? –  FrustratedWithFormsDesigner Jan 24 '12 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 '12 at 19:19
    
Ah, I didn't know that. –  FrustratedWithFormsDesigner Jan 24 '12 at 19:23
add comment

3 Answers

up vote 2 down vote accepted

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.

share|improve this answer
    
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 '12 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 '12 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 '12 at 2:24
add comment

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.

share|improve this answer
    
@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 '12 at 17:29
add comment

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.

share|improve this answer
    
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 '12 at 21:04
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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