多個提升Node.js應用吞吐量的小優化技巧介紹

多個提升Node.js應用吞吐量的小優化技巧介紹翻譯自 InfoQ 英文站的 node-micro-optimizations-javascript 一文，從屬於筆者的Web 前端入門與工程實踐。

多個提升Node.js應用吞吐量的小優化技巧介紹

內容提點

• 儘量地使用聚合IO操做，以批量寫的方式來最小化系統調用的次數。

• 須要將發佈的開銷考慮進內，清除應用中不一樣的定時器。

• CPU分析器可以給你提升一些有用信息，可是並不能完整地反饋整個流程。

• 謹慎使用ECMAScript高級語法，特別是你還未使用最新的JavaScript引擎或者相似於Babel這樣的轉換器的時候。

• 要洞察你的依賴樹的組成而且對你使用的依賴進行適當的性能評測

當咱們但願去優化某個包含了IO功能的應用性能時，咱們須要對於應用耗費的CPU週期以及那些妨礙到應用並行化執行的因素瞭如指掌。本文則是分享我在提高Apache Cassandra項目中的DataStax Node.js 驅動時的一些思考與總結出的致使應用吞吐量降級的關鍵因素。

背景

Node.js使用的標準JavaScript引擎V8會將JavaScript代碼編譯爲機器碼而後以本地代碼的方式運行。V8引擎使用了以下三個組件來同時保證較低的啓動時間與最佳性能表現：

• 可以快速將JavaScript代碼編譯爲機器碼的通用編譯器。

• 可以自動追蹤應用中代碼執行時間而且決定應該優化哪些代碼模塊的運行時分析器。

• 可以自動優化被分析器標註的待優化代碼的優化編譯器；而且若是操做被認爲是過優化，該編譯器還能自動地進行逆優化操做。

儘管優化編譯器可以保證最佳的性能表現，可是它並不會對全部的代碼進行優化，特別是那些不合適的代碼編寫模式。你能夠參考來自Google Chrome DevTools團隊的建議來了解哪些代碼模式是V8拒絕優化的，典型的包括：

• 包含try-catch語句的函數

• 使用arguments對象對函數參數進行從新賦值

雖然優化編譯器可以顯著提高代碼容許速度，可是對於典型的IO密集型的應用，大部分的性能優化仍是依賴於指令重排以及避免高佔用的調用來提升每秒的操做執行數目；這也會是咱們在接下來的章節中須要討論的部分。

測試基準

爲了可以更好地發現那些能夠惠及最多用戶的優化技巧，咱們須要模擬真實用戶場景，根據經常使用任務執行的工做量來定義測試基準。首先咱們須要測試API入口點的吞吐量與時延；除此以外若是但願獲取更多的信息，你也能夠選擇對於內部調用方法進行性能評測。推薦使用process.hrtime()來獲取實時解析與執行時長。雖然可能會對項目開發形成些許不便，但我仍是建議儘量早地在開發週期中引入性能評測。能夠選擇先從一些方法調用進行吞吐量測試，而後再慢慢地增長譬如時延分佈這些相對複雜的測試。

CPU 分析

目前有多種CPU分析器可供咱們使用，其中Node.js自己提供的開箱即用的CPU分析器已經能應付大部分的使用場景。內建的Node.js分析器源於V8內置的分析器，它可以以固定地頻率對棧信息進行採樣；你能夠在運行node命令時使用--prof參數來建立V8標記文件。而後你能夠對分析結果進行聚合轉化處理，經過使用--prof-process參數將其轉化爲可讀性更好的文本：

$ node --prof-process isolate-0xnnnnnnnnnnnn-v8.log > processed.txt

在編輯器中打開通過處理的記錄文件，你能夠看到整個記錄被劃分爲了部分，首先咱們來看下Summary部分，其格式以下所示：

[Summary]:

  ticks   total   nonlib  name

  20109   41.2%   45.7%  JavaScript

  23548   48.3%   53.5%  C++

    805    1.7%    1.8%  GC

   4774    9.8%          Shared libraries

    356    0.7%          Unaccounted

上面的值分別表明了在JavaScript/C++代碼以及垃圾收集器中的採樣頻次，其會隨着分析代碼的不一樣而變化。而後你能夠根據須要分別查看具體的子部分（譬如[JavaScript], [C++], ...）來了解具體的採樣信息。除此以外，分析文件中還包含一個叫作[Bottom up (heavy) profile]的很是有用的部分，它以樹形結構展現了買個函數的調用者，其基本格式以下：

223  32%      LazyCompile: *function1 lib/file1.js:223:20

221  99%        LazyCompile: ~function2 lib/file2.js:70:57

221  100%         LazyCompile: *function3 /lib/file3.js:58:74

上面的百分比表明該層調用者佔目標函數全部調用者數目的比重，而函數以前的星號意味着該函數是通過優化處理的，而波浪號表明該函數是未通過優化的。在上面的例子中，function199%的調用是由function2發起的，而function3佔據了function2100%的調用佔比。CPU 分析結果與火焰圖是很是有用的分析棧佔用與CPU耗時的工具。不過須要注意的是，這些分析結果並不意味着所有，大量的異步IO操做會讓分析變得不那麼容易。

系統調用

Node.js利用Libuv提供的平臺無關的接口來實現非阻塞型IO，應用程序中全部的IO操做（sockets, 文件系統, ...）都會被轉化爲系統調用。而調度這些系統調用會耗費大量的時間，所以咱們須要儘量地聚合IO操做，以批量寫的方式來最小化系統調用的次數。具體而言，咱們應該將Socket或者文件流放入到緩衝中而後一次性處理而不是對每一個操做進行單獨處理。你可使用寫隊列來管理你的全部寫操做，經常使用的寫隊列的實現邏輯以下：

