On Tue, May 8, 2012 at 11:26 PM, Ed Summers <[log in to unmask]> wrote:
> For both these apps the socket.io library for NodeJS provided a really
> nice abstraction for streaming data from the server to the client
> using a variety of mechanisms: web sockets, flash socket, long
> polling, JSONP polling, etc. NodeJS' event driven programming model
> made it easy to listen to the Twitter stream, or the ~30 IRC channels,
> while simultaneously holding open socket connections to browsers to
> push updates to--all from within one process. Doing this sort of thing
> in a more typical web application stack like Apache or Tomcat can get
> very expensive where each client connection is a new thread or
> process--which can lead to lots of memory being used.
We've also been using socket.io for our cloudbrowser project, with great
success. The only drawback is that websockets don't (yet) support
compression, but that's not node.js fault. Another fault: you can't easily
migrate open socket.io connections across processes (yet). FWIW, since you
mention Rackspace - the lead student on the the cloudbrowser project has
now accepted a job at Rackspace (having turned down M$), in part because he
finds their technology/environment more exciting.
I need to dampen the enthusiasm about memory use a bit. It's true that
you're saving memory for additional threads etc., but - depending on your
application - you're also paying for that because V8 still lacks some
opportunities for sharing other environments have. For instance, if you run
25 Apache instances with say mod_whatever, they'll all share the code via
shared .so file. In Java/Tomcat, the JVM exploits, under the hood, similar
V8/node.js, as of now, does not. This means if you need to load libraries
such as jQuery n times, you're paying a substantial price (we found on the
order of 1-2MB per instance), because V8 will not do any code sharing under
the hood. That said, whether you need to load it multiple times depends on
your application - but that's another subtle and error prone issue.
> familiar, because of the extensive use of callbacks. This can take
> some getting used to, but it can be a real win in some cases,
> especially in applications that are more I/O bound than CPU bound.
> Ryan Dahl (the creator of NodeJS) gave a presentation  to a PHP
> group last year which does a really nice job of describing how NodeJS
> is different, and why it might be useful for you. If you are new to
> event driven programming I wouldn't underestimate how much time you
> might spend feeling like you are turning our brain inside out.
The complications arising from event-based programming are an extensively
written-about topic of research; one available approach is the use of
compilers that provide a linear syntax for asynchronous calls. The TAME
system, which originally arose from research at MIT, is one such example.
http://tamejs.org/ Though I haven't tried it myself, I'm eager to and
would also like to know if someone else has. The tamejs.org provides
excellent reading for why/how you'd want to do this.