An engineer with LinkedIn has published 10 tips for fast mobile application performance using Node.js on the server.
1. Avoid synchronous code
Node.js was designed to favor asynchronous code. Go with the callback, Luke. If you want to tame your asynchronous code (callbacks can become rather circuitous) use modules like async.
2. Turn off socket pooling
?
3. Don't use Node.js for static assets
Your application probably includes some .js or .css or .jpg files that are meant to be sent to the browser. It's tempting to send those assets using the same Node.js code that's driving the application. But that's inefficient. It's better to use a CDN or other technique to send those assets.
4. Render on the client side
Here's where I somewhat diverge from the recommendations. This recommendation is to send a page that includes javascript code that turns around to request data and lazily construct the page - on the browser. What this means is the browser then has to make a zillion small requests to the server, and adds computational load to the browser's JavaScript engine.
I happen to think it's best to gather the full page content on the server, sending that to the browser, and use in-browser javascript for refinements.
5. Use gzip
This is the standard thing - to compress stuff you send the browser and decompress it in the browser. The way this benefits us is that the payload transmitted over the Internet is smaller, at the cost of more CPU consumed in compressing and uncompressing.
6. Go parallel
This is kind of the opposite of the "Render on the Client Side" recommendation. In any case the idea here is to parallelize gathering of the data on the server side.
7. Go session-free
Apparently the Express framework has bad performance with storing sessions. Their suggestion is to store no server-side state. But they don't recommend what to do with making stateful sessions for users. Do they recommend storing all session data in cookies? If so, that would mean each HTTP request is much larger because of excess data in the cookies that could be stored on the server.
8. Use binary modules
The V8 JavaScript engine is fast, but I suppose it's not as fast as native code modules? They're recommending that some modules can give you a performance boost when you code them with C/C++ but of course native code module development has to be made easier to perform.
9. Use V8 JavaScript rather than client side libraries
There may be a tendency to use familiar client side libraries from the browser on the server. But those libraries have an overhead unnecessary on Node, because the client side javascript implementations vary so much the libraries have to be coded to accommodate those differences. That's an overhead and it's better to just avoid that overhead by avoiding those libraries.
10. Keep your code small and light
I suppose here they're looking at the memory footprint of excess modules.
Blazing fast node.js: 10 performance tips from LinkedIn Mobile
1. Avoid synchronous code
Node.js was designed to favor asynchronous code. Go with the callback, Luke. If you want to tame your asynchronous code (callbacks can become rather circuitous) use modules like async.
2. Turn off socket pooling
?
3. Don't use Node.js for static assets
Your application probably includes some .js or .css or .jpg files that are meant to be sent to the browser. It's tempting to send those assets using the same Node.js code that's driving the application. But that's inefficient. It's better to use a CDN or other technique to send those assets.
4. Render on the client side
Here's where I somewhat diverge from the recommendations. This recommendation is to send a page that includes javascript code that turns around to request data and lazily construct the page - on the browser. What this means is the browser then has to make a zillion small requests to the server, and adds computational load to the browser's JavaScript engine.
I happen to think it's best to gather the full page content on the server, sending that to the browser, and use in-browser javascript for refinements.
5. Use gzip
This is the standard thing - to compress stuff you send the browser and decompress it in the browser. The way this benefits us is that the payload transmitted over the Internet is smaller, at the cost of more CPU consumed in compressing and uncompressing.
6. Go parallel
This is kind of the opposite of the "Render on the Client Side" recommendation. In any case the idea here is to parallelize gathering of the data on the server side.
7. Go session-free
Apparently the Express framework has bad performance with storing sessions. Their suggestion is to store no server-side state. But they don't recommend what to do with making stateful sessions for users. Do they recommend storing all session data in cookies? If so, that would mean each HTTP request is much larger because of excess data in the cookies that could be stored on the server.
8. Use binary modules
The V8 JavaScript engine is fast, but I suppose it's not as fast as native code modules? They're recommending that some modules can give you a performance boost when you code them with C/C++ but of course native code module development has to be made easier to perform.
9. Use V8 JavaScript rather than client side libraries
There may be a tendency to use familiar client side libraries from the browser on the server. But those libraries have an overhead unnecessary on Node, because the client side javascript implementations vary so much the libraries have to be coded to accommodate those differences. That's an overhead and it's better to just avoid that overhead by avoiding those libraries.
10. Keep your code small and light
I suppose here they're looking at the memory footprint of excess modules.
Blazing fast node.js: 10 performance tips from LinkedIn Mobile