Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

highscalability.com

Post reply on HN
Print view View original

131–140 of 140 posts

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

#131

Post by jeremyjh »

ikailan wrote: post #109
kin wrote: post #108

Earlier quoted context omitted.

It's believable to me. The whole reason we have front-end/back-end specialist isn't because front-end js people can't learn Ruby but rather it's the same reason why front-end/back-end is separated code-wise. Depending on how they're using node they could very well keep this segregation. But some implementations with node have server/client sharing code. I know I've seen examples of this. I imagine that's how they're…

I don't think it's about the language - it's about knowledge. A backend specialist can learn Javascript but may not know the nuances of working with the DOM, or optimizing for pagespeed, or the important front end libraries. Similarly, a front-end specialist may not have all the experience necessary to diagnose problems in a deployment. That's one reason I don't buy the "front end developers can now do backend develo…

Exactly.

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

#132

Post by flyinglizard »

yxhuvud wrote: post #112
markmm wrote: post #39

Earlier quoted context omitted.

I would spend a little extra time upfront and save many many expensive rewrites latter on. Use C from the start, you won't need to rewrite just scale with hardware. This argument that using Ruby (or any language that makes programming easy but runs like treacle) to get something out the door a few months earlier is bullshit, I would rather release something a few months later that I didn't have to totally rewrite dow…

What makes you think you know the problem space enough to make a C implementation that you won't have to rewrite 10 times? Writing in C certainly doesn't stop any rewrites at least where I work.

This. I'm as hardcore C programmer as they come and I still find it better to start with Python and reimplement in C when the application becomes familiar and finite. It's faster, easier and cheaper.

The basic notion is that every bit of code is better the second time its written, and C development is just too slow for the first iteration.

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

#133

Post by antonpug »

evilduck wrote: post #36
antonpug wrote: post #30

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

Library > Language > Framework?

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

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

#134

Post by megaman821 »

gnufied wrote: post #24

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…

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.

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

#135

Post by astrodust »

grandalf wrote: post #103
astrodust wrote: post #100

Earlier quoted context omitted.

When you want a 100% solution and Node gives you a 95% one that 5% can be a deal-breaker. Node is nearly there, which is frustrating because it has so much potential, but it's just not yet. I think in the long run Node will beat the pants off of Rails but it's going to take an enormous amount of work to make that happen.

What's the missing 5%? I'm personally partial to sinatra so I might be missing it there also :)

Sinatra is a lot closer to Node and Django than Rails in terms of philosophy. It's more minimalist, where you must assemble a lot of your environment rather than be issued one by default.

The missing 5% is mostly things that make your development process more effortless.

I've found that it's easy to get a first cut of an application out inside of two weeks with Rails, but you will probably need more time or lower expectations when working with something more limited like Django or Sinatra.

Since Rails imposes a lot of conventions, applications are easier to organize if you follow the rules. Sinatra is far more open to interpretation, so if you're not disciplined it can turn in to a bit of a mess.

I'm a big fan of the DRY principle and it's much easier to apply within Rails than in other environments. A lot of this relates to how Ruby is a lot easier to meta-program than other languages.

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

#137

Post by kin »

ikailan wrote: post #109
kin wrote: post #108

Earlier quoted context omitted.

It's believable to me. The whole reason we have front-end/back-end specialist isn't because front-end js people can't learn Ruby but rather it's the same reason why front-end/back-end is separated code-wise. Depending on how they're using node they could very well keep this segregation. But some implementations with node have server/client sharing code. I know I've seen examples of this. I imagine that's how they're…

I don't think it's about the language - it's about knowledge. A backend specialist can learn Javascript but may not know the nuances of working with the DOM, or optimizing for pagespeed, or the important front end libraries. Similarly, a front-end specialist may not have all the experience necessary to diagnose problems in a deployment. That's one reason I don't buy the "front end developers can now do backend develo…

I'm not saying they've removed specialists. I believe they still exist. But in switching to node, because client/server shares a language, they're now capable of sharing code as well. Which is what I imagine they are doing, which is why it's logical that they've merged teams. This doesn't rule out that front/back-end specialists are removed and become well-rounded rather, they're just working together more.

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

#139

Post by segmond »

zorked wrote: post #73
pdelgallego wrote: post #35

Earlier quoted context omitted.

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

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.

how was netscape to survive back then? making money from ads was not in. microsoft had plenty of other ways to earn money. would you write millions of lines of code and give it away for free?

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

#140

Post by commentzorro »

benologist wrote: post #110
Smudge wrote: post #10

Earlier quoted context omitted.

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.

Node has some pretty unique benefits, I save a good $1000/month from switching from .NET on dedicateds to NodeJS on a PaaS (Heroku), and that was after 2 - 3 years of writing and rewriting and optimizing the .NET stuff. Biggest improvements came from persistant connections to redis/mongodb and polling for updated information independently of requests so there was no cached-or-fetch shenanigans at all in some areas.

>> " I save a good $1000/month from switching from .NET on dedicateds to NodeJS on a PaaS (Heroku)"

I'm really puzzled by this. A single dedicated large .NET box (16GB RAM and 6 Core Processor, 1TB raid, etc.) runs $150 a month. When I was looking at PaaS, Heroku came in more than five times that much for similar capability. $1,000 a month gets me SIX of these dedicated boxes that can be tied together as needed.

Why was your setup so much more for dedicated that you could _save_ that much, much less why you would be spending that much in the first place?

Post reply on HN