read all the comments, not a single mention about php, wtf world?
LinkedIn Mobile Moved from Rails to Node: 27 Servers Cut and Up to 20x Faster
91–100 of 140 posts
Re: LinkedIn Mobile Moved from Rails to Node: 27 Servers Cut and Up to 20x Faster
#92Earlier quoted context omitted.
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.
> 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. In most cases, you're not. You're mostly making a big logic spaghetti mess on both the client and the server AND make your pages load slower, especially for the initial load (client performance, js loading times, etc). > What makes you think…
It's true that moving more logic and state management to the client side often increase page load times - but it also allows you (potentially) to make certain interactions much faster.
When you have real data on the client instead of just a bunch of markup, you can be a lot smarter about how and when you make additional AJAX requests. Optimistic updates can make a huge difference in perceived performance.
Re: LinkedIn Mobile Moved from Rails to Node: 27 Servers Cut and Up to 20x Faster
#93Earlier 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.
When a competitor undercuts your pricing with free, not doing anything for three years is unlikely to be the optimal response...
Re: LinkedIn Mobile Moved from Rails to Node: 27 Servers Cut and Up to 20x Faster
#94Earlier quoted context omitted.
"This times a thousand" would be an improvement by a factor of 10000. The improvement should definitely not be that large.
Thanks for the explanation, skeletonjelly. I think the reason I misunderstood is that I don't hang out on the Internet enough: a friend explained to me that "This." and "this times a thousand" are Internet slang that mean "I agree" (the second, presumably means something like "On a scale from 1 to infinity my agreement level is 1000." :). As far I know these expressions aren't used verbally, which would explain why I…
It means repeat it a thousand times for emphasis.
Re: LinkedIn Mobile Moved from Rails to Node: 27 Servers Cut and Up to 20x Faster
#95Earlier quoted context omitted.
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.
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?
Re: LinkedIn Mobile Moved from Rails to Node: 27 Servers Cut and Up to 20x Faster
#96I was on the team at LinkedIn when we first wrote the thing on Ruby on Rails. Here's my writeup containing some more context:
http://ikaisays.com/2012/10/04/clearing-up-some-things-about...
While I'll freely admit v8 is much faster than MRI Ruby, the efficiency gains are likely more related to 1) the rewrite factor 2) moving to non-blocking 3) the fact that the original server ... um, needed love
Re: LinkedIn Mobile Moved from Rails to Node: 27 Servers Cut and Up to 20x Faster
#97I personally find it hard to believe that all of LinkedIn was only running on 30 servers, and is now running on only 3. EDIT: Mobile only. Maybe the title should be updated to reflect that.
> I personally find it hard to believe that all of LinkedIn was only running on 30 servers, and is now running on only 3. I can believe it, if their caching strategy was garbage before and part of a massive rewrite was rethinking that. If you fail to use your caches, you'll pay for it. I mean it's not like LinkedIn is about split-second changes, you could probably statically generate most of it and serve it with a si…
Actually, we aggressively cached, which led to weird things happening. I posted a follow up about this explaining more context - I hope it gets voted up.
Re: LinkedIn Mobile Moved from Rails to Node: 27 Servers Cut and Up to 20x Faster
#98Ruby is one of the slowest languages you can think of, while Javascript on V8 is only 2.3X slower than C++ (median). http://shootout.alioth.debian.org/u32/which-programs-are-fas... What I'm really surprised is that they got such a huge gain. Most projects I've worked on are DB or I/O bound. Maybe they store everything in RAM.
It was a huge gain because the original Rails servers were running on single threaded Mongrel and blocking on cross data center IO.
Re: LinkedIn Mobile Moved from Rails to Node: 27 Servers Cut and Up to 20x Faster
#99Earlier 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.
Coming from Rails, Node is like opening a toolbox and finding it has a screwdriver, a wrench, and a hammer. Somehow you're expected to build things with that.
For those that love to build things from the ground up or to carve out new solutions, Node is a great place to be. I think it's got enormous potential and is biggest opportunity since Python and Ruby took off around years ago.
Just don't think because you can create the same sorts of apps with Node that it's as easy.
Ruby on Rails even three years ago was laughable compared to today's toolset. Node is catching up quickly, covering ground faster than Ruby ever did, but still lagging.
Re: LinkedIn Mobile Moved from Rails to Node: 27 Servers Cut and Up to 20x Faster
#100Earlier 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…
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.