LinkedIn Moved from Rails to Node: 27 Servers Cut and Up to 20x Faster
Thursday, October 4, 2012 at 9:15AM 
Update: More background by Ikai Lan, who worked on the mobile server team at LinkedIn, says some facts were left out: the app made "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." Which explains why any non-blocking approach would be a win. And Ikai, I hope as you do that nobody reads HS and just does what somebody else does without thinking. The goal here is information that you can use to make your own decisions.
Ryan Paul has written an excellent behind-the-scenes look at LinkedIn’s mobile engineering. While the mobile part of the story--23% mobile usage; focus on simplicity, ease of use, and reliability; using a room metaphor; 30% native, 80% HTML; embedded lightweight HTTP server; single client-app connection--could help guide your mobile strategy, the backend effects of moving from Rails to Node.js may also prove interesting.
After evaluation, some of the advantages of Node.js were:
- Much better performance and lower memory overhead than other tested options, running up to 20x faster in some scenarios
- Programmers could leverage their JavaScript skills.
- Frontend and backend mobile teams could be combined into a single unit.
- Servers were cut to 3 from 30. Enough headroom remains to handle 10x current levels of resource utilization.
- Development could focus more on application development than firefighting
Clearly a lot of issues are being mixed together here. We have a rewrite, a change of stack, and a change of logic distribution between the server and the client, so there's plenty of room to argue where the gains really came from, but it's clear LinkedIn believes the use of Node.js was a big win for them. YMMV.
The comment section is, well, vigorous, but has some interesting observations. I especially liked one comment by oluseyi:
For our inevitable rearchitecting and rewrite, we want to cache content aggressively, store templates client-side (with the ability to invalidate and update them from the server) and keep all state purely client side. This means the application may request from the server all content matching a set of filters updated since a provided timestamp in order to refresh its cache; rather than opening and closing several connections, we want to open a single long-lived connection and stream all of the relevant metadata, assets and content. (Again, remember that the original implementation just rendered the returned HTML, which means that URIs for images, etc pointed to the server, and because the web views were being created and destroyed with navigation, the images were not being effectively cached.)
In the long-lived connection implementation, there are no longer "views" in the traditional MVC web application sense. The final result of server-side processing in the controller to aggregate any necessary data is not markup written to the output stream but rather a large binary blob which the client unpacks to extract all relevant data.So while I see your concern that the term MVC is being misused here, its usage is correct in a web application context-specific sense. The "view" (markup written to output, including references to external URIs that must be resolved by the rendering web view) is now an aggregated data stream, which gets unpacked, cached and then rendered client-side into the view.
Reader Comments (11)
How LinkedIn is doing scalability with nodejs? It is true that nodejs can not be scalable on multiple servers and processors? What is happening when the app has more than 1000 concurrent users?
It's cool that you guys use Node.js. I think it is a great platform. My only problem with your approach is that it off loads all the load of your application onto your customers. That is probably why you were able to drop your servers, since you aren't doing any heavy lifting on the server.
You can't guarantee a smooth user experience for everyone since each user has a different machine, OS, and browser combination. I wouldn't be surprised to see server utilization be similar to Rails or any other platform if you were actually using the same approaches.This approach also leads to confusion on both sides (development and end users).
Customer : "My experience is really slow can you help me?"
You : "It is blazing fast, what are you talking about?"
I'm interested to see a follow up to this post.
Thanks,
Khalid
Offloading some tasks to the client is a very good strategy for scaling and by no means implies that the client is going to be slow for customers. Most modern webapps do a large amount of Javascript work on the client end, some poorly, some very efficiently.
Khalid, I don't think you understand what node.js is, what this post is talking about or what the original article on ars is talking about.
mxx: he's not talking about the use of node.js, but the fact that the redesigned the mobile app to be a single page javascript app at the same time. Khalid is correct that now their server's aren't doing the page rendering.
I think its safe to assume they would have tested a range of hardware and browser combos to ensure the user experience would be acceptable. Its pretty trivial to collect performance information from a bunch of scaled down VMs running different systems to ensure you're not pushing more work onto the client than some systems can handle
All this really proved is that LinkedIn's Rail code was inefficient.
It's like to compare apples vs oranges, Node.js uses different , event based approach and probably in this case rendering was moved to a client. So no regular rails app with heavy server side rendering can match, but there are other event based Ruby frameworks out there.
This is embarrassing to read. They spend time migrating from Rails to Node but can't spend the time to get security right and to do something trivially like salt passwords? Bad priorities and bad technical leadership.
I really would like to know if there were any protocol changes in between client-server or if LinkedIn stuck with just the old fashioned http request-response? There are a lot of gains to be made with webSocket, especially on mobile, by transferring only the data required and not constantly updating html fragments. It would also seem there would be significant gains made with having a full duplex connection between client and server to fully honor the non-blocking execution inside Node.JS.
Why LinkedIn chose not to use WS with an appropriate protocol straight into the native code is a bit of a mystery to me. Why embed a web server in the native code to do REST in between JS and native components? Seems like a lot of work just to stick with the old html fragment approach to building applications.
Sure Linked In moved to Node.js - but that because linked in is not much of a website. All you do on it is read resumes and apply for jobs. If GitHub moved to Node.js - that would get peoples attention.
To my experience, you get live faster with Rails and if minimum memory isn't the issue then best way to go with much mature technology like Rails. I wouldn't agree to go node.js because of performance. Non blocking things can be achieved with background jobs.