# 1. 定位cpu瓶頸程式碼

定位nodejs cpu 效能瓶頸，有好多方法。目的都是為了拿到個火焰圖，我試了個遍做個小總結

關於火焰圖： [如何讀懂火焰圖？- 阮一峰](http://www.ruanyifeng.com/blog/2017/09/flame-graph.html)， 我的經驗就是檢查火焰圖的大平層，即那些高耗時的函式。**Nodejs 是對密集型函式是否敏感的語言，因為cpu密集型計算會阻塞事件迴圈, 致命的影響QPS，解決幹掉那些高cpu 耗時的密集型函式對QPS的提升至關重要**
## 1.1  v8-profiler

裂牆推薦： https://www.speedscope.app/

```
// 這裡使用@hyj1991 base v8-profile(官方不再維護) const profiler = require('v8-profiler-node8'); 
const fs = require('fs');
const profileTime = 60 * 000 const delay = 30 * 000  setTimeout(function () {
    console.log('start profile');
    profiler.startProfiling('CPU profile');
    setTimeout(function () {
      const profile = profiler.stopProfiling();
      console.log('end profile');
      profile.export()
        .pipe(fs.createWriteStream(`cpuprofile-${Date.now()}.cpuprofile`))
        .on('finish', () => profile.delete())
    }, profileTime)
  }, delay)
  
// 壓測 // ab -t 300 -c 10 "http://localhost:8030/golden/stat?xxxx" // 當前路徑下生成 cpuprofile-1578464113338-v8.cpuprofile
```

當前路徑下生成 cpuprofile-1578464113338-v8.cpuprofile， 那麼如何分析呢？

**使用 Chrome DevTools**

開啟Chrome -> 開啟開發者工具 -> 點選右上角三個點按鈕 -> More tools -> JavaScript Profiler -> Load，載入剛生成的 cpuprofile 檔案
![img](http://img-hxy021.didistatic.com/static/km/do1_luJBX7UFh4Kms1tZVkQy)

![img](http://img-hxy021.didistatic.com/static/km/do1_gFAqkiEZvvcjrWZG5fSv)

**使用Speedscope**： https://www.speedscope.app/
- 開啟網站Speedscope，載入剛生成的 cpuprofile 檔案
- 它支援Chrome DevTools 裡的 按時間線顯示、按比重上到下排序顯示
- 它支援Left Heavy 統計所有時間線，將佔比重的放左側，且仍然保留火焰圖的分析能力，簡直太棒了
  ![img](http://img-hxy021.didistatic.com/static/km/do1_X4tlTes1wZPvTPJrEALe)

透過這張圖，我們很快很方便知道了我們服務裡業務邏輯耗時的部分

- **8% CPU 花在了這個函式**，lib/golden.js  每個請求使用了  [ua-device](https://www.npmjs.com/package/ua-device)這個模組, 來根據 req.headers['user-agent'] 獲取移動裝置的各種型號,  裡面6000多行，各種正則匹配、提取。以下程式碼佔比了整個服務 8% 的耗時

```
const UA = require('ua-device')
// origin 端上報的裝置型號 var uaObj = new UA(req.headers['user-agent'])
var os_type = origin.ot || uaObj.os.name var os_version = origin.ov || uaObj.os.version
```

因為99.9%的流量端上報都會帶上該裝置的型號和版本，故這 8%cpu 密集型計算6000行程式碼是不必要的。

即使端上不上報，我們後臺統計裝置需要如此詳細多樣的裝置數不? 如果不必要我們可以自己寫個幾十行程式碼統計下業務主流關係的裝置和版本代替這個庫,  **做如下修改即可**

```
const UA = require('ua-device')
if (!origin.ot || !origin.ov) { // 絕大大大部分流量不需要這 8% cpu的密集型計算    var uaObj = new UA(req.headers['user-agent'])
}
var os_type = origin.ot || uaObj.os.name var os_version = origin.ov || uaObj.os.version
```

- **4% CPU 花在了這個函式** ，lib/golden.js
```
var timer = new Date()
var sendData = {
 logtime: +timer,
 jsonMsg: {
    // formatDate 這個公用函式中使用了正則來支援個性化formate yyyy-MM-dd hh:mm:ss     server_time: utils.formatDate(timer) 
 }
}
```

我們在看看背後的查詢這個server_time 有用麼？ 如下圖可見本身logtime 這個欄位根據規範背後會自動被formate成期望格式，故server_time欄位可移除，

![img](http://img-hxy021.didistatic.com/static/km/do1_i6vX1nfNhi2bDYS9YGdI)

另外一個問題，我們自己的 utils.formatDate耗時正常麼，有最佳化空間不?  是不是都這麼慢？然後拿官方[dateformat](https://www.npmjs.com/package/dateformat) 簡單寫了個效能測試，對比了下

```
# debug 跑 dateformat 10000 count spend 108 ms
utils.formatDate 10000 count spend 879 ms

# 非degbug 跑 dateformat 10000 count spend 116 ms
utils.formatDate 10000 count spend 62 ms
```

不知道為啥 不同跑的方式有這麼大差距，相關邏輯裡沒有任何日誌等區別除錯環境的內容，難道用到的原生函式底層有debug的區別，待進一步探索

## 1.2  perf

nodejs官方中文文件： https://nodejs.org/zh-cn/docs/guides/diagnostics-flamegraph/

```
# node app.js # 執行 ab 壓測 請求服務 # ps -ef  找出 node pid , 特別是cluster 執行，找到其中一個worker perf record -F 99 -p <pid> -g -- sleep 30 # 上面輸出 perf.data  處理輸出perfs.out perf script > perfs.out
npm i -g stackvis
stackvis perf < perfs.out > flamegraph.htm
# 輸出火焰圖 flamegraph.html
```
問題

- perf 是linux 上工具，本地mac 無法使用，需要登入測試環境，預發環境
- 生成火焰圖在預發環境，無法下載訪問，npm i puer -g ,  工程路徑執行puer 啟動靜態服務來訪問預發環境的火焰圖
- 在生成的火焰圖，由於數量太大，函式文字各種重疊無法正常檢視，故此路就探索到此

## 1.3 使用 Node.js 內建的探查器

nodejs官方中文文件： https://nodejs.org/zh-cn/docs/guides/simple-profiling/
```
# 啟動服務 NODE_ENV=production node --prof app.js
# 對服務熱處理 curl -X GET "http://localhost:8080/newUser?username=matt&password=password" # 進行壓測 ab -k -c 20 -n 250 "http://localhost:8080/auth?username=matt&password=password" # -k Use HTTP KeepAlive feature # -c Number of multiple requests to make at a time 併發數 # -n Number of requests to perform 總請求數 # -t 總壓測時間 秒 # 你能獲得當前服務，在當前環境的一個qps量 # 上面在當前目錄路徑下，產生了刻度檔案xxx-v8.log # 透過nodejs 自帶的處理檔案進行轉換統計為可閱讀檔案 node --prof-process isolate-0xnnnnnnnnnnnn-v8.log > processed.txt
```

```
 [Summary]:
   ticks  total  nonlib   name
     25 6.1%    6.2%  JavaScript
    341 83.6%   84.6%  C++      14 3.4%    3.5%  GC
      5 1.2%          Shared libraries
     37 9.1%          Unaccounted
 [JavaScript]:
   ticks  total  nonlib   name
      2 0.5%    0.5%  Function: ~fs.readFileSync fs.js:548:27
      ...
```

問題

- 分析結果是文字，不利於觀看排查，解決：https://github.com/mapbox/flamebearer

```
# install flamebearer (Node v8.5+ required) $ npm install -g flamebearer
# profile your app $ node --prof app.js
# generate flamegraph.html from a V8 log and open it in the browser $ node --prof-process --preprocess -j isolate*.log | flamebearer
# 立馬生成了火焰圖
```

- 分析結果檔案裡一眼望過去沒有什麼業務程式碼函式，更多的是c++、原生js函式，不好定位問題
- 如何控制時間，貌似node --prof-process 啟動後就已經開始 對node程式碼進行分析了，這個時候壓測未開始
- 如何指定分析特定程式pid，對應egg預設cluster 啟動，分析的應該是不幹業務邏輯的主程式，我們服務是基於egg 封裝的框架degg實現的，故此路就探索到此

## 1.4 Alinode

[alinode官方文件](https://help.aliyun.com/document_detail/60338.html?spm=a2c4g.11174283.3.1.540430b1C052mY)

- 建立  App ID 和 App Secret

```
# 安裝版本管理工具 tnvm，安裝過程出錯參考：https://github.com/aliyun-node/tnvm wget -O- https://raw.githubusercontent.com/aliyun-node/tnvm/master/install.sh | bash source ~/.bashrc
# tnvm ls-remote alinode 檢視需要的版本 tnvm install alinode-v3.11.4 # 安裝需要的版本 tnvm use alinode-v3.11.4 # 使用需要的版本 npm install @alicloud/agenthub -g # 安裝 agenthub
```

- 本地啟動agenthub

```
// aliconfig.json
{
  "appid": "xxxx",                         
  "secret": "xxxx" }
agenthub start aliconfig.json
```

- 本地啟動服務

```
ENABLE_NODE_LOG=YES node demo.js  #環境變數必要 # 進行 ab 壓測
```

![img](http://img-hxy021.didistatic.com/static/km/do1_RRj5TvhiJPmdnNSxGSh9)

問題

- 依賴alinode
- 後臺分析不開源，資料需要上報
- 其他功能全面

## 1.5  NodeX 效能分析平臺 （對內）

我們NodeX FT在公司內部搭建的Nodejs效能分析平臺  http://nodex.xiaojukeji.com/monitor

接入文件： http://xingyun.xiaojukeji.com/docs/nodex#/_service_monitorserver?id=app註冊列表

![img](http://img-hxy021.didistatic.com/static/km/do1_QWJXT3glmBi1wDkbrvTZ)

## 作者：陳欽輝【 滴滴出行資深軟體開發工程師】

- [	現在註冊滴滴雲，得8888元立減紅包](https://app.didiyun.com/#/auth/signup?channel=14816)
- [7月特惠，1C2G1M雲伺服器 9.9元/月限時搶](https://www.didiyun.com/?channel=14816)
- [滴滴雲使者專屬特惠，包年雲伺服器低至68元/年](https://www.didiyun.com/envoy/e-index.html?channel=14816)</pid>

記-Nodejs埋點服務-定位cpu瓶頸

相關文章