Node.js Event Loop 處理的幾大週期如下圖所示：

• Timer：通過 setTimeout() 或 setInterval() 安排的一切都將在這裡處理。

• IO 回撥：這裡將處理大部分回撥。 由於 Node.js 中的所有使用者態程式碼基本上都在回撥中（例如，對傳入 http 請求的回撥會觸發級聯回撥），這就是使用者態程式碼。

• IO輪詢：輪詢下一次執行要處理的新事件。

• Set Immediate：執行通過 setImmediate() 註冊的所有回撥。

• close：這裡處理了所有 on('close') 事件回撥。

實際上 Node 應用程式中發生的一切都通過事件迴圈執行。這意味著，如果我們可以從中獲取指標，它們應該會為我們提供有關應用程式整體健康狀況和效能的寶貴資訊。

如果應用程式處於空閒狀態，這意味著沒有待處理的任務（定時器、回撥等），全速執行這些階段是沒有意義的，因此事件迴圈將適應這種情況並在 等待新的外部事件進入的輪詢階段。

這也意味著，無負載下的指標與高負載下與慢速後端通訊的應用程式相似（低頻率、高持續時間）。

Event Loop Latency

事件迴圈延遲衡量在使用 setTimeout(X) 安排的任務真正得到處理之前還需要多長時間。

高事件迴圈延遲表示事件迴圈忙於處理回撥。

Node.js 應用程式在單個執行緒上執行。 在多核機器上，這意味著負載不會分佈在所有核心上。 使用 Node 附帶的叢集模組，可以很容易地為每個 CPU 生成一個子程序。 每個子程序維護自己的事件迴圈，主程序透明地在所有子程序之間分配負載。

如前所述，libuv 將建立一個大小為 4 的執行緒池。可以通過設定環境變數 UV_THREADPOOL_SIZE 來覆蓋池的預設大小。
雖然這可以解決 I/O 密集型應用程式的負載問題，但在生產系統上進行這項改動之前，務必進行負載測試，因為更大的執行緒池可能仍會耗盡記憶體或 CPU.