12 ms·

LinkedIn Mobile Moved from Rails to Node: 27 Servers Cut and Up to 20x Faster

204 points by turar 14y ago

justinjlynn 14y ago
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.
- some1else 14y ago
  The aggressive caching approach taken by Basecamp Next is another example of such an optimization: http://37signals.com/svn/posts/3112-how-basecamp-next-got-to-be-so-damn-fast-without-using-much-client-side-ui http://37signals.com/svn/posts/3112-how-basecamp-next-got-to...
  - aantix 14y ago
    DHH shows off some of the New Basecamp caching logic in this video : http://www.youtube.com/watch?v=FkLVl3gpJP4#t=33m30s http://www.youtube.com/watch?v=FkLVl3gpJP4#t=33m30s
- gnufied 14y ago
  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-behind-the-scenes-look-at-linkedins-mobile-engineering/2/ http://arstechnica.com/information-technology/2012/10/a-behi...
  - rhizome 14y ago
    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 14y ago
      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 14y ago
        What is the sense that it makes?
  - justinjlynn 14y ago
    Indeed, shifting to a streaming architecture can vastly reduce the amount of churn your application sees. This makes great sense if it fits the use case of your product. However, one need not throw out a huge existing code/knowledge base in order to accomplish this shift. I think that it's perfectly acceptable to shift to something like EventMachine + some HTTP layers to implement a streaming server using a good chunk of your existing codebase and developer experience. Node.js is the new hotness and so is the prospect of rewriting your application cleaner, faster and better... but often, the less you have to rewrite or learn, the more likely it is that your project will be successful.
    - gnufied 14y ago
      If I had a choice I would have certainly picked EM. But I am not sure, how much of Rails code can be ported over to Event driven model of EM. I think the only thing which can be reliably ported is models. Now, they did evaluate EM apparently and according to them node.js performed 20 times better than EM/twisted in certain tests and hence they went ahead with node.js. I am curious as anyone else to see, what those tests were.
SoftwareMaven 14y ago
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 14y ago
  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.
  - asianexpress 14y ago
    My thoughts exactly -- going from 30 to 3 servers is no joke and it couldn't just be because of a move to node.js
  - nicholassmith 14y ago
    This times a thousand. When you first write the software you're basing it on expectations, no matter how well you plan, but when you rewrite it you're coming at it with real world knowledge of the pain points so of course it's going to be better in terms of performance.
    - omaranto 14y ago
      "This times a thousand" would be an improvement by a factor of 10000. The improvement should definitely not be that large.
      - skeletonjelly 14y ago
        You're getting downvoted because the poster was referring to the gravity/importance of the message.
dpcx 14y ago
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 14y ago
  > 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 14y ago
    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.
wardb 14y ago
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 14y ago
  Like a lot of contemporary online companies, they might be skimping on sysadmins.
- cmccabe 14y ago
  yeah, but it's easier politically to rewrite it in a newer language. If you rewrite it in the same language, then you have to explain your rewrite as cleaning up someone's braindead mistakes-- someone who might still work there. If you rewrite it in a different language, then you get to blame the old language and framework for all the problems. No harm, no foul-- and you get to put the new shiny thing on your resume.
benbjohnson 14y ago
Can someone update the title to read: "LinkedIn Moved from Server to Client: 27 Servers Cut and Up to 20x Faster"?
- hnriot 14y ago
  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 14y ago
    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 14y ago
      This. Many rails apps spend much of their time rendering views, and even a decent caching strategy on the server can increase performance tons.
skyebook 14y ago
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.
gnufied 14y ago
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-behind-the-scenes-look-at-linkedins-mobile-engineering/2/ http://arstechnica.com/information-technology/2012/10/a-behi...
- pepve 14y ago
  I think they created a specific benchmark for their use case. Maybe they even implemented part of their requirements on both stacks.
