
LinkedIn Mobile Moved from Rails to Node: 27 Servers Cut and Up to 20x Faster - turar
http://highscalability.com/blog/2012/10/4/linkedin-moved-from-rails-to-node-27-servers-cut-and-up-to-2.html
======
SoftwareMaven
If you are thinking about using node.js for this reason[1] on most sites, you
are optimizing poorly. LinkedIn didn't worry about this until _after_ they
were a public company.

If Python/Djando or Ruby/Rails can get your app out the door and into customer
hands faster, it is almost always the right thing to use.

1\. There are certainly other, very valid, technical reasons for choosing
node.js over other technologies early. But let those reasons be about the
problems you are solving _today_ , not the ones you might need to worry about
when you have 50 servers to deal with.

~~~
Smudge
I'm sure LinkedIn could have cut servers _without_ switching to node. Take
your first, crappy implementation and rewrite it in the _same_ language and
you'll probably still see at least 10x improvement, if not 20.

~~~
pdelgallego
>> Take your first, crappy implementation and rewrite it in the same language
and you'll probably still see at least 10x improvement.

You will probably will get the same mess. There is plenty of literature about
that. I.e: A complete rewrite is what killed Netscape

~~~
zorked
As bad as Netscape 4 was, what killed the company was their decision to charge
for the browser while their monopolitic competidor was giving it away for
free.

~~~
tedunangst
When a competitor undercuts your pricing with free, not doing anything for
three years is unlikely to be the optimal response...

------
justinjlynn
It sounds like they went through a major rewrite of their backend and ended up
architecting things to be much more performant than their previous system. I'm
curious to find out what parts of the system they think contributed most to
the performance increase. While this is interesting it is by no means an
apples to apples comparison of Node and Rails as the headline suggests.

~~~
gnufied
From original article[1] (Not the highscalability link spam):

>This led them to a model where the application is essentially piping all of
its data through a single connection that is held open for as long as it is
needed.

So it sounds like from using a request/response driven architecture, they
adopted streaming architecture. Also, they moved away from Rails and adopted
an Event driven approach.

It is well known fact that, it is almost impossible to stream stuff with Rails
currently and hence adopting a event driven approach made sense. I can see,
how just these two factors alone will contribute hugely to performance.

[1]: [http://arstechnica.com/information-
technology/2012/10/a-behi...](http://arstechnica.com/information-
technology/2012/10/a-behind-the-scenes-look-at-linkedins-mobile-
engineering/2/)

~~~
rhizome
Sure, but is it unreasonable to wonder why they need such an architecture?
LinkedIn is basically a CRUD app, and while they have a wall now and yadda
yadda, I wonder how much of this rearch was really necessary, over simple
refactorings and sysadmin attention to the nuts and bolts.

~~~
gnufied
Ability to stream stuff from an Event driven reactor loop makes lot of sense
when it comes to raw performance actually.

If you throw in Postgres database in mix which supports asynchronous queries -
one can pretty much beat 20 passenger instances serving similar request. The
problem again though is, doing non-blocking IO does not reduce database load.
So, if likely they re-architected that bit as well.

~~~
rhizome
What is the sense that it makes?

------
gnufied
The title is misleading. From original article[1]:

> They found that Node.js, which is based on Google’s V8 JavaScript engine,
> offered substantially better performance and lower memory overhead than the
> other options being considered. Prasad said that Node.js “blew away” the
> performance of the alternatives, running as much as 20 times faster in some
> scenarios.

So according to original article, Node.js did not perform 20 times better
compared to existing Rails based backend. According to Prasad, it performed 20
times better than alternatives of Node such as - Eventmachine & Python Twisted
(they did evaluate both of them).

Now I am having hard time believing node.js can outperform Eventmachine or
Twisted by 20 times. Most benchmarks I have seen and done tell me, node is
marginally ahead. I would obviously like to see, what they benchmarked and
how?

