I flagged this as spam, in the sense that this is blog spam that adds nothing to the original article. Please let me know if I was incorrect in doing this.
I find these links more helpful:
I am not sure why folks are saying that the claims are bullshit.
The dude who wrote the second post you lined to left LinkedIn in 2009. He was on the team that built the rails system that was replaced with node long after he left. Choice quote from his blog post: “I don’t think there is any question that v8 is freakin’ fast. If node.js blocked on I/O, however, this fact would have been almost completely irrelevant.”
That said, I agree with you that the post was blogspam, and thanks for posting those links!
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?
Node.js is asynchronous. This means it doesn’t block on database calls so it can stack up hundreds of requests waiting for data.
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.
I saw Ikai’s article after posting my reply. You’re right, it answered most of my questions.