Node.js中性能指標的示例分析

小編給大家分享一下Node.js中性能指標的示例分析，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

對于我們前端工程師來說，掌握Node.js應用開發是我們走上資深/專家的一條必經之路。此外Node.js是一門服務端語言，我們不僅要能夠完成開發任務，而且更應該要關注服務器性能。

應用場景

在介紹NodeJS性能指標之前呢，我們先來看看它的應用場景，針對不同的應用場景，所要關注的性能指標是有所不同的。

• BFF中間層，接口的代理，充當網關層

• 開發構建工具gulp，webpack基于Node.js

• 桌面應用程序Electron和Node.js結合

• SSR服務端渲染

Node.js如果是用于前端SSR的話，那么CPU和網絡就會成為主要的性能瓶頸；

如果使用NodeJS來進行數據持久化相關的工作，那么I/O和磁盤會有很高的占用率;

而在大多數場景下，CPU、內存以及網絡可以說是Node的主要性能瓶頸。

優缺點

• node.js容錯，性能不是很好

• node.js操作數據庫不專業

• node.js處理異步io強

• io密集型，不適合cpu密集型

事件循環（libuv）

這里引用官網的一張圖，展示了事件循環操作順序的簡化概覽

階段描述

• 定時器：本階段執行已經被 setTimeout() 和 setInterval() 的調度回調函數。

• 待定回調：執行延遲到下一個循環迭代的 I/O 回調。

• idle, prepare：僅系統內部使用。

• 輪詢：檢索新的 I/O 事件;執行與 I/O 相關的回調（幾乎所有情況下，除了關閉的回調函數，那些由計時器和 setImmediate() 調度的之外），其余情況 node 將在適當的時候在此阻塞。

• 檢測：setImmediate() 回調函數在這里執行。

• 關閉的回調函數：一些關閉的回調函數，如：socket.on('close', ...)

V8 GC機制

我們知道Node.js? 是一個基于 Chrome V8 引擎 的 JavaScript 運行時環境，同時它又是單線程的。

其中 V8內存 分為新生代和老生代 :

新生代：采用from空間->to空間內存回收scavenge算法

老生代：采用引用標記、碎片整理的形式進行內存回收

如果GC時間過長，會導致js線程阻塞，影響服務性能。內存使用不當，則會造成內存溢出。了解了以上Node.js的基礎知識之后，我們再來看性能指標

性能指標

我們從系統層面和Node.js進程層面進行一個性能指標描述

系統層面

針對服務器（物理機、虛擬機、Docker 等）級別，提供如下監控指標：

• 內存使用

• CPU 使用率

• 系統負載，使用中進程/等待進行的進程數

• 系統 QPS

• 硬性性能指標

• 磁盤使用率

• GC 統計

• ……

進程層面

針對每個 Node.js 進程，提供如下監控指標：

• 堆內（total 和 used）和堆外內存統計

• 堆內各個內存空間占用內存統計

• 垃圾回收（GC）占整個進程運行時間比例

• QPS

• 按 1s、15s、30s、60s 的 CPU 統計

• libuv 句柄，定時器統計

• ……

如何獲取

針對上面講到的性能指標，我們該如何獲取呢？

系統層面

系統層面的指標可以通過以下兩種方式獲取

1、os模塊

const os = requie('os')

代碼示例

執行結果

2、top和iostat命令查看內存和硬盤使用

top [參數]

iostat[參數]

內存使用情況

//該方法返回 Node.js 進程的內存使用情況的對象
process.memoryUsage()

代碼示例

執行結果：

{
  rss: 4935680,
  heapTotal: 1826816,
  heapUsed: 650472,
  external: 49879
}復制代碼

名詞解釋：

rss 是駐留集大小, 是給這個進程分配了多少物理內存（占總分配內存的一部分）

一般這個指標上升，可能會發生內存泄漏

heapTotal 和 heapUsed 代表 V8 的內存使用情況。

external 代表 V8 管理的，綁定到 Javascript 的 C++ 對象的內存使用情況。

