Node.js的幾個“黃金”指標

Node.js應用的監控有一些需要特別注意的地方。該語言的動態特性為開發造成了新的問題，內存泄漏和單一功能阻塞事件隊列，這可能對整體應用 性能產生巨大的影響。并行執行作業使用“集群（cluster）”功能，以便充分利用多核CPU。但主要進程和工作進程屬于一個應用程序，所以我們應該對 它們進行監控。本文中，我們一起深入去了解Node.js應用程序的幾項重要指標，更好地解決和避免可能的問題。

垃圾回收&內存處理

Node.js是基于Google’s Chrome V8的Javascript引擎。垃圾回收可以回收那些不再需要的對象的內存。V8垃圾回收可以停止執行程序。增量GC周期（scavenging）過程 只是堆的一部分，并且非常快。為了盡量減少程序執行中的暫停，執行完整的GC運行較不頻繁。

關于垃圾回收的指標，我們首先應該衡量所花費的時間。此外，還需要看完整GC循環（或增量GC循環）的執行周期。堆內存的大小可以與上次GC運行的大小進行比較，看是否有增多的趨勢。以下是需要監控的指標：

• 垃圾回收的時間消耗
• 計算完整GC周期
• 計算增量GC周期

垃圾回收指標

除了GC發生的頻率，時間，我們還可以通過以下的指標觀察內存的情況：

• GC周期之間釋放內存（見上文）
• 流程堆大小和堆使用

進程內存信息

事件循環– Node.js性能的秘訣是CPU限制并使用異步操作的能力。這樣，我們可以充分利用CPU，不浪費等待I/ O操作的周期。這意味著一臺服務器可以進行多個連接，異步操作不被阻塞。一旦操作完成，使用回調函數來繼續處理。它的實現基于單一事件循環—單獨的線程中 處理異步函數調用。使用同步操作會使性能下降，因為其他操作需要等待執行。這就是為什么，“不堵塞事件循環”是Node.js性能的黃金法則。

• 最慢的事件處理（最大延遲）
• 平均事件循環延遲
• 最快的事件處理（最小延遲）

最慢，平均和最快的事件處理

事件循環的高延遲可能意味著使用阻斷（同步）或程序正在處理事件。這可能會影響整個Node.js應用程序的性能。

集群模式和進程數– 為了使Node.js處理不止一個進程，我們需要使用“集群”模式。主進程共享插槽與叉形工作進程，并可以用它交換消息。有一個網絡服務器派生n個工作流 程的典型用例：在共享的服務器接口中操作，并處理循環的要求。多數情況下，程序選中N個服務器提供的CPU—這就是為什么常規情況下，進程的數量恒定。如 果這個數字產生變化，這意味著工作進行已經終止，或其他的一些原因。當需要處理的進程排隊的時候，要按照需要依次處理。這時候，進程數量隨時都會變化。可 以使用像SPM類似的工具，觀察Node.js的進程數量。Node.js進程的時間很短，傳統的檢測工具可能不夠準確。

進程數量

例如，要在不同的Node.js子過程比較事件循環延遲，我們需要能夠選擇想要的進程進行比較：

每個進程的時間循環延遲

Web框架– 越來越多的人使用Node.js構建Web服務器框架。最流行的是：Express、 Hapi.js、 Restify、 Mean.io、 Meteor，等等。當進行HTTP檢測時，需要注意以下這些關鍵指標：

• 響應時間（HTTP / HTTPS）
• 請求率
• 錯誤率（總數，錯誤種類）
• 請求/響應內容大小

HTTP / HTTPS指標概述

當然，Node.js不會運行在真空中。它們連接到其他服務，其他類型的應用，高速緩存，數據存儲等。因此，Node.js單獨使用或單獨監測不 是明智的做法。在這里，我要給大家一個忠告：你要準備一個足夠大的顯示屏，以便更好的進行檢測。 Node.js 經常是與 Elasticsearch、 Redis等等一起使用。因此，需要將相關的指標一起顯示。如下圖所示：