Code debugging and performance tuning for Nodejs

NodeJS since 2009 revealed the world, to now has six years, because of various reasons, the middle of the derivation of a brother, called Iojs, the recent brothers continue to fit, derived from the nodejs4.0 version, this thing nodejs new 1.0 is version, the original squad are unified to a front. I did not pay much attention to the development behind the Nodejs, but has been its loyal users, read through the v4.1.2 document, feel from the developer perspective, there is no big change, so this two brothers separated so long, mainly in the bottom of the building module to do the transformation, the superstructure has not changed, concrete can see This article.

If you have been using Nodejs, but has been writing the most basic small demo, rarely in-depth to analyze the performance of Nodejs, and even how to debug code, how to find performance problems do not know where to start, then hurry down to read it!

Command-line debugging

The command line debug Nodejs code, this is the most basic debugging skills, as we debug in Chrome control JS code in general, but it is rarely used, because he is too primitive, looks more troublesome.

In retrospect, our usual debugging methods:

• Enter in a place where you need to enter console.log() , print the debug results
• Introduce the asserts module and debug the debugging area

Both of these debugging methods require us to explicitly embed various debug information into our business logic code, and when we are familiar with command line debugging, we can better start our own debugging journey. NodeJS provides us with the Debugger module, built-in client, through TCP to the command line input to the built-in module to achieve the purpose of debugging.

When you start the file, add a second parameter debug :

?  $ node Debug proxy2.js< Debugger listening on port 5858debug>. Okbreak in proxy2.js:1> 1 var http = require (' http ');  2 var net = require (' net ');  3 var url = require (' URL ');d ebug>

Debugging code when there are two states, one is the location of the operation debugging, such as the next step, enter the function, jump out of the function, such as the debug mode, and the other is to see the value of the variable, such as Enter the loop, want to see the value of the loop counter I, at this time REPL (read-eval-per-line) state, input in debug mode to repl enter REPL state:

debug> replpress Ctrl + C to leave debug repl> httpprint something about http>

Press to Ctrl+C return to the debug state from the REPL state, we do not need to remember how many debug commands in the debug state, do help:

Debug> Helpcommands:run (R), Cont (c), Next (N), step (s), Out (O), BackTrace (BT), Setbreakpoint (SB), Clearbreakpoin T (CB), watch, Unwatch, watchers, REPL, restart, kill, list, scripts, breakonexception, breakpoints, version

The related commands are not a lot:

Command	explain
Cont, C	Go to the next breakpoint
Next, N	Next
Step, S	Enter function
Out, O	Jump out of functions
Setbreakpoint (), SB ()	Set a breakpoint on the current line
Setbreakpoint (line), SB (line)	Set breakpoints on line lines

The above several are commonly used, and more commands can be poked here.

The debugging principle of Nodejs

We usually use IDE tools, many IDE tools have integrated NodeJS debugging tools, such as Eclipse, Webstorm and so on, their principle is still using the NodeJS Debugger built-in module, on this basis to encapsulate.

The attentive classmate will find that when we open a node file with the debug parameter, we will output this line of copy:

Debugger listening on port 5858

can be accessed under http://localhost:5858 , you will see:

It tells us that Nodejs started the built-in debugging function when the file was opened, and listened to the debug command coming from Port 5858. In addition to debugging directly in the command line, there are two other ways to debug this code:

• node debug <URI>To connect debugging through a URI, such asnode debug localhost:5858
• node debug -p <pid>Debug with PID link

If we open the file with a --debug parameter:

?  $ node--debug proxy2.js

At this point, Nodejs does not enter the command line mode, but instead executes the code directly, but still opens the built-in debugging functionality, which means we have the ability to remotely debug Nodejs code, --debug open the server's Nodejs file with parameters, and then pass:

?  $ node Debug < server ip>:< Debug port, default 5858>

You can debug the Nodejs code locally remotely. However, it is necessary to distinguish between the next --debug and --debug-brk , the former will execute all the code, generally in the event of listening to use, the latter, will not execute the code, you need to wait until the external debugging access, enter the code area. The language is not so vivid that the reader can test it himself.

The default port number is 5858, if the port is occupied, the program will increment the port number, we can also specify the ports:

?  Node  node--debug-brk=8787 proxy2.jsdebugger listening on port 8787

More ways to debug node-inspector

The built-in debugging provided by NodeJS is very powerful, and it tells V8 to interrupt the execution of the code and wait for the developer to manipulate the execution progress of the code. The node-inspector we know is also used in this principle.

?  

Here --web-port is the Chrome Devtools Debug page address port, --debug-port for the NodeJS launch of the built-in debug port, we can open http://localhost:8080/debug?port=5858 the page, debug using --debug(-brk) parameters open program.

More settings can be found in the official documentation.

IDE Debugging

Both the Eclipse and Webstorm toolbars have a selection bar called Run, where you can configure how the file is executed, such as in Webstorm (Navigation>run>edit configurations):

The first step is to add a startup program to the program

If there are no Nodejs options (such as in Phpstorm), you can manually configure the under.

Second step, configure the execution

• Node interpreterIt's the location of your node program.
• Node parametersIs the option to open the Nodejs program, if you use the ES6 feature, you need to start the --harmony mode, if you need a remote debugging program, you can use the --debug command, we use the console debugging, obviously do not need to add --debug parameters.
• Working directoryIs the directory of the file
• Javascript fileis a file that needs to be debugged

Step three, breakpoints, debugging

The debugging of other IDE tools is similar, and the principle is that it is connected to the built-in debug port via TCP to Nodejs.