- megaman821 14y ago
  They should really release those benchmarks. From what I have seen Python/Gevent performance is on par with Node.js and I doubt Ruby/Eventmachine is that far behind either. If they found a 20x performance difference there is probably a bug in one of those competing libraries.
antonpug 14y ago
I hate Rails. Node is the way to go. Node > Python > Rails
- evilduck 14y ago
  Library > Language > Framework?
  - antonpug 14y ago
    What I mean to say...in terms of modern web development, Javascript > Python > Ruby and Node > Django > Rails.
- markmm 14y ago
  1 server running Nginx with modules + Postgresql == 100 servers running Ruby/Node/Some scripting shit slow language talking to some NoSql crap.
- j95tin 14y ago
  Having an opinion is fine, but you need to support it with an explanation and/or data.
- deleted 14y ago
  [deleted]
SanjayUttam 14y ago
"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?
fomojola 14y ago
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 14y ago
  It's mangled from the original article.
jemfinch 14y ago
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.
scott_meade 14y ago
"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".
derwiki 14y ago
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.
pragmatic 14y ago
The original article: http://arstechnica.com/information-technology/2012/10/a-behind-the-scenes-look-at-linkedins-mobile-engineering/2/ http://arstechnica.com/information-technology/2012/10/a-behi... 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.
rorrr 14y ago
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-fastest.php http://shootout.alioth.debian.org/u32/which-programs-are-fas... 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 14y ago
  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.
- ikailan 14y ago
  It was a huge gain because the original Rails servers were running on single threaded Mongrel and blocking on cross data center IO.
