
Blazing fast node.js: performance tips from LinkedIn - diwank
http://engineering.linkedin.com/nodejs/blazing-fast-nodejs-10-performance-tips-linkedin-mobile
======
sausagefeet
Meh, this post was pretty unsatisfying.

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

~~~
SiVal
A good checklist of important items for optimizing performance should list the
important items. That's what she did. Each reader can then skip over the items
he already knows. It wouldn't be a better checklist if it left out important
items on the grounds that some readers might already know some of them.

~~~
sausagefeet
Well, she failed to mention "make sure computer is plugged in". Please, it's
2012, if you are using an asynchronous framework, doing things asynchronously
should hardly be a surprise. And serving static content via a CDN or Nginx has
knowledge order than dirt. This information would be fine if I was reading a
college students blog, but this is LinkedIn, I expect something a little bit
more. Maybe the next blog post will be on how to store salted passwords?

~~~
18pfsmt
What does, "knowledge order than dirt" mean, exactly?

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.

~~~
j2labs
It's a typo for "older".

------
judofyr
I like how the 10th tip is completely opposite of the 1st one.

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…

~~~
adrianbravo
Practice what you preach. Passive-aggressively sniping at asynchronous code by
implying it can never be small or light is not a valid argument. There is no
"meat" to such a subjective position.

~~~
judofyr
Callback-based code will always be more complex than synchronous code (and I
believe that's an objective observation), but please let's not go there.

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.

~~~
btilly
Inside of an asynchronous framework where every call blocks all others (eg
Node.js), callback-based code is almost always going to be the right choice.
If you can't immediately produce the answer, don't wait. And if you can
immediately produce the answer but it will take a while, break it up into
multiple smaller computations so that you do not block.

If you are in a different environment, the arguments for/against become much
different.

------
evanlong
"We worked hard to make our mobile apps fast. Try them out and let us know how
we did: we have an iPhone app, Android app and an HTML5 mobile version."

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.

~~~
viggio24
Compared with the web based apps we had in the past the LinkedIn one is a
great step forward. The main point according to me is not the fact that web
vieww apps are slow, for sure things will improve in the future and web view
perofrmances will increase in the time thus reducing the performance impact in
most apps. The main point that should be discussed is why these guys insist in
using html and js. People seem to forfet where html is coming from: it was a
way to layout a page on screen. The reason why html acquired "desktop
application like" capabilities was to provide some desktop features to
internet based apps: at the end the clear winner was html5+js+css, while java
applet failed and flash is its decline. Looking at the efforts done by
LinkedIn engineers, you may appreciate the hard work they did and the
interesting way they faced several challenges, but what surprises me is why
those guys didn't follow the Obj-C approach that would have given to them the
possibility to reach better results in a more natural way. According to me
html should be used only in those cases where it is superior to Obj-C:
publishing. It offers much more capabilities than PDF at lower cost. All other
usages are wrong. Someone may anseer that LinkedIn preferred to follow the
html based approach to leverage their investment i. The web site, but I will
object that: 1\. Html5 is the only choice for the web in the computers, which
are not mobile devices, but it's a poor choice for all mobile devices that
have a native development environment 2\. The effor they did in fixing all
webview issues could have been moved to do a better API for native apps. And
yes, if you compare their app to Flipboard you notice the difference.

------
crazygringo
Very interesting to see how just a _single_ sync file call can _destroy_
performance.

It makes perfect sense in hindsight, even though at the time it could be easy
to think, "how much could this really hurt?"

~~~
fatjonny
"Our initial logging implementation accidentally included a synchronous call
to write to disc."

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.

------
karterk
It's interesting to note that while Twitter has moved away from client side
rendering of HTML templates (and is a strong advocate of sending HTML directly
down the wire[1]), LinkedIn mobile app seems to be rendering the template on
the client.

[1]: [http://engineering.twitter.com/2012/05/improving-
performance...](http://engineering.twitter.com/2012/05/improving-performance-
on-twittercom.html)

~~~
chime
Just because client-side rendering did not work well for Twitter for a variety
of reasons, does not mean it is subpar to server-side rendering in all cases.
Performance-wise, if server_json_generate + json_download +
client_render_json_to_html < server_html_generate + html_download +
client_render_html, you can certainly go with client-side rendering.

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.

~~~
jameswyse
What about SEO? I've noticed a lot of these sites that are rendered client-
side start with very little content in the HTML, doesn't this mean the search
engines can't read the content?

~~~
cynwoody
According to this other LinkIn blog post,
[http://engineering.linkedin.com/frontend/leaving-jsps-
dust-m...](http://engineering.linkedin.com/frontend/leaving-jsps-dust-moving-
linkedin-dustjs-client-side-templates) (look for SEO in the comments), they
detect cases where the client can't or won't do JS and perform the rendering
server-side.

~~~
Marwy
How do they do that? I can't really figure out anything apart checking user
agent (for web crawlers?)

~~~
heroic
you can simply check for the accepts header.

------
grannyg00se
"Don't use Node.js for static assets"

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.

~~~
wmf
Express supports sendfile(), so it should be about as efficient as any other
Web server. I wonder if anybody has benchmarked it.

~~~
willvarfar
I'm curious, is that an _asynchronous_ sendfile?

~~~
mhansen
Yes.

~~~
willvarfar
as in spinning off a thread to serve it?

------
raja
I would love more insight or experiences on going stateless/ session free. Are
you explicitly signing every request that requires authentication for security
purposes?

------
heroic
Another tip for people using express is to not use middleware that is not
needed in every request. You can specify special middleware for every path. So
you can even split session usage only on pages that need it. Similarily,
cookie parsing, etc can be avoided where not needed.

------
halayli
I was expecting they went the extra mile and implemented aio in node. Nothing
is out of the ordinary here.

~~~
chime
I found their use of Steps interesting. The syntax seems a bit unconventional
but helps avoid nested callbacks.

~~~
pooriaazimi
Be sure to check out IcedCoffeeScript (if you use CoffeeScript) or TameJS as
well. You might find them useful.

------
mitchi
I was tempted to make a joke about LinkedIn and their passwords but this
article is nice.

------
jjm
Careful with one of the tips... Not everything should be speed focused...

------
bluestix
Why would a company that uses Java even consider Node.js?

Java is hands down faster.

I have never seen a benchmark that showed Node coming even close to Java
performance.

<http://www.youtube.com/watch?v=bzkRVzciAZg>

~~~
Ygg2
It's funny, but I find it ironic you are using that video opposite to what it
is intended. Saying "Java is hands down faster" without proof isn't any
different than saying "Node.js will run circles around Java" without any
proof.

~~~
bluestix
<https://github.com/jbrisbin/node-vs-java-shootout>

[http://vertxproject.wordpress.com/2012/05/09/vert-x-vs-
node-...](http://vertxproject.wordpress.com/2012/05/09/vert-x-vs-node-js-
simple-http-benchmarks/)

<http://www.olympum.com/java/quick-benchmark-java-nodejs/>

[http://stackoverflow.com/questions/6645796/node-js-
performan...](http://stackoverflow.com/questions/6645796/node-js-performance-
with-zeromq-vs-python-vs-java)

