I'm looking into real-time web applications using websockets and node.js. I'm interested to see what are some technical challenges with scaling such a setup.

One such problem I've heard is that each socket requires a Unix file descriptor, and epoll/select takes time linear to the number of open file descriptors.

Anyone have other insights into scaling?

  • 2
    Do you really mean 'real-time' or just fast. Real-time has a special meaning in computer science and programming. Mar 6, 2011 at 16:02
  • I mean real-time as it is used here: en.wikipedia.org/wiki/Real-time_web , not as in real-time programming Mar 6, 2011 at 18:43
  • To comment on the epoll statement - We have a custom epoll server written in C, and we can saturate a gigabit connection in performance tests against 1kb server-response sizes... That's a lot of simultaneous requests (probably near the maximum allowed per process). You can do a ulimit -aH to see how many FD's are allowed per process.
    – Ben DeMott
    Mar 9, 2011 at 20:56

1 Answer 1


First things first:

There are two approaches to all http servers, thread/process or asynchronous and persistent.

Twitter is an example of what to avoid in my opinion - fail whale and all. Although they are getting better now it seems - the front-end is still not persistent... you can read about its evolution here: http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster

The first thing you are going to need to acknowledge is you aren't going to be able to accomplish scalable real-time anything without TRUE persistence. As in a main-loop or event-loop. If you have any sizable amount of code at all, PHP, Perl, etc - must re-execute and reload all of their data, variables, etc every request - although fine for displaying your Wordpress blog, this is not going to work in the type of application you are describing.

If you have enough servers and enough money you can use apache2/httpd to serve all of the content in real time you want. But if you are like the rest of us the asynchronous approach is probably going to work best for you.

Existing Technologies:

Tornado - Facebook adopted the Tornado web-server to handle event notifications/feed updates. (I'm not advocating it, just giving you an example of how to handle the real-time solution.


If you want to write the kind of http servers that amazon.com is engineering then you might look at: libevent http://monkey.org/~provos/libevent/


If you have a little less time on your hands, I would suggest Python's twisted framework. We use Twisted at my work for a great many things.

http://justin.tv runs on Twisted - that's about as realtime web as it gets.

See here: http://twistedmatrix.com/trac/wiki/SuccessStories

  • Problems: 1. "Twitter (...) still haven't adopted an event-loop" - The Twitter article you cite explicitly says they moved to asynch processing. 2. "you aren't going (...) accomplish scalable real-time (...) without TRUE persistance" - Even aging tech like FastCGI doesn't reload per request. Event-based processing is more about not blocking then avoiding app state reload. 3. "Facebook adopted the Tornado web-server" - Facebook chat is based on ejabberd which is written in Erlang. Are you thinking of FriendFeed? 4. The OP asked how to scale node. Not sure what you're going for here. Mar 8, 2011 at 23:26
  • I guess with Twitter I was referring to the front end - which is still Ruby, whether you use a JVM or not - the state still reloads - local scope, local variables. As for FastCGI it depends... for PHP FastCGI simply keeps the state of the container application alive, the actual logic / state is re-executed each time (the interpreter is simply reset) I would know I embedded PHP as a Python extension and we based our embed and reset on the FastCGI implementation... -> github.com/bendemott/pyhp
    – Ben DeMott
    Mar 9, 2011 at 20:40
  • Comet/Long Poll / and State-Persistent servers are suited for real-time web apps is my point.
    – Ben DeMott
    Mar 9, 2011 at 20:46

Your Answer

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

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