LinkedIn replaced their back-end mobile infrastructure built on Ruby on Rails with Node.js some time ago for performance and scalability reasons. A former LinkedIn team member reacted explaining what went wrong, in his opinion.
Kiran Prasad, Director of Mobile Engineering at LinkedIn, told ArsTechnica they had to reconsider their back-end infrastructure providing mobile services for LinkedIn clients because although only 7-8% of the clients were using their mobile application, the Ruby on Rails back-end suffered from severe scalability problems.
LinkedIn evaluated three possible solutions: Rails/Event Machine, Python/Twisted, and Node.js. According to Prasad, Node.js was eventually chosen providing a number of benefits:
- Better performance, Node.js being up to 20x faster than Rails for certain scenarios
- Using only 3 servers instead of 30, leaving room for a 10x traffic growth
- Front-end JavaScript engineers could be used for back-end code, and the two teams were actually merged into one
LinkedIn’s story of dumping Rails due to scalability reasons triggered some reactions around the web. Ikai Lan, a former member of the mobile team at LinkedIn, shared his part of the story on the technology chosen and the problems encountered:
The stack we chose was Ruby on Rails 1.2, and the deployment technology was Mongrel. Remember, this is 2008. Mongrel was cutting edge Ruby technology. Phusion Passenger wasn’t released yet (more on this later), and Mongrel was light-years ahead of FastCGI. The problem with Mongrel? It’s single-threaded. It was deemed that the cost of shipping fast was more important than CPU efficiency, a choice I agreed with. … We deployed using Capistrano, and were the first ones to use nginx. …
[Later] we upgraded to Rails 2.x+ … Oh, and we also decided to use OAuth for authenticating the iPhone client. Three legged OAuth, so we also turned those Rails servers into OAuth providers. Why did we use 3-legged OAuth? Simple: we had no idea what we were doing. I’LL ADMIT IT.
The servers designated for mobile services were hosted by Joyent, so when a mobile application needed some information the request had to travel to Joyent then make another trip to LinkedIn’s datacenter where the main API service was located, according to Lan:
That’s a cross data center request, guys. Running on single-threaded Rails servers (every request blocked the entire process), running Mongrel, leaking memory like a sieve (this was mostly the fault of gettext). The Rails server did some stuff, like translations, and transformation of XML to JSON, and we tested out some new mobile-only features on it, but beyond that it didn’t do a lot. It was a little more than a proxy. A proxy with a maximum concurrency factor dependent on how many single-threaded Mongrel servers we were running. The Mongrel(s), we affectionately referred to them, often bloated up to 300mb of RAM each, so we couldn’t run many of them.
After pinpointing some of the problems, Lan eventually admitted that “v8 is freaking fast” but added: “Don’t assume that you must build your next technology using node.js. It was definitely a better fit than Ruby on Rails for what the mobile server ended up doing, but it is not a performance panacea. You’re comparing a lower level server to a full stack web framework.”
Hacker News has a long thread of reactions to this decision of using Node.js over Rails.
Community comments
Why not Java or C#?
by Jonathan Allen,
Re: Why not Java or C#?
by Siva Katir,
Re: Why not Java or C#?
by Jonathan Allen,
Re: Why not Java or C#?
by Maniek Barniek,
Re: Why not Java or C#?
by Erik Reppen,
Re: Why not Java or C#?
by Deivid Bitti,
Re: Why not Java or C#?
by Michael Campbell,
This is archeology
by Matias B,
Remember 10 years ago when Java was the slowest language?
by Sergio Rafael Gianazza,
Re: Remember 10 years ago when Java was the slowest language?
by Marc Stock,
Valuable Reasons people prefer Node.js and Ruby on Rails
by Kathreen Riya,
Why not Java or C#?
by Jonathan Allen,
Your message is awaiting moderation. Thank you for participating in the discussion.
If performance was a concern, why didn't they settle a compiled language like C++, Java, or C#?
Did they try it and find that it was still too slow?
Or did they not even consider it, perhaps because they were under the misconception that statically compiled languages are necessarily slower to develop in?
Re: Why not Java or C#?
by Siva Katir,
Your message is awaiting moderation. Thank you for participating in the discussion.
Performance? PERFORMANCE!? How dare you! Those aren't "sexy" languages! How are we supposed to be cutting edge and sexy when we use C++?
In all seriousness though I was wondering the same thing. Every time I see a Rails job I wonder how long that company will be around :(
Re: Why not Java or C#?
by Jonathan Allen,
Your message is awaiting moderation. Thank you for participating in the discussion.
To be fair, one of the hallmarks of web programming is that you can just keep throwing more hardware at the problem. You don’t need great performance, you just need to reach barely adequate and stick it behind a load balancer.
But I’ll still deride platforms like Ruby on Rails and Node.js for maintainability. The 5 seconds you save by not creating property Foo isn’t balanced by the 20 minutes you spend making sure that no one else is already using Foo for something else.
Re: Why not Java or C#?
by Deivid Bitti,
Your message is awaiting moderation. Thank you for participating in the discussion.
They could use JRuby, www.jruby.org/
Re: Why not Java or C#?
by Maniek Barniek,
Your message is awaiting moderation. Thank you for participating in the discussion.
Jonathan how about TypeScript :)? You have JavaScript + maintainability.
Re: Why not Java or C#?
by Michael Campbell,
Your message is awaiting moderation. Thank you for participating in the discussion.
> If performance was a concern, why didn't they settle a compiled language like C++, Java, or C#?
Not to belittle your very appropriate question, but I was around when java was brand spanking new, and the biggest/loudest threads on all the mailing lists then was, "JAVA ISN'T COMPILED, IT CAN'T BE FAST ENOUGH!"
It's just amusing to me to see these sorts of discussions putting java in the "fast" side of the fence; how times have changed.
This is archeology
by Matias B,
Your message is awaiting moderation. Thank you for participating in the discussion.
First, they compare Node.js, a platform, vs Rails, a web framework. Second, they talk about Mongrel. How is using Mongrel now day? No one, Mongrel sucks!
If you're going to write something about Rails and the great alternatives, do something serious, not this throw a bone so the dogs will start a flame war.
Remember 10 years ago when Java was the slowest language?
by Sergio Rafael Gianazza,
Your message is awaiting moderation. Thank you for participating in the discussion.
Github is an example of a website with lots of users using Ruby and Rails in the backend.
I don't know why still are people who thinks that the only way to achieve good performance is with either Java or C#. 10 Years Ago Java was the Slowest language ever created and now seems that Java is the only way to respond to thousands of request?
Re: Remember 10 years ago when Java was the slowest language?
by Marc Stock,
Your message is awaiting moderation. Thank you for participating in the discussion.
I'm pretty sure that the 2002 version of Java would still be faster than Ruby is today. I'm not slamming Ruby because I really don't care about it one way or the other.
Re: Why not Java or C#?
by Erik Reppen,
Your message is awaiting moderation. Thank you for participating in the discussion.
Why would I need to do that when foo is a persistent var living inside an instance and can't be touched from the outside. Not even by a getter/setter because that would be stupid and missing the point.
Valuable Reasons people prefer Node.js and Ruby on Rails
by Kathreen Riya,
Your message is awaiting moderation. Thank you for participating in the discussion.
Good comparison. You may be a great author. Also, I would like to share some valuable comparison points and Which framework to choose for web development activities. www.agriya.com/blog/2017/07/07/node-js-vs-ruby-...