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

51–60 of 140 posts

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

#51

Post by ahupp »

pdelgallego wrote: post #35
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.

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

I think this taking the wrong lesson from Netscape. If you do a greenfield re-write of a multi-million line application you probably are going to have a bad time, but people successfully re-write smaller applications or portions of an application all the time. Since this was just a portion of the total functionality of LinkedIn, they incurred much less risk than a ground up rewrite would have.

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

#52

Post by dmorgan »

pdelgallego wrote: post #35
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.

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

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

That's a meme started by a Joel Spolsky article, and maybe an allusion to the "second system effect" (which is about something else altogether). Hardly "plenty of literature about that".

Actually, the complete rewrite might killed Netscape, but it saved Mozilla and Firefox. And Netscape was a multi-million line web browser engine, with a javascript interpreter, a full mail client and a wysiwyg editor thrown in. And multi-platform in C/C++ to boot.

That is, something an order of magnitude more difficult than LinkedIn or 99% of web properties out there.

There have been TONS of successful rewrites. Especially in the web space, it's almost trivial to rewrite your webapp or parts of it. To name but a few:

Twitter, the new Digg, SoundCloud, Basecamp, etc etc.

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

#53

Post by pyre »

Devilboy wrote: post #38
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

Is moving from Rails to Node not a complete rewrite?

They just wrote a Ruby interpreter for Node.js. Node.js is just that fast.

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

#54

Post by 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.

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

#56

Post by knewter »

gnufied wrote: post #31
justinjlynn wrote: post #26

Earlier quoted context omitted.

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

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

If you <3 EventMachine, check out Celluloid. It's a vastly more sensible approach to asynchronous code in ruby imo - uses the Actor Model (from erlang OTP, etc) to great effect.

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

#57

Post by andybak »

dmorgan wrote: post #52
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

> You will probably will get the same mess. There is plenty of literature about that. I.e: A complete rewrite is what killed Netscape That's a meme started by a Joel Spolsky article, and maybe an allusion to the "second system effect" (which is about something else altogether). Hardly "plenty of literature about that". Actually, the complete rewrite might killed Netscape, but it saved Mozilla and Firefox. And Netscap…

It's got a slightly longer history than just being a Joel Spolsky meme: http://en.wikipedia.org/wiki/Second-system_effect

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

#59

Post by andybak »

erichocean wrote: post #37
astrodust wrote: post #28

Earlier quoted context omitted.

Node.js is extremely hard to work with compared to Rails and moderately hard to work with compared to Django. The Node.js ecosystem has a lot of potential, but the variety of off-the-shelf add-ons is severely limited compared to either of those more mature frameworks. If you think Node.js is easy, you've never really experimented enough to understand what makes Rails so effortless. It's a lot easier to produce a prod…

Node.js is extremely hard to work with compared to Rails and moderately hard to work with compared to Django. Pro tip: Don't put this on your resume.

Meaning?

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

#60

Post by andybak »

markmm wrote: post #39
SoftwareMaven wrote: post #3

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

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…

I look forward to seeing C as the go-to web-development language.

Really? C for a problem that is largely string manipulation and database access?

Post reply on HN