How to Improve Node .js performance

[Amit Roman]

I am using Node JS for communication through socket and http to many client.

Many number of client is connected to my node js. 

My Node js sending data coming from hardware to connected client.

I want to improve the performance of Node js.

Please guide me.

[Patrick Hastings]

What exactly is the media you are sending to the client?
For example, is it:

• HTML pages
  
• Video content
• picture content
• music
• other (explain)
  

It also might help to know where the data is coming from; are you querying a MySQL or RDBMS database? Or again are these just flat web pages you are serving up?

[lawrence...@gmail.com]

I asked a related question but got no response:

https://groups.google.com/forum/#!topic/nodejs/03jxmdnctPw

In my case I was focused on the error case. 

Here is one thing that helps: 

proxy_read_timeout 

proxy_connect_timeout

See here:

https://serverfault.com/questions/287102/nginx-proxy-read-timeout-vs-proxy-connect-timeout

I'm trying to figure out what can postpone the moment when NodeJS fails completely. 

This doesn't increase the performance of the NodeJS app if you measure performance internally to the app. But it does increase the practical performance of the app, if you measure from the outside. That is, we can forestall the moment when NodeJS dies completely.

One thing I've noticed, which is very worrying, is that once a NodeJS app runs out of memory it can take many minutes before it actually dies. 

I have NodeJS running under the control of the daemon Supervisord, with this setup for restarts:

[program:dupe_res_v7]

command=/usr/local/bin/node   --max_old_space_size=6000   /home/ec2-user/daemons/deduplication_api/v7/dupe-res/server.js

autostart=true

autorestart=true

startretries=100

numprocs=1

stderr_logfile=/var/log/dupe_res_stderr_v7.log

stdout_logfile=/var/log/dupe_res_stdout_v7.log

stdout_logfile_maxbytes=50MB

stderr_logfile_maxbytes=50MB

At some users (my fellow co-workers) wrote to me and said "Hey, the API is non-responsive." I looked into. The app would run out of money and freeze, sometimes for as long as 30 minutes, before it would die and be restarted by Supervisord. 

I've learned that aggressive health checks are necessary to kill the app sooner, so that Supervisord can restart it sooner. 

---- lawrence

[lawrence...@gmail.com]

I occasionally see things like this in the log, but this simply kills the app. This does not return nicely formatted JSON, which just happens to lack the right data. 

It does, however, stall, for a very long time, sometimes 20 or 30 minutes. 

<--- Last few GCs --->

  856870 ms: Mark-sweep 5647.1 (6029.8) -> 5625.8 (6029.8) MB, 10733.9 / 0.0 ms [allocation failure] [GC in old space requested].

  867774 ms: Mark-sweep 5625.8 (6029.8) -> 5625.8 (6030.8) MB, 10903.4 / 0.0 ms [allocation failure] [GC in old space requested].

  878580 ms: Mark-sweep 5625.8 (6030.8) -> 5625.8 (5996.8) MB, 10806.3 / 0.0 ms [last resort gc].

  889353 ms: Mark-sweep 5625.8 (5996.8) -> 5625.8 (5996.8) MB, 10773.0 / 0.0 ms [last resort gc].

<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0x1b2594dcfb51 <JS Object>

    1: DoJoin(aka DoJoin) [native array.js:~129] [pc=0x432db260a69] (this=0x1b2594d04381 <undefined>,w=0x19cc4da897b9 <JS Array[68277]>,x=68277,N=0x1b2594d043c1 <true>,J=0x231615ef899 <String[4]\: ,\n  >,I=0x1b2594db46e1 <JS Function ConvertToString (SharedFunctionInfo 0x1b2594d52dc9)>)

    2: Join(aka Join) [native array.js:180] [pc=0x432db381812] (this=0x1b2594d04381 <undefined>,w=0x19cc4da89...

    

    

    

    

On Tuesday, April 18, 2017 at 8:42:15 PM UTC-4, Patrick Hastings wrote:

[Zlatko]

On Sunday, May 7, 2017 at 12:32:08 AM UTC+2, lawrence...@gmail.com wrote:

I occasionally see things like this in the log, but this simply kills the app. This does not return nicely formatted JSON, which just happens to lack the right data. 

It does, however, stall, for a very long time, sometimes 20 or 30 minutes. 

[...]

This part looks like a simple case of a memory leak. Your code (or some library you use) is creating objects, but not releasing them, and at a certain point it time, your process is out of memory. 

That is relatively simple to debug. Install the heapdump module (https://www.npmjs.com/package/heapdump or something similar), and then dump the memory maybe once each hour. Something like this in your main script.

const heapdump = require('heapdump');

setTimeout(function() {

  heapdump.writeSnapshot(`/tmp/${process.env.pid}${Date.now()}.heapsnapshot`);

}, 60 * 60 * 1000);

// ... the rest of your code.

Then load up the dumps into Chrome's Javascript console (Dev Console -> Profiles) and see what kind of objects are you accumulating or not releasing).

(Make sure you have enough disk space for all the heap dumps. Also, depending how often your app gets stuck, you can dump more or less frequently, this is just a basic example.)

On the other hand, it might not be the memory leak, maybe your app is specific and simply needs more memory to function properly under load. But I'd bet on the mem leak.