1: [http://arstechnica.com/information-
technology/2012/10/a-behi...](http://arstechnica.com/information-
technology/2012/10/a-behind-the-scenes-look-at-linkedins-mobile-
engineering/2/)

~~~
pepve
I think they created a specific benchmark for their use case. Maybe they even
implemented part of their requirements on both stacks.

------
ikailan
I was on the team at LinkedIn when we first wrote the thing on Ruby on Rails.
Here's my writeup containing some more context:

[http://ikaisays.com/2012/10/04/clearing-up-some-things-
about...](http://ikaisays.com/2012/10/04/clearing-up-some-things-about-
linkedin-mobiles-move-from-rails-to-node-js/)

While I'll freely admit v8 is much faster than MRI Ruby, the efficiency gains
are likely more related to 1) the rewrite factor 2) moving to non-blocking 3)
the fact that the original server ... um, needed love

------
dpcx
I personally find it hard to believe that all of LinkedIn was only running on
30 servers, and is now running on only 3.

EDIT: Mobile only. Maybe the title should be updated to reflect that.

~~~
masklinn
> I personally find it hard to believe that all of LinkedIn was only running
> on 30 servers, and is now running on only 3.

I can believe it, if their caching strategy was garbage before and part of a
massive rewrite was rethinking that. If you fail to use your caches, you'll
pay for it.

I mean it's not like LinkedIn is about split-second changes, you could
probably statically generate most of it and serve it with a single nginx
instance.

~~~
ikailan
Actually, we aggressively cached, which led to weird things happening. I
posted a follow up about this explaining more context - I hope it gets voted
up.

------
lsh123
The performance improvements have probably NOTHING to do with node.js but with
the re-architecture goals set by the team:

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

Better understanding of the problem and experience running the system were
probably key for building the new high-performance architecture. Obviously,
old one lacked these big advantages.

------
wardb
Reading this like: "Hey, our previous backend was a total turd, technically
speaking." It might be trivial to speed up your own crappy first
implementation 20x with some extra TLC.

~~~
rhizome
Like a lot of contemporary online companies, they might be skimping on
sysadmins.

------
rapind
I looked into Node.js, Sinatra, and Go to handle API traffic for a mobile app
a few months ago and did a lot of benchmarking. What I found during my tests,
was that Go > (Node.js = Sinatra).

If I had wanted to add Rails to this comparison I would have compared apples
to apples and used Metal instead of including the entire stack.

------
jemfinch
When you make a software change that allows you to reduce your server pool
from 30 to 3, you don't say, "27 servers cut". You say "Servers reduced by
90%." I have no idea what "27 servers" actually means: you could have been
using a thousand servers for all I know.

------
pragmatic
The original article:

[http://arstechnica.com/information-
technology/2012/10/a-behi...](http://arstechnica.com/information-
technology/2012/10/a-behind-the-scenes-look-at-linkedins-mobile-
engineering/2/)

And this is really intersting:

Finally LinkedIn tested, and ultimately chose to adopt, something surprising.
The company embedded an extremely lightweight HTTP server in the application
itself. The HTTP server exposes native functionality through a very simple
REST API that can be consumed in the embedded HTML controls through standard
JavaScript HTTP requests. Among other things, this server also provides access
to the user’s contacts, calendar, and other underlying platform functionality.

------
skyebook
It's a nice stat to see but I think this sort of comparison with "we moved our
infrastructure of undisclosed age and unknown bloat to this new infrastructure
built for the current problem domain" doesn't really do much for the ongoing
conversation.

The article is touted as praise for a stack but my gut says that its really a
smart restructuring of how they serve mobile. Either way, good on them for the
efficiency boost.

------
shn
What this article talks about is more than a year old. When I was looking for
a tool to start my project I was at the same distance to Python, Ruby and
NodeJS and their ecosystem. So when I read about it a year ago I leaned
towards NodeJS. So knowing the experience of others always help to certain
people at certain point of their yet to unfold story but not to everybody all
the time.

