 |
 |
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