Blazing fast node.js: performance tips from LinkedIn
engineering.linkedin.com
engineering.linkedin.com
Should anyone be shocked that you shouldn't do synchronous calls in an asynchronous framework? Or that you should use nginx to serve your static content and not Node? Requesting remote services in parallel is a no brainer. What does blazing fast really mean here? Using your framework correctly just sounds like "normal fast".
Are these types of errors a symptom of touch screen input, or apathy? I have noticed the occurrence has increased greatly over the last few months. I feel like a pedantic asshole, but it greatly impairs my ability to read comments fast, and it gives me the impression that code written by the same people would confuse me as a beginner/ hobbyist.
Given the number of hacked password databases that weren't hashed and salted, this might actually be useful.
For what it's worth I'm working on a project that uses Node.js and took something away from this article.
I didn't
> Comment if you disagree with her points
That would be what you're replying to now...
2 is just a bad tip. Socket pooling is a useful feature. Opening up more connections than you (or the server) can handle will lead to poor performance.
3 and 5 isn't Node.js-specific and you're better off reading https://developers.google.com/speed/ to learn the fine details.
Instead of following 1, 8 and 9 you should learn how to profile your application so you can find the true bottlenecks of your app.
4 and 7 are just weird. Going session-free or switching to client-side architecture are both big tasks; I'd love to hear more about the real challenges, not just "this is fast, zomg!!"
I wish this post had more meat. How did they end up with these tips? How did they profile? How did they benchmark? Where can I read more about the other tips? Without any good links to learn more about the details (seriously, linking to gzip.org was the best you could do?) I'd say these tips can almost do more harm than good…
My remark was against their "Keep your code small and light". Making your code lighter doesn't always make it faster. If you can get your code to do less (like, skipping memory-based sessions), that will make it faster. If all you're doing is avoiding complexity, there's no guarantee it will be perform better.
The proper way is to benchmark and profile. You can refactor your code based on developer happiness, but only try increase its performance based on objective data.
EDIT: I should probably clarify this (although it seems silly to have to do this on HN): I consider callback-based code yet another tool for solving problems, not something you preach for/against. There is a time and place for callback-based code, just as there is a time and place where it's not a good idea.
If you are in a different environment, the arguments for/against become much different.
Node doesn't really give you much of a choice. If something is going to take awhile then you will be using callbacks, it's that simple.
I'm not sure how #4 is weird. It can make sense in certain circumstances, as template rendering can be quite expensive. Making this change, though, without data from profiling is probably unnecessary.
Although you didn't touch on #6, they probably should have explained this in a little more detail.
It does sound like they made the decision to use binary modules as a result of profiling, and the fact binary modules exist might be useful info to a node n00b.
This article should probably have been presented more as food for thought, rather than Node's pseudo ten commandments for performance, but nevertheless, it's a useful article for the most part. Developers (well, seasoned ones at least) know to apply critical thinking to all advice anyway.
Yay they made loading fast apparently. But any user of the app will notice that the linked in app feels slow and clunky. Great shit loaded. But it still feels slow. For example, take an iPad and go to Flipboard. Rotate the device. Notice how fast and smooth it is. Now go to the news feed in the iOS LinkedIn app and Rotate. It's slow. It feels like a web browser. It feels like they spent so much time optimizing the loading of resources and spent ZERO time actually making the client feel nice and native.
It makes perfect sense in hindsight, even though at the time it could be easy to think, "how much could this really hurt?"
You really want to avoid synchronous calls all of the time in node.js unless you are at a point in the app's life where it makes sense to block if necessary, such as on startup or shutdown.
Since this call was used in logging my guess is that the synchronous write call was called a lot and was easy to spot because of it. There are other places where calls like that would be harder to track down. As with any programming environment it is important to understand how things are working at least one abstraction level below the code you are writing.
[1]: http://engineering.twitter.com/2012/05/improving-performance...
In Twitter's case, client-side rendering was slow while server-side wasn't. In LinkedIn's case, html_download was slow while client_render_json_to_html wasn't. Performance aside, there are numerable reasons to go either away, all of which vary from project to project.
Having Worked with CoffeeScript + Twitter Bootstrap + BackboneJS/Underscore + LessCSS for some time now, I know I will not willingly go back to the old server-side ways unless there is a major reason to. Working fully client-side to make UI and relying on REST API / JSON is wonderful experience, especially when the app feels so responsive.
Obviously if you have node doing less it's going to be "faster". Or is it? I'm not really sure that offloading tasks qualifies as being faster. I'd like to see some data on this though. Basic caching as supplied with connect should serve static files pretty damn fast I would think. Perhaps nginx does that for a living and kicks ass, but node shouldn't be all that bad.
The approach I favour is to put varnish in front of a classic slow script webserver (tornado, but use node if you prefer).
Tornado has this neat way of baking-in versioning to static content so clients (and proxies) can do aggressive caching http://www.tornadoweb.org/documentation/overview.html#static...
Best of both worlds.
-Node has more cycles to compute things?
-The server node's on has less contention to deal with (disk, network)?
-Putting statics on another server allows the browser more simultaneous connections when loading the page, so it loads faster by default?
"Don't use Node.js for static assets" is an interesting observation but I'd like to know exactly why.
Java is hands down faster.
I have never seen a benchmark that showed Node coming even close to Java performance.