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

Clearing up some things about LinkedIn mobile’s move from Rails to node.js

ikaisays.com

Post reply on HN
Print view View original

21–30 of 33 posts

Re: Clearing up some things about LinkedIn mobile’s move from Rails to node.js

#21

Post by JimmaDaRustla »

The concept that I got from the main article was that they tailored their application for "long-lived connection" to avoid multiple resource calls to make their web server more responsive. They also mention things like using "aggressive cacheing", "storing templates locally", "using timestamps to stream only required resources", "rearchitecture and rewrite."

Never once did I ever feel this article was advising that node.js was superior to RoR - they only every justified, at a high level, a way better approach (in terms of server load) to an "MVC" like architecture by leveraging client side frameworks and technique to lessen server load.

The author of this article also makes it clear at the end by stating that comparing the solutions is apples to oranges, but so did the original article...so I don't get the need for "clarification".

EDIT: I retract my "way better" statement - I mean "way better" in the sense of server load.

Re: Clearing up some things about LinkedIn mobile’s move from Rails to node.js

#22

Post by JimmaDaRustla »

klochner wrote: post #5

This sounds much more sane than "node is 20x faster than rails", thanks for validating the assumption most of us were making.

I interpreted the original article that their new node.js approach was wildly different than a server-based MVC framework.

Sure, they ended up with 20x greater speed, but never did they say that it was because node.js. They even provide a high-level detailed description of all the things they did with their new approach to achieve this performance.

Re: Clearing up some things about LinkedIn mobile’s move from Rails to node.js

#24

Post by brown9-2 »

davedx wrote: post #12
eta_carinae wrote: post #8

> And those requirements kept growing. If my calculations are correct, the standard setup for engineers now is a machine with 20 or more gigabytes of RAM just to RUN the software. Close. In 2011, all the engineer desktops got upgraded to 36Gigs. At the time, the eng department still hadn't figured out how to deploy without duplicating hundreds of jar files everywere.

Wow, that sounds like fun. What exactly is in the LinkedIn stack that requires so much memory?

Speculation, but it sounds like the main webapp you see at linkedin.com is a single monolithic application.

Re: Clearing up some things about LinkedIn mobile’s move from Rails to node.js

#26

Post by marknutter »

JimmaDaRustla wrote: post #22
klochner wrote: post #5

This sounds much more sane than "node is 20x faster than rails", thanks for validating the assumption most of us were making.

I interpreted the original article that their new node.js approach was wildly different than a server-based MVC framework. Sure, they ended up with 20x greater speed, but never did they say that it was because node.js. They even provide a high-level detailed description of all the things they did with their new approach to achieve this performance.

Yes, but the title on HN implied that. We need to be better about writing our submission titles, but hey, sex sells.

Re: Clearing up some things about LinkedIn mobile’s move from Rails to node.js

#27

Post by jfoutz »

marknutter wrote: post #26
JimmaDaRustla wrote: post #22

Earlier quoted context omitted.

I interpreted the original article that their new node.js approach was wildly different than a server-based MVC framework. Sure, they ended up with 20x greater speed, but never did they say that it was because node.js. They even provide a high-level detailed description of all the things they did with their new approach to achieve this performance.

Yes, but the title on HN implied that. We need to be better about writing our submission titles, but hey, sex sells.

I'm sure you mean high scalability's linkbait titles, right?

Re: Clearing up some things about LinkedIn mobile’s move from Rails to node.js

#28

Post by JimmaDaRustla »

marknutter wrote: post #26
JimmaDaRustla wrote: post #22

Earlier quoted context omitted.

I interpreted the original article that their new node.js approach was wildly different than a server-based MVC framework. Sure, they ended up with 20x greater speed, but never did they say that it was because node.js. They even provide a high-level detailed description of all the things they did with their new approach to achieve this performance.

Yes, but the title on HN implied that. We need to be better about writing our submission titles, but hey, sex sells.

True! Thanks.

"LinkedIn Moved from Rails to Node: 27 Servers Cut and Up to 20x Faster" should say something like "LinkedIn did a rewrite and rearchitecture that cut 27 Servers and increase speed aby 20x"

Re: Clearing up some things about LinkedIn mobile’s move from Rails to node.js

#29

Post by flatline3 »

brown9-2 wrote: post #24
davedx wrote: post #12

Earlier quoted context omitted.

Wow, that sounds like fun. What exactly is in the LinkedIn stack that requires so much memory?

Speculation, but it sounds like the main webapp you see at linkedin.com is a single monolithic application.

Even if it is a single monolithic application, it in no way could explain the use of that much RAM.

Re: Clearing up some things about LinkedIn mobile’s move from Rails to node.js

#30

Post by joshhart »

davedx wrote: post #12
eta_carinae wrote: post #8

> And those requirements kept growing. If my calculations are correct, the standard setup for engineers now is a machine with 20 or more gigabytes of RAM just to RUN the software. Close. In 2011, all the engineer desktops got upgraded to 36Gigs. At the time, the eng department still hadn't figured out how to deploy without duplicating hundreds of jar files everywere.

Wow, that sounds like fun. What exactly is in the LinkedIn stack that requires so much memory?

Systems actually come standard with 48 gigs :) As it turns out, that's really useful for the part of my job requiring data modeling.

Somebody suggested LinkedIn is one large application, which is absolutely false. It's composed of many small applications, each deployed as a WAR file since the non-Node.js part of the site is on the JVM. There's a lot of overhead that comes from deploying this way. It doesn't matter in production or staging, but it adds up on a desktop.

At this point in time though, dev machines have stopped growing because we have shared stacks you can deploy a couple pieces of the application against if you want to test the whole thing.

Post reply on HN