NodeJS 性能优化之 CPU 看图篇

原创

web爱好者

修改于 2017-09-07 09:43:58

7.6K3

修改于 2017-09-07 09:43:58

服务稳定性到一定程度之后，都会开始经历一段精细化运营的过程，从成本意识角度来说也是成立的。作为前端出身的NodeJS开发者们，产生共鸣的那就是如何能够直观且快速发现性能瓶颈，能够像调试前端的JS代码那样可视化，堆栈化，接下来我们就针对常见的CPU性能分析方法来揭开NodeJS的CPU面纱。

充分利用劳动工具有助于帮助我们提升定位问题的效率，Linux kernal自带的系统性能分析工具perf，为我们提供函数级与指令级的热点查找，常用于性能瓶颈的查找与热点代码定位。

#NodeJS如何正确完整的采集火焰图呢？

1-1、用例构造

NodeJS服务代码示例—JSON编解码，如下片段：

1-2 启动方式：

启动参数：--perf_basic_prof或—perf-basic-prof适用于node@0.11.13

也可以使用--perf_basic_prof_only_functions

标准方式：node --perf_basic_prof JsonParse.js

MIG tafNodeJS启动方式：私有模板配置启动参数，如下：


<taf>

<application>

    <server>

        node-args=--perf-basic-prof

</server>

</application>

</taf>

注：--perf_basic_prof或--perf-basic-prof会对应生成一个/tmp/perf-pid.map文件，如图：

1-3 perf脚本采集函数和热点代码

#查看NodeJS服务进程pid，采集时需要用到。命令：$ ps –ef | grep ‘worker’

#采集脚本：$ perf record -F 99 -p 182497 -g -- sleep 60

参数说明如下：

采集频率(ms)	进程pid	调用记录	记录时长
-F 99	-p 182497	-g	--sleep 60

#进程对应的符号表perf-pid.map权限设置：$chown root /tmp/perf-pid.map。

踩过的坑！！！是为了消除下面这个问题的

File /tmp/perf-PID.map not owned by current user or root, ignoring it (use -f to override).

Failed to open /tmp/perf-PID.map, continuing without symbols

http://github.com/brendangregg/FlameGraph

单一颜色：$ perf script | ./stackcollapse-perf.pl | ./flamegraph.pl > xxx.svg

多种颜色：perf script | ./stackcollapse-perf.pl | ./flamegraph.pl --color=js –hash > xxx.svg，如下图：

2.1 通过上面的步骤采集出两种不同颜色系的火焰图，如下图

2.2 火焰图颜色对应关系，如下表：

2.3 火焰图形状对应关系

形状	含义
每一个平面方块	一个函数在栈中的位置（也称一个栈帧）
Y轴	栈的深度(也叫栈的帧数)
X轴	表示总的样例，不过它们左右顺序没有特殊含义
每个平面方块的宽度	方块的宽度标示CPU使用时间或者说相对父函数而言使用CPU的比率，越宽代表占用CPU的时间越长，或者使用CPU很频繁

2.4 JSON序列化与反序列化火焰图分析

采用ab进行压力测试分析JSON.parse与JSON.stringify性能开销

压测命令：ab –n 3000000 -c 50 http://ip:port/jsonParse

从火焰图看到JsonParse.js里面耗时主要消耗在JSON序列化和反序列化

几个常见的栈帧类型说明：

栈帧	含义
LazyCompile	指的是下回会被编译
Builtin	指的是C++内置的运算方法
Stub	C入口桩代码：作用是在js的JIT代码中，如果要调用Runtime的函数，则通过CEntryStub实现
V8::internal	内部命名空间，就是C++的namespace，在V8的源代码可以找到对应的namespace