6 ms·
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 probab
by Smudge 14y ago
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.
- asianexpress 14y agoMy thoughts exactly -- going from 30 to 3 servers is no joke and it couldn't just be because of a move to node.js
- nicholassmith 14y agoThis 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.
- omaranto 14y ago"This times a thousand" would be an improvement by a factor of 10000. The improvement should definitely not be that large.
- skeletonjelly 14y agoYou're getting downvoted because the poster was referring to the gravity/importance of the message.
- omaranto 14y agoThanks 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 took it literally.
- xenophanes 14y agoIt means repeat it a thousand times for emphasis.
- dguaraglia 14y agoLOL, apparently sarcasm and witty banter is not HN forte :P
- freditup 14y agoWe 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"
- nicholassmith 14y agoI included an extra bit of improvement to deal with inflation rates.
- ericcholis 14y agoI'm with you on this one. I'm currently in the process of re-platforming and I'm noticing considerable gains just from revising the way certain process are done. You find a lot of "wtf was I thinking".
- pdelgallego 14y ago>> 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
- ahupp 14y agoI think this taking the wrong lesson from Netscape. If you do a greenfield re-write of a multi-million line application you probably are going to have a bad time, but people successfully re-write smaller applications or portions of an application all the time. Since this was just a portion of the total functionality of LinkedIn, they incurred much less risk than a ground up rewrite would have.
- Devilboy 14y agoIs moving from Rails to Node not a complete rewrite?
- pyre 14y agoThey just wrote a Ruby interpreter for Node.js. Node.js is just that fast.
- OriginalSyn 14y agoWhere can I see this?
- jrockway 14y agoYou'll have to wait until April 1.
- tedunangst 14y agoIt doesn't count as a rewrite when the rewrite is in a language that's cooler than the original version.
- 14y ago
- dkrich 14y agoI 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.
- dmorgan 14y ago>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 refactoring code is going to give you a 10x improvement in efficiency? Because even correctly implementing just the caching layer, with nested/micro-caching, can give you up to 1000x improvement in efficiency in the first place.
- kevincennis 14y agoIt'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.
- deleted 14y ago[deleted]
- fleitz 14y agoYeah as the article notes the old version used HTML and the new version uses binary blobs. This is hardly surprising.
- benologist 14y agoNode 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.
- statictype 14y agoWhat 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.
- benologist 14y agoThe 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 receive some data, do some light manipulations and then push the data to redis about 8,000 to 12,000 times a second. With .NET I could only push to locally running software instances because anything remote couldn't keep up with the connection volume (without throwing even more hardware at the problem).
- statictype 14y agoInteresting. 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.
- benologist 14y agoI 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.
- throwa 14y agoThis 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-linkedin-mobiles-move-from-rails-to-node-js/ http://ikaisays.com/2012/10/04/clearing-up-some-things-about...