I am not unhappy with my choice but I do not have enough data to compare with
other tools. I do not think a lot of people have either. Once you start with a
tool you tend to keep it since you invested a lot of time learning it as well
as developing something with it. I think few can afford switching tools (e.g.
FB switched from HTML5 to native recently for their mobile interface).

------
trekkin
It's almost impossible to reach 1000 req/sec in Ruby/Rails. It's relatively
easy to reach 50000 req/sec in C++. Assuming V8 is about 3x slower than C++,
it is not surprising that a move Ruby/Rails->node.js gets 10x throughput
improvement.

------
SanjayUttam
"Programmers could leverage their JavaScript skills."

I'm confused by that being an advantage - I guess that's better than using
some language you don't know at all, but it's still a bit of a different
approach to JS, no?

------
scott_meade
"simplicity is at the heart of LinkedIn’s mobile vision." Then the article
goes on to describe complexities of the implementation. Maybe my old and
cranky mind has lost touch with what people mean by "simple".

------
fomojola
Ah, odd math point, but was I the only one who noticed this sentence:

"focus on simplicity, ease of use, and reliability; using a room metaphor; 30%
native, 80% HTML; embedded lightweight HTTP server; "

~~~
pragmatic
It's mangled from the original article.

------
chmike
What would they gain if they moved from node to nginx and a c++ with asio
backend (e.g. <http://cgi.sourceforge.net/>) ?

------
lquist
Hmm...

Does going from 30 servers to 3 actually make an impact to a $13B company?

------
derwiki
Without citing versions, it's hard to extract anything useful from this
article. Rails 2.1 on ree-1.8.7 performs very differently than Rails 3.2 on
1.9.3-p194.

------
VeejayRampay
Again with that little war of frameworks? Man there's a lot of money and pride
behind all this, dear god.

------
jrockway
Is 27 servers a lot?

------
benbjohnson
Can someone update the title to read: "LinkedIn Moved from Server to Client:
27 Servers Cut and Up to 20x Faster"?

~~~
hnriot
But that would be wrong, the server legitiamtely moved from rails to node.
Just because node is JavaScript doesn't mean that it automatically runs on the
client, JavaScript is a perfectly viable server language too.

The title could be improved by reflecting that this is for LinkedIn mobile,
but the rails->node is correct.

~~~
ericf
Not wrong, a lot of their performance gains were a result of caching their
templates client side and having their servers only return data. That is a
much smaller load on the server and easily could account for the reduction in
servers. The title makes it sound as if they reduced their servers and
increased their performance simply by migrating from ruby to node.

~~~
knewter
This. Many rails apps spend much of their time rendering views, and even a
decent caching strategy on the server can increase performance tons.

------
elpee
read all the comments, not a single mention about php, wtf world?

------
rorrr
Ruby is one of the slowest languages you can think of, while Javascript on V8
is only 2.3X slower than C++ (median).

[http://shootout.alioth.debian.org/u32/which-programs-are-
fas...](http://shootout.alioth.debian.org/u32/which-programs-are-fastest.php)

What I'm really surprised is that they got such a huge gain. Most projects
I've worked on are DB or I/O bound. Maybe they store everything in RAM.

~~~
jamesaguilar
They probably fixed query design issues at the same time as they moved
implementations. It strikes me as hilariously unlikely that LinkedIn was CPU-
bound.

------
dschiptsov
Replacing inefficient and bloated Rails, with custom coded framework, and
_byte-code interpreted Ruby for native code generating V8_ , losing in
readability in an order of magnitude? Well, nothing to see here.

------
antonpug
I hate Rails. Node is the way to go. Node > Python > Rails

~~~
evilduck
Library > Language > Framework?

~~~
antonpug
What I mean to say...in terms of modern web development, Javascript > Python >
Ruby and Node > Django > Rails.