Problems with the Discovery program

The above describes the NodeJS debugging need to master a few basic skills, mastering is still very easy, but to try it yourself.

Nodejs compared to Java, PHP these old language, the surrounding facilities are still deficient, such as performance analysis and monitoring tools, coupled with its single-threaded operation characteristics, in large-scale applications, it is easy to allow the system CPU or memory bottleneck, resulting in a program crash. How do we drill down to problems with the NodeJS code as soon as the program alerts you that the CPU load is too high or the memory soars?

First to analyze the problem, what are the factors of high memory height:

• Cache, a lot of people in the process of tapping the cache when memory, such as the use of an object to store the user's session information
• Closures, scopes are not released
• Producers and consumers have poor speed, such as the database is not busy, Query queue accumulation

High CPU load warning possible factors:

• Garbage collection frequency is too high, the volume is too large, this is generally due to memory or cache spikes caused by
• Intensive long-cycle calculations, such as large traversal of folders, large numbers of computations, etc.

These problems are the most troubling, a project dozens of hundreds of files, received these alerts if there is no experience, simply do not know how to troubleshoot.

The most straightforward approach is to analyze the GC log, because the program's every move will be fed back to the GC, and the above questions will point to the GC, such as:

• A spike in memory, especially in old Space, can lead to a direct increase in GC frequency and time
• Increased cache, resulting in GC time increase, useless traversal too much
• Intensive calculations, resulting in increased GC now space times

This requires a little bit of NodeJS memory management and a garbage collection mechanism.

V8 memory is divided into the size of New space and old space,new space by default to the size of 8m,old space, which defaults to double the value of the 0.7g,64 bit system.

The life cycle of the object is: first into new space, where new space is divided into two parts, each GC will be a copy of the live object to another, so its space utilization is 50%, this algorithm is called Cheney algorithm, this operation is called scavenge. After a while, if the object in New space is alive, it will be moved to old space, and the GC will traverse the dead object in old space at intervals, then defragment it (there are two modes Mark-sweep and mark-compact, ominously). The above mentioned "dead" refers to the object has not been referenced, alive said that the number of citations is zero.

Knowing this, we are good at analyzing the problem, if the cache increases (such as using the object cache a lot of user information), the GC is not aware that the cache is dead or alive, they will keep looking at this object, and whether the child object in this object is still alive, if the number of objects is particularly large, then the GC The traversal time is also very long. When we are doing intensive calculations, there are a lot of intermediate variables that often die in new space, and the GC will also be doing garbage collection on the new space area several times.

Analyzing GC Logs

Having said so much, how to analyze GC logs?

When you start the program --trace_gc , add parameters, and V8 will print out the garbage collection information when it is garbage collected:

?  $ node--trace_gc aa.js ... [94036]       Ms:scavenge 8.4 (42.5), 8.2 (43.5) MB, 2.4 Ms [allocation failure]. [94036]       Ms:scavenge 8.9 (43.5), 8.9 (46.5) MB, 5.1 ms [allocation failure]. [94036] Increasing marking speed to 3 due to high promotion rate[94036]       ms:scavenge 16.1 (46.5)-15.7 (47.5) MB, 3.8 ms (+ 5.0 MS in 106 steps since last GC) [allocation failure]. [94036]       Ms:scavenge 16.7 (47.5), 16.6 (54.5) MB, 7.2 ms (+ 1.3 MS in + steps since last GC) [allocation failure]. [94036]      111 Ms:mark-sweep 23.6 (54.5), 23.2 (54.5) MB, 6.2 ms (+ 15.3 MS in 222 steps since start of marking, biggest step 0 .3 ms) [GC interrupt] [GC in old space requested] ....

V8 offers a number of program startup options:

Startup Item	meaning
–max-stack-size	Set Stack size
–v8-options	Print V8 related commands
–trace-bailout	Find functions that cannot be optimized, overriding
–trace-deopt	Find functions that cannot be optimized

These startup items allow us to see the various log logs that V8 performs at execution time, which is useful for troubleshooting obscure issues. However, this pile of logs is not very nice, we can send the log output to the professional tools to help us analyze, compared to many people have used Chrome DevTools JavaScript CPU profile, it here:

Profile can be used to find specific functions in the entire program execution time and execution time ratio, so as to analyze the specific code problems, V8 also provides the Profiles log export:

?  $ node--prof test.js

After executing the command, a log file is generated in that directory *-v8.log and we can install a log analysis tool tick:

?  $ sudo npm install tick-g?  $ node-tick-processor *-v8.log[top Down (Heavy) profiles]:  note:callees occupying less than 0.1% is not shown.  Inclusive      self           name  ticks   Total  ticks   total    426   36.7%      0    0.0%  Function: ~<anonymous> node.js:27:10    426   36.7%      0    0.0%    lazycompile: ~startup node. js : 30:19    410   35.3%      0    0.0%      lazycompile: ~module.runmain module.js:499:26    409   35.2%      0    0.0%        lazycompile:module._load module.js:273:24    407   35.1%      0    0%          lazycompile: ~module.load module.js:345:33    406   35.0%      0    0.0%            lazycompile: ~module._ Extensions. JS module.js:476:37    405   34.9%      0    0.0%              lazycompile: ~module._compile module.js:378:37 ...

We can also use tools such as headdump to export logs and then put them in Chrome's profile.

Summary

This article mainly from NodeJS program debugging means, as well as debugging performance of the entrance to do a brief introduction, I hope you have some inspiration, not to the place also please treatise!

Nodejs code debugging and performance tuning