CPU profile

一般來說，如果涉及到內存泄漏的，可以抓取 堆快照，那如果是 CPU 異常飆高的，可以抓取 CPU Profile

可通過以下兩種方式進行獲取：

GC trace

V8提供了很多node.js程序啟動的參數選項，通過以下實例代碼的方式可以獲取到GC日志的信息

node --trace_gc的執行結果

可以看到V8對于新老內存采用不同的GC過程

內存快照

如果使用 node-inspector 的話，快照中會有前端的變量干擾。推薦使用 heapdump 用來保存內存快照，使用 devtool 來查看內存快照。使用 heapdump 保存內存快照時，只會有 Node.js 環境中的對象，不會受到干擾。后面會介紹heapdump的使用

壓力測試

項目上線前是要進行壓力測試的，通過壓力測試來尋找是否存在內存泄漏

壓測工具：ab測試(ApacheBench）、autocannon

下面展示了使用ab功能進行壓力測試的結果

上述運行結果可以看到

我們的一個QPS：4301.28/sec

每個請求的平均時長：23ms

傳輸率：617.47kb/s

內存泄漏

Node.js相對比較專業的后端語言Java、PHP等，一些基礎的建設相對是不夠完善的。加上單線程的特點，在大型的應用當中，很容易引起服務器或者Node.js進程的性能瓶頸。

引起node內存泄漏通常有以下三種情況：

• node v8本身內存大小的限制：64 位系統約為 1.4GB，32 位系統約為 0.7GB。

• 程序使用不當：全局變量引用、閉包使用不當、事件監聽未銷毀

• 大文件應用：應該使用buffer操作，buffer不占用v8內存

那如何去排查內存泄漏呢？可以通過以下工具使用

工具使用

一. heapdump：生成內存快照 + chrome面板分析

需要注意的是，打印內存快照是很耗 CPU 的操作，可能會對線上業務造成影響。

引入

const heapdump = require('heapdump')

獲取

方式一：命令 kill -USR2 <pid>

方式二：調用writeSnapshot

heapdump.writeSnapshot('./' + Date.now() + '.heapsnapshot');

chrome面板分析

二. alinode

阿里云也提供了Nodejs應用的性能平臺alinode，可以很方便、全面的為我們收集性能指標數據，同時以可視化圖表的方式，更加的直觀。接入alinode可參考5分鐘快速入門

以下是部分采集數據圖表展示

一些指標描述

Memory

• memory_sys：系統內存使用百分比。

• memory_node： 所有 Node.js 進程內存使用之和占系統內存的百分比。

CPU

• cpu_sys：系統 CPU 使用百分比。

• cpu_node：所有 Node.js 進程 CPU 使用百分比之和。

Load

• load1：1分鐘內平均 Load。

• load5：5分鐘內平均 Load。

• load15：15分鐘內平均 Load。

• 下面是一些 Load 的參考信息 (Load 已經歸一化處理，如果是 N 核 CPU，那么相應 Load * N)：

• 0.7 < Load < 1：不錯的狀態，有新任務也可以及時處理；

• Load = 1：即將有任務需要額外的等待時間才能被處理，需要引起關注；

• Load > 5：任務需要等待時間很長，需要干預處理。

• 通常先看 load15，如果很高，再看 load1 和 load5，看是否有下降趨勢，短時間內 load1 大于 1，不用擔心，如果長時間 Load 較高，需要引起關注。

QPS

該實例所有 Node.js 進程每秒鐘處理的 HTTP 請求數之和。

GC

• gc_avg：所有 Node.js 進程垃圾回收時間占比平均值。

• gc_max：每分鐘內垃圾回收時間最多的 Node.js 進程的垃圾回收時間占比。

三. 開源Easy-Monitor

企業級 Node.js 應用性能監控與線上故障定位解決方案。

Easy-Monitor是一款輕量級的Node性能監控工具。快速入口

我們也可以給予它的基礎之上去搭建部署一套自己內部的性能平臺。

以上是“Node.js中性能指標的示例分析”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！