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
sharing opportunities.

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.


> If you've done any JavaScript programming in the browser, it will seem
> 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 [4] 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.
Originally for C++, there's now a version for JavaScript available:
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.

 - Godmar