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

81–90 of 140 posts

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

#81

Post by munificent »

markmm wrote: post #68
andybak wrote: post #60

Earlier quoted context omitted.

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?

Why are they moving from Ruby if it's just "string manipulation and database access"? The problem is folks, as soon as you get a large number of users every compromise you made by using a toy language or database is magnified 1000 times. Google didn't implement in some scripting language to get to the market a few months early.

That's because Google's initial product was CPU bound. Most web products aren't. Most of Youtube was and is written in Python.

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

#82

Post by yuhong »

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.

Actually the competitor deliberately did it in order to kill Netscape's business model. This also affected Opera too.

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

#83

Post by andersbreivik »

jonpaul wrote: post #12
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…

Why not write your code using Node.js because you actually enjoy using JavaScript? Or how about the convenience of writing in one language in your stack? Or how about the simplicity provided by not having to worry about threading per process? If you already know Python or Ruby, then ya, using Node.js would be silly. But if you have to pick one because you're equally familiar with all of the languages, then Node.js is…

" because you actually enjoy using JavaScript? "

You sick bastard!

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

#84

Post by drstewart »

markmm wrote: post #72
jonny_eh wrote: post #50

Earlier quoted context omitted.

But the odds of the thing you release actually getting used are low. So make it fast, and if it's a hit, then deal with that.

Wow!! your comment encapsulates the thinking of every wannabe startup loser that ends up smoking crack on some beach in San Francisco" Will making it faster increase the chances of more people using it? Also this attitude of building shit products (Yes software is a product) because..well the chances are it will fail.. is precisely why so many startups fail. This is why you get one crapola startup after another......…

Imagine your shock when you build your craptastic app in C++ and wonder why it's not any faster than a scripted app. I'll give you a hint ahead of time: most bottlenecks aren't processing time, they're DB or IO limited.

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

#87

Post by jeremyjh »

dmorgan wrote: post #75
tedunangst wrote: post #63

Earlier quoted context omitted.

the complete rewrite might killed Netscape, but it saved Mozilla and Firefox. What do you mean?

I mean that while Netscape, the company, succumbed while waiting to put out their new competitive browser, we now have the Mozilla Foundation and Firefox. We wouldn't have those if it wasn't for the rewrite. The old code was a mess even before version 4 (by its developers own admission), and it could never get to the point of competing in the engine space ever again. That is, with the old Netscape rendering engine it…

And since we are talking here more about technology, and not business models, we should more or less regard the Netscape rewrite as a success story. They did NOT produce a system that was over-engineered or that failed to perform well. Indeed it took a tremendous amount of market share. Now of course they complain about the code again but the situation is far from desperate.

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

#88

Post by jeremyjh »

kin wrote: post #18
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…

What I saw as a plus was that they combined front/back end teams into a single unit.

Am I the only person who doesn't believe this story? Because really, the whole reason we have front-end/back-end specialists is because front-end javascript ninjas can't learn RUBY??!?

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

#89

Post by [deleted] »

dkrich wrote: post #43
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.

I disagree. When you change state management to client side, you are making a fundamental architecture shift that is significant enough to remove a lot of server-side overhead. What makes you think refactoring code is going to give you a 10x improvement in efficiency? If your code is that bad, you should get rid of the developers along with the code.

[deleted]

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

#90

Post by jeremyjh »

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…

The em-synchrony project (https://github.com/igrigorik/em-synchrony) has patched versions of the mysql gem and they say they can run most of the rails stack. They use a fiber model to un-event the program flow a bit. Ilya is brilliant really. Still, I would be a little leary of betting LinkedIn on a bunch of monkey-patched client code. The challenge in porting to EM is that so many Ruby network clients will block. With Node.js that is impossible. I think though for a rewrite it wouldn't matter, you'd use the right libraries and design your app around the framework just like they had to do switching to Node.
Post reply on HN