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

101–110 of 140 posts

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

#101

Post by shn »

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

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

#102

Post by wpietri »

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

App speed matters some. But not nearly as much as a lot of other things. And when speed is the biggest problem, your users can tell you and the fixes are pretty straightforward.

The hard things to solve require a lot of user-facing iteration. Basically, the faster you can try new things, the more likely you'll get product-market fit before you run out of money.

My feelings on Rails are decidedly mixed, but fast prototyping is one of the things they got right.

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

#103

Post by grandalf »

astrodust wrote: post #100
grandalf wrote: post #48

Earlier quoted context omitted.

I used to think this until I built an app with node... every time I got to a point where I wanted a library or framework, a mature, well-supported one existed. Yes I had a bit of a learning curve since it was my first node app, but I was shocked at how smoothly it went and this was over a year ago.

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

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

#104

Post by rapind »

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.

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

#105

Post by SoftwareMaven »

adgar2 wrote: post #95
JL2010 wrote: post #80

Earlier quoted context omitted.

An excerpt from Google history: ---------------------------- Some Rough Statistics (from August 29th, 1996) BackRub is written in Java and Python and runs on several Sun Ultras and Intel Pentiums running Linux. The primary database is kept on an Sun Ultra II with 28GB of disk. Scott Hassan and Alan Steremberg have provided a great deal of very talented implementation help. Sergey Brin has also been very involved and…

And now the real heavy lifting for Google web search is C++, as everybody with a clue knows. What's your point?

The point is that most companies don't get to the point that the difference between C++ and Python matters. Worrying more about the business and less about the technology will be more likely to see you succeed than worrying more about the technology and less about the business.

I don't believe all companies can survive with a python or ruby solution. I do think that, as technologists, we worry too much about the "optimal" solution to technical problems when, in most cases, businesses are made or lost in people problems. People problems are really hard because there are few "right" answers. Instead, it is an optimization game, and optimization games require agility.

If you are that amazing at C or C++ that you can iterate amazingly quickly with them, then use them! That will give you a leg up later. I've been developing software for 15 years and have use everything from C and C++ to Java to Python to Objective C; and I've seen a massive difference in my ability to iterate with each of them.

Optimize for what works best for you, but don't be surprised if you choose C++ and a competitor who doesn't care about the "perfect" solution runs circles around you in the market because they chose something different (even if they re-write in C++ in 10 years, after they've stolen all of your customers).

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

#106

Post by dguaraglia »

omaranto wrote: post #34
nicholassmith wrote: post #20

Earlier quoted context omitted.

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.

"This times a thousand" would be an improvement by a factor of 10000. The improvement should definitely not be that large.

LOL, apparently sarcasm and witty banter is not HN forte :P

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

#107

Post by freditup »

omaranto wrote: post #34
nicholassmith wrote: post #20

Earlier quoted context omitted.

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.

"This times a thousand" would be an improvement by a factor of 10000. The improvement should definitely not be that large.

We don't all have English as our first language, and there's no problem with that. I'd have replied exactly as you did if I thought he literally meant "this times a thousand"

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

#108

Post by kin »

jeremyjh wrote: post #88
kin wrote: post #18

Earlier quoted context omitted.

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

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 doing things.

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

#109

Post by ikailan »

kin wrote: post #108
jeremyjh wrote: post #88

Earlier quoted context omitted.

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

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 development because of node.js" argument. Any sufficient competent backend developer can start writing Python code in a day. What that developer doesn't get in a day is understanding deployments, popular Python libraries, the ecosystem, etc.

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

#110

Post by benologist »

Smudge wrote: post #10
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'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.

Post reply on HN