-
I am usually skeptical of articles on node.js, because I feel like there is so much hype around it, and it is usually not substantively better. However, switching from 30 servers to 3 is pretty impressive. What I am wondering is how they can maintain so many long-lived connections simultaneously, where every view change there’s some sort of database/cache call (ie blocking). Do they just not have that many simultaneous connections? Is there something about node that makes it really ideal for this? Do they have other machines that sit behind the 3 servers that do other logic? Obviously the data sits on other machines, are there also other machines for mediating which data nodes they hit? What exactly are the responsibilities of these three servers? Do they send HTML over the wire, or just raw data that the client plugs into templates?
-
-
I guess if they are long-lived so it doesn’t really matter, but for shorter lived calls, it does matter, because each database call means they are keeping a file descriptor and process open longer. At linkedin levels of volume, that matters. We know that asynchronous doesn’t mean that the process disappears, it just gets sent to the background until the data it’s waiting for is back.
-
-
Read Ikai’s article. The original Rails stack was routinely communicating between data centers. This would negatively impact performance for a node stack too. But it would hurt the scalability a synchronous server stack far more. Node/any asynchronous code can do as it pleases between slow requests. Rails/any synchronous server has to sit patiently and wait for a response.
A better network architecture would have served them well too and perhaps obviated some of the desire for a rewrite.
-
-
-
Nice. Looks like compile-buffer on Emacs. ;)
-
-
I’ve been using it for a few months now (and submittef a patch).
For the most part, it’s wonderful. Where it falls down just a little is where it’s limited by tmux. For instance, while you can search in the terminal from vim, tmux does not highlight the found text because vim is the selected window and not the terminal.
A big plus: it’s written using VIM Ruby hooks. And Ben Mills, the author, wrote a nice API of primitive functions for communicating with tmux.
If you use vim, use it. It will let you envy the emacs users a bit less.
-
| In IRC-land, Red only has so much patience to help Yellow in their quest for learning.
This speaks to me of a problem with some IRC users more than a problem with Red and Yellow.
Do you know Yellow people personally? What are their goals in learning Ruby or Rails or insert-technology-du-jour? Are they trying to get a programming job? Are they just dabbling in their spare time?
Context, here, seems key. For lack of context, I would leave Yellow well enough alone and/or help as I can.
It’s an “Excalibur test” as mentioned in The Last Starfighter. I am amused by this.