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

121–130 of 140 posts

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

#121

Post by gizzlon »

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.

Interesting.. how often do you pull from the db's? Do you think about it as a write-through cache?

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

#122

Post by markmm »

SoftwareMaven wrote: post #76
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…

Said with true engineering "vision". The reason why "getting it out the door" is so important is because nobody behind the door generally has any idea about what people will really pay for. By making it fast (read: cheap ) to make, if you find that you don't get it right, you can try again, and again, and again. Now, you can argue that "they shouldn't be releasing without knowing they will be successful", but if they…

I can turn around a project in a few months easily, and all my _running_ software will be C or C++. The secret is leverage and code generation (Where I will use a scripting language)

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

#123

Post by jrabone »

drstewart wrote: post #84
markmm wrote: post #72

Earlier quoted context omitted.

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.

Not strictly true. In the bigger companies, everyone knows that DBs (which is really just a special case of I/O) and I/O are slow (we tend not to hire them if they don't - one of my favoured systems & arch. interview questions[1] is on memory/storage hierarchies). The more interesting problem is what ELSE you've traded off to eliminate I/O on the common path - and in many languages it turns out to be memory fragmentation and/or garbage collection time. In Java, stop-the-world GC pauses of multiple seconds are not unheard of, and it's no fun being Oracle's test bed for undocumented GC features. It's also no fun when you find out you can't restart your multi-gigabyte heap JVM because the underlying OS has fragmented RAM so badly it can't alloc that heap in a single contiguous chunk.

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

#124

Post by statictype »

benologist wrote: post #119
statictype wrote: post #115

Earlier quoted context omitted.

What were the benefits you saw in switching from .NET to Node? Was it in basic code structure/complexity or performance? I'd actually be very surprised if NodeJS running on Heroku (which is built on EC2) performs better than compiled .NET code running on dedicated Windows hardware.

The major benefits were persistant connections and background fetching of data - a lot of my requests serve data directly from local memory instead of hitting local or shared caches and databases. The equivalent in .NET I guess would be BackgroundWorkers that are independently prefetching the data required most of the time but I could never get them to Just Work. Specifically for my use case 99+ percent of requests r…

Interesting. Thanks for the answer. I'm a little surprised that .NET can't juggle network connections very well but in retrospect, I probably shouldn't be.

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

#125

Post by markmm »

drstewart wrote: post #84
markmm wrote: post #72

Earlier quoted context omitted.

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.

This is something newbies repeat to justify their choice of a piss poor implementation. Sure with 10 users hitting your Rails app it might perform the same as Nginx with a custom C handler talking to a database written in C, but increase the load and soon your handing Amazon thousands a month on ec2 nodes while I am still on a small Linode. The funny thing is because of code gen and experience I can probably write my app faster than you dicking around with framework after framework

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

#126

Post by markmm »

SoftwareMaven wrote: post #105
adgar2 wrote: post #95

Earlier quoted context omitted.

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 "opt…

How about worrying about both equally, if you still don't get it see Diaspora, great idea and lots of buzz, but implementation was shit and it was DOA.

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

#127

Post by benologist »

gizzlon wrote: post #121
benologist wrote: post #110

Earlier quoted context omitted.

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.

Interesting.. how often do you pull from the db's? Do you think about it as a write-through cache?

Every 30 or 60 seconds + the data's timestamped so it's usually a pretty minimal refresh.

It's really just like using any memcached or the built in .net caching rather than a write through one, new data reaches each dyno either via the periodic refresh or when it tries to create that record and finds it already exists. Writes are done immediately and the caches don't get updated because there's 8 - 16 dynos and why bother updating the single dyno that created it.

I did originally use redis pub/sub to push out updates to everything but I ended up removing it because it was unnecessary.

Here's some example code, it pre-fetches all the leaderboards (not scores) every 30 seconds: http://pastebin.com/asq6eExu

Higher up in the same script is the api for the leaderboard data with stuff like: http://pastebin.com/gsfvsZsv

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

#128

Post by benologist »

statictype wrote: post #124
benologist wrote: post #119

Earlier quoted context omitted.

The major benefits were persistant connections and background fetching of data - a lot of my requests serve data directly from local memory instead of hitting local or shared caches and databases. The equivalent in .NET I guess would be BackgroundWorkers that are independently prefetching the data required most of the time but I could never get them to Just Work. Specifically for my use case 99+ percent of requests r…

Interesting. Thanks for the answer. I'm a little surprised that .NET can't juggle network connections very well but in retrospect, I probably shouldn't be.

I think it's just whatever .NET's doing to pool them that has some tiny bit of overhead that doesn't matter most of the time.

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

#129

Post by throwa »

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.

This article actually gives details of their first implementation which suggest that they could cut servers without switching to node :

http://ikaisays.com/2012/10/04/clearing-up-some-things-about...

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

#130

Post by burke »

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 really need to quit reading HN comments. This entire thread is enraging. Both sides. Especially yours.
Post reply on HN