trekkin 14y ago
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.
jrockway 14y ago
Is 27 servers a lot?
elpee 14y ago
read all the comments, not a single mention about php, wtf world?
ikailan 14y ago
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-linkedin-mobiles-move-from-rails-to-node-js/ http://ikaisays.com/2012/10/04/clearing-up-some-things-about... 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
shn 14y ago
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).
rapind 14y ago
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.
lsh123 14y ago
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.
dschiptsov 14y ago
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.
chmike 14y ago
What would they gain if they moved from node to nginx and a c++ with asio backend (e.g. http://cgi.sourceforge.net/ http://cgi.sourceforge.net/) ?
VeejayRampay 14y ago
Again with that little war of frameworks? Man there's a lot of money and pride behind all this, dear god.
lquist 14y ago
Hmm... Does going from 30 servers to 3 actually make an impact to a $13B company?

204 points by turar 14y ago

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.

some1else 14y ago
The aggressive caching approach taken by Basecamp Next is another example of such an optimization: http://37signals.com/svn/posts/3112-how-basecamp-next-got-to-be-so-damn-fast-without-using-much-client-side-ui http://37signals.com/svn/posts/3112-how-basecamp-next-got-to...
- aantix 14y ago
  DHH shows off some of the New Basecamp caching logic in this video : http://www.youtube.com/watch?v=FkLVl3gpJP4#t=33m30s http://www.youtube.com/watch?v=FkLVl3gpJP4#t=33m30s
gnufied 14y ago
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-behind-the-scenes-look-at-linkedins-mobile-engineering/2/ http://arstechnica.com/information-technology/2012/10/a-behi...
- rhizome 14y ago
  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 14y ago
    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 14y ago
      What is the sense that it makes?
- justinjlynn 14y ago
  Indeed, shifting to a streaming architecture can vastly reduce the amount of churn your application sees. This makes great sense if it fits the use case of your product. However, one need not throw out a huge existing code/knowledge base in order to accomplish this shift. I think that it's perfectly acceptable to shift to something like EventMachine + some HTTP layers to implement a streaming server using a good chunk of your existing codebase and developer experience. Node.js is the new hotness and so is the prospect of rewriting your application cleaner, faster and better... but often, the less you have to rewrite or learn, the more likely it is that your project will be successful.
  - gnufied 14y ago
    If I had a choice I would have certainly picked EM. But I am not sure, how much of Rails code can be ported over to Event driven model of EM. I think the only thing which can be reliably ported is models. Now, they did evaluate EM apparently and according to them node.js performed 20 times better than EM/twisted in certain tests and hence they went ahead with node.js. I am curious as anyone else to see, what those tests were.

SoftwareMaven 14y ago

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 14y ago
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.
- asianexpress 14y ago
  My thoughts exactly -- going from 30 to 3 servers is no joke and it couldn't just be because of a move to node.js
- nicholassmith 14y ago
  This times a thousand. When you first write the software you're basing it on expectations, no matter how well you plan, but when you rewrite it you're coming at it with real world knowledge of the pain points so of course it's going to be better in terms of performance.
  - omaranto 14y ago
    "This times a thousand" would be an improvement by a factor of 10000. The improvement should definitely not be that large.
    - skeletonjelly 14y ago
      You're getting downvoted because the poster was referring to the gravity/importance of the message.

dpcx 14y ago

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 14y ago
> 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 14y ago
  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.

wardb 14y ago

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 14y ago
Like a lot of contemporary online companies, they might be skimping on sysadmins.
cmccabe 14y ago
yeah, but it's easier politically to rewrite it in a newer language. If you rewrite it in the same language, then you have to explain your rewrite as cleaning up someone's braindead mistakes-- someone who might still work there. If you rewrite it in a different language, then you get to blame the old language and framework for all the problems. No harm, no foul-- and you get to put the new shiny thing on your resume.

benbjohnson 14y ago

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

hnriot 14y ago
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 14y ago
  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 14y ago
    This. Many rails apps spend much of their time rendering views, and even a decent caching strategy on the server can increase performance tons.

skyebook 14y ago

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.

gnufied 14y ago

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-behind-the-scenes-look-at-linkedins-mobile-engineering/2/ http://arstechnica.com/information-technology/2012/10/a-behi...

pepve 14y ago
I think they created a specific benchmark for their use case. Maybe they even implemented part of their requirements on both stacks.
megaman821 14y ago
They should really release those benchmarks. From what I have seen Python/Gevent performance is on par with Node.js and I doubt Ruby/Eventmachine is that far behind either. If they found a 20x performance difference there is probably a bug in one of those competing libraries.

antonpug 14y ago

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

evilduck 14y ago
Library > Language > Framework?
- antonpug 14y ago
  What I mean to say...in terms of modern web development, Javascript > Python > Ruby and Node > Django > Rails.
markmm 14y ago
1 server running Nginx with modules + Postgresql == 100 servers running Ruby/Node/Some scripting shit slow language talking to some NoSql crap.
j95tin 14y ago
Having an opinion is fine, but you need to support it with an explanation and/or data.
deleted 14y ago
[deleted]

SanjayUttam 14y ago

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

fomojola 14y ago

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 14y ago
It's mangled from the original article.

jemfinch 14y ago

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.

scott_meade 14y ago

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

derwiki 14y ago

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.

pragmatic 14y ago

The original article: http://arstechnica.com/information-technology/2012/10/a-behind-the-scenes-look-at-linkedins-mobile-engineering/2/ http://arstechnica.com/information-technology/2012/10/a-behi... 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.

rorrr 14y ago

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-fastest.php http://shootout.alioth.debian.org/u32/which-programs-are-fas... 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 14y ago
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.
ikailan 14y ago
It was a huge gain because the original Rails servers were running on single threaded Mongrel and blocking on cross data center IO.

trekkin 14y ago

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.

jrockway 14y ago

Is 27 servers a lot?

elpee 14y ago

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

ikailan 14y ago

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-linkedin-mobiles-move-from-rails-to-node-js/ http://ikaisays.com/2012/10/04/clearing-up-some-things-about... 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

shn 14y ago

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

rapind 14y ago

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.

lsh123 14y ago

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.

dschiptsov 14y ago

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.

chmike 14y ago

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

VeejayRampay 14y ago

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

lquist 14y ago

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