• 當咱們須要進行寫操做而且在某個處理窗口期內：

  • 將該緩衝區添加到待寫列表中

• 鏈接全部的緩衝區而且一次性的寫入到目標管道中。

你能夠基於總的緩衝區長度或者第一個元素進入隊列的時間來定義窗口尺寸，不過在定義窗口尺寸時咱們須要權衡考慮單個寫操做的時延與總體寫操做的時延，不能厚此薄彼。你也須要同時考慮可以聚合的寫操做的最大數目以及單個寫請求的開銷。你可能會以千字節爲單位決定一個寫隊列的上限，咱們的經驗發現8千字節左右是個不錯的臨界點；固然根據你應用的具體場景這個值確定會有變化，你能夠參考咱們的這個寫隊列的完整實現。總結而言，當咱們採用了批量寫以後系統調用的數目大大下降了，最終提高了應用的總體吞吐量。

Node.js 定時器

Node.js中的定時器與window中的定時器具備相同的API，能夠很方便地實現簡單的調度操做；在整個生態系統中有很普遍的應用，所以咱們的應用中可能充斥着大量的延時調用。相似於其餘基於散列的輪轉調度器，Node.js使用散列表與鏈表來維護定時器實例。不過有別於其餘的輪轉調度器，Node.js並無維持固定長度的散列表，而是根據觸發時間對定時器創建索引。添加新的定時器實例時，若是Node.js發現已經存在了相同的鍵值（有相同觸發事件的定時器），那麼會以O(1)複雜度完成添加操做。若是還不存在該鍵值，則會建立新的桶而後將定時器添加到該桶中。須要銘記於心的是，咱們應該儘量地重用已存在的定時器存放桶，避免移除整個桶而後再建立一個新的這種耗時的操做。舉例而言，若是你使用滑動延時，那麼應該在使用clearTimeout()移除定時器以前使用setTimeout()建立新的定時器。咱們對於心跳包的處理中在移除上一個定時器以前會先肯定下以O(1)複雜度調度空閒的定時器。

Ecmascript 語言特性

當咱們着眼於總體的性能保障時，咱們須要避免使用部分Ecmascript中的高級語言特性，典型的譬如:Function.prototype.bind(), Object.defineProperty() 以及 Object.defineProperties()。咱們能夠在JavaScript引擎的實現描述或者問題中發現這些特性的性能缺陷所在，譬如Improvement in Promise performance in V8 5.3 以及 Function.prototype.bind performance in V8 5.4。另外你也須要謹慎使用ES2015或者ESNext中的新的語言特性，它們相較於ECMAScript 5中的語法會慢不少。six-speed 項目網站就追蹤了這些語言特性在不一樣的JavaScript引擎上的性能表現，若是你還沒有發現某些特性的性能評測你也能夠本身進行一些測試。V8 團隊也一直致力於提升新的語言特性的性能表現，最終使其與底層實現保持一致。咱們能夠在性能規劃中隨時瞭解他們對於ES2015性能優化的工做進展，這裏他們會收集使用者對於提高點的建議而且發佈新的設計文檔來闡述他們的解決方案。你也能夠在這個博客隨時瞭解V8的實現進展，不過考慮到V8的提高可能須要較長的時間才能合併入LTS版本的Node.js: 根據LTS規劃只有在Node.js大版本迭代時纔會合併進最新的V8版本。你可能要等待6-12月才能發現新的V8引擎被合併進入Node.js的運行環境中，而目前Node.js的新的發佈版本只會包含V8引擎中的部分修復。

依賴

Node.js 運行時爲咱們提供了完整的IO操做庫，可是ECMAScript語法標準則僅提供了寥寥無幾的內建數據類型，不少時候咱們不得不依賴第三方的庫來進行某些基本任務。沒有人能保證這些第三方的庫能夠準確高效地工做，即便那些流行的明星模塊也可能存在問題。Node.js的生態系統是如此的繁榮茂盛，可能不少依賴模塊中只包含幾個你本身很方便就能實現的方法。咱們須要在重複造輪子的代價與依賴帶來的性能不可控之間作一個權衡。咱們團隊會盡量地避免引入新的依賴，而且對全部的依賴持保守態度。不過對於bluebird這樣自己發佈了可信賴的性能評測的庫咱們是很歡迎的。咱們的項目中使用async來處理異步操做，在代碼庫中普遍地使用了async.series(), async.waterfall() 以及 async.whilst()。確實咱們很難說這樣鏈接了多個層次的異步處理庫就是性能受損的罪魁禍首，幸虧有不少其餘開發者定位了其中存在的問題。咱們也能夠選擇相似於neo-async這樣的替代庫，它的運行效率明顯提升而且也有公開的性能評測結果。

總結

本文中說起的優化技巧有的屬於常識，有的則是涉及到Node.js生態系統以及JavaScript核心引擎的實現細節與工做原理。在咱們開發的客戶端驅動中，經過引入這些優化手段咱們達成了兩倍的吞吐量的提高。考慮到咱們的Node.js應用以單線程方式運行，咱們應用佔據CPU的時間片與指令的排布順序會大大影響總體的吞吐量與高平行的實現程度。

關於做者

Jorge Bay是Apache Cassandra項目中Node.js以及C#客戶端驅動的核心工程師，同時仍是DataStax的DSE。他樂於解決問題與提供服務端解決方案，Jorge擁有超過15年的專業軟件開發經驗，他爲Apache Cassandra實現的Node.js客戶端驅動一樣也是DataStax官方驅動的基礎