Node.js 根本沒有這樣搞性能優化的？

1、使用最新版本的 Node.js

僅僅是簡單的升級 Node.js 版本就可以輕松地獲得性能提升，因為幾乎任何新版本的 Node.js 都會比老版本性能更好，為什么？

Node.js 每個版本的性能提升主要來自于兩個方面：

V8 的版本更新；
Node.js 內部代碼的更新優化。

例如最新的 V8 7.1 中，就優化了某些情形下閉包的逃逸分析，讓 Array 的一些方法得到了性能提升：

Node.js 的內部代碼，隨著版本的升級，也會有明顯的優化，比如下面這個圖就是?require?的性能隨著 Node.js 版本升級的變化：

每個提交到 Node.js 的 PR 都會在 review 的時候考慮會不會對當前性能造成衰退。同時也有專門的 benchmarking 團隊來監控性能變化，你可以在這里看到 Node.js 的每個版本的性能變化：

https://benchmarking.nodejs.org/

所以，你可以完全對新版本 Node.js 的性能放心，如果發現了任何在新版本下的性能衰退，歡迎提交一個 issue。

如何選擇 Node.js 的版本？

這里就要科普一下 Node.js 的版本策略：

Node.js 的版本主要分為 Current 和 LTS；
Current 就是當前最新的、依然處于開發中的 Node.js 版本；
LTS 就是穩定的、會長期維護的版本；
Node.js 每六個月（每年的四月和十月）會發布一次大版本升級，大版本會帶來一些不兼容的升級；
每年四月發布的版本（版本號為偶數，如 v10）是 LTS 版本，即長期支持的版本，社區會從發布當年的十月開始，繼續維護 18 + 12 個月（Active LTS + Maintaince LTS）；
每年十月發布的版本（版本號為奇數，例如現在的 v11）只有 8 個月的維護期。

舉個例子，現在（2018年11月），Node.js Current 的版本是 v11，LTS 版本是 v10 和 v8。更老的 v6 處于 Maintenace LTS，從明年四月起就不再維護了。去年十月發布的 v9 版本在今年六月結束了維護。

對于生產環境而言，Node.js 官方推薦使用最新的 LTS 版本，現在是 v10.13.0。

2、使用 fast-json-stringify 加速 JSON 序列化

在 JavaScript 中，生成 JSON 字符串是非常方便的：

<pre>const json = JSON.stringify(obj)</pre>

但很少人會想到這里竟然也存在性能優化的空間，那就是使用 JSON Schema 來加速序列化。

在 JSON 序列化時，我們需要識別大量的字段類型，比如對于 string 類型，我們就需要在兩邊加上?"?，對于數組類型，我們需要遍歷數組，把每個對象序列化后，用?,?隔開，然后在兩邊加上?[?和?]?，諸如此類等等。

但如果已經提前通過 Schema 知道每個字段的類型，那么就不需要遍歷、識別字段類型，而可以直接用序列化對應的字段，這就大大減少了計算開銷，這就是 fast-json-stringfy 的原理。

根據項目中的跑分，在某些情況下甚至可以比?JSON.stringify?快接近 10 倍！

一個簡單的示例：

<pre>const fastJson = require('fast-json-stringify')
const stringify = fastJson({title: 'Example Schema',type: 'object',properties: {name: { type: 'string' },age: { type: 'integer' },books: {type: 'array',items: {type: 'string',uniqueItems: true}}}
})console.log(stringify({name: 'Starkwang',age: 23,books: ['C++ Primier', '響け！ユーフォニアム～']
}))
//=> {"name":"Starkwang","age":23,"books":["C++ Primier","響け！ユーフォニアム～"]}</pre>

在 Node.js 的中間件業務中，通常會有很多數據使用 JSON 進行，并且這些 JSON 的結構是非常相似的（如果你使用了 TypeScript，更是這樣），這種場景就非常適合使用 JSON Schema 來優化。

3、提升 Promise 的性能

Promise 是解決回調嵌套地獄的靈丹妙藥，特別是當自從 async/await 全面普及之后，它們的組合無疑成為了 JavaScript 異步編程的終極解決方案，現在大量的項目都已經開始使用這種模式。

但是優雅的語法后面也隱藏著性能損耗，我們可以使用 github 上一個已有的跑分項目進行測試，以下是測試結果：

<pre>file                               time(ms)  memory(MB)
callbacks-baseline.js                   380       70.83
promises-bluebird.js                    554       97.23
promises-bluebird-generator.js          585       97.05
async-bluebird.js                       593      105.43
promises-es2015-util.promisify.js      1203      219.04
promises-es2015-native.js              1257      227.03
async-es2017-native.js                 1312      231.08
async-es2017-util.promisify.js         1550      228.74Platform info:
Darwin 18.0.0 x64
Node.JS 11.1.0
V8 7.0.276.32-node.7
Intel(R) Core(TM) i5-5257U CPU @ 2.70GHz × 4</pre>

我們可以從結果中看到，原生 async/await + Promise 的性能比 callback 要差很多，并且內存占用也高得多。對于大量異步邏輯的中間件項目而言，這里的性能開銷還是不能忽視的。

通過對比可以發現，性能損耗主要來自于 Promise 對象自身的實現，V8 原生實現的 Promise 比 bluebird 這樣第三方實現的 Promise 庫要慢很多。而 async/await 語法并不會帶來太多的性能損失。

所以對于大量異步邏輯、輕量計算的中間件項目而言，可以在代碼中把全局的 Promise 換為 bluebird 的實現：

<pre>global.Promise = require('bluebird');</pre>

4、正確地編寫異步代碼

使用 async/await 之后，項目的異步代碼會非常好看：

<pre>const foo = await doSomethingAsync();
const bar = await doSomethingElseAsync();</pre>

但因此，有時我們也會忘記使用 Promise 給我們帶來的其它能力，比如?Promise.all()?的并行能力：

<pre>// bad
async function getUserInfo(id) {const profile = await getUserProfile(id);const repo = await getUserRepo(id)return { profile, repo }
}// good
async function getUserInfo(id) {const [profile, repo] = await Promise.all([getUserProfile(id),getUserRepo(id)])return { profile, repo }
}</pre>

還有比如?Promise.any()?（此方法不在ES6 Promise標準中，也可以使用標準的?Promise.race()?代替），我們可以用它輕松實現更加可靠快速的調用：

<pre>async function getServiceIP(name) {// 從 DNS 和 ZooKeeper 獲取服務 IP，哪個先成功返回用哪個// 與 Promise.race 不同的是，這里只有當兩個調用都 reject 時，才會拋出錯誤return await Promise.any([getIPFromDNS(name),getIPFromZooKeeper(name)])
}</pre>

5、優化 V8 GC

關于 V8 的垃圾回收機制，已經有很多類似的文章了，這里就不再重復介紹。推薦兩篇文章：

解讀 V8 GC Log（一）: Node.js 應用背景與 GC 基礎知識
解讀 V8 GC Log（二）: 堆內外內存的劃分與 GC 算法

我們在日常開發代碼的時候，比較容易踩到下面幾個坑：

坑一：使用大對象作為緩存，導致老生代（Old Space）的垃圾回收變慢

示例：

<pre>const cache = {}
async function getUserInfo(id) {if (!cache[id]) {cache[id] = await getUserInfoFromDatabase(id)}return cache[id]
}</pre>

這里我們使用了一個變量?cache?作為緩存，加速用戶信息的查詢，進行了很多次查詢后，?cache?對象會進入老生代，并且會變得無比龐大，而老生代是使用三色標記 + DFS 的方式進行 GC 的，一個大對象會直接導致 GC 花費的時間增長（而且也有內存泄漏的風險）。

解決方法就是：

使用 Redis 這樣的外部緩存，實際上像 Redis 這樣的內存型數據庫非常適合這種場景；
限制本地緩存對象的大小，比如使用 FIFO、TTL 之類的機制來清理對象中的緩存。

坑二：新生代空間不足，導致頻繁 GC

這個坑會比較隱蔽。

Node.js 默認給新生代分配的內存是 64MB（64位的機器，后同），但因為新生代 GC 使用的是 Scavenge 算法，所以實際能使用的內存只有一半，即 32MB。

當業務代碼頻繁地產生大量的小對象時，這個空間很容易就會被占滿，從而觸發 GC。雖然新生代的 GC 比老生代要快得多，但頻繁的 GC 依然會很大地影響性能。極端的情況下，GC 甚至可以占用全部計算時間的 30% 左右。

解決方法就是，在啟動 Node.js 時，修改新生代的內存上限，減少 GC 的次數：

<pre>node --max-semi-space-size=128 app.js</pre>

當然有人肯定會問，新生代的內存是不是越大越好呢？

隨著內存的增大，GC 的次數減少，但每次 GC 所需要的時間也會增加，所以并不是越大越好，具體數值需要對業務進行壓測 profile 才能確定分配多少新生代內存最好。

但一般根據經驗而言，?分配 64MB 或者 128MB 是比較合理的?。

6、正確地使用 Stream

Stream 是 Node.js 最基本的概念之一，Node.js 內部的大部分與 IO 相關的模塊，比如 http、net、fs、repl，都是建立在各種 Stream 之上的。

下面這個經典的例子應該大部分人都知道，對于大文件，我們不需要把它完全讀入內存，而是使用 Stream 流式地把它發送出去：

<pre>const http = require('http');
const fs = require('fs');// bad
http.createServer(function (req, res) {fs.readFile(__dirname + '/data.txt', function (err, data) {res.end(data);});
});// good
http.createServer(function (req, res) {const stream = fs.createReadStream(__dirname + '/data.txt');stream.pipe(res);
});</pre>

在業務代碼中合理地使用 Stream 能很大程度地提升性能，當然是但實際的業務中我們很可能會忽略這一點，比如采用 React 服務器端渲染的項目，我們就可以用?renderToNodeStream?：

<pre>const ReactDOMServer require('react-dom/server')
const http = require('http')
const fs = require('fs')
const app = require('./app')// bad
const server = http.createServer((req, res) => {const body = ReactDOMServer.renderToString(app)res.end(body)
});// good
const server = http.createServer(function (req, res) {const stream = ReactDOMServer.renderToNodeStream(app)stream.pipe(res)
})server.listen(8000)</pre>

使用 pipeline 管理 stream

在過去的 Node.js 中，處理 stream 是非常麻煩的，舉個例子：

<pre>source.pipe(a).pipe(b).pipe(c).pipe(dest)</pre>

一旦其中 source、a、b、c、dest 中，有任何一個 stream 出錯或者關閉，會導致整個管道停止，此時我們需要手工銷毀所有的 stream，在代碼層面這是非常麻煩的。

所以社區出現了 pump 這樣的庫來自動控制 stream 的銷毀。而 Node.js v10.0 加入了一個新的特性： stream.pipeline ，可以替代 pump 幫助我們更好的管理 stream。

一個官方的例子：

<pre>const { pipeline } = require('stream');
const fs = require('fs');
const zlib = require('zlib');pipeline(fs.createReadStream('archive.tar'),zlib.createGzip(),fs.createWriteStream('archive.tar.gz'),(err) => {if (err) {console.error('Pipeline failed', err);} else {console.log('Pipeline succeeded');}}
);</pre>

實現自己的高性能 Stream

在業務中你可能也會自己實現一個 Stream，可讀、可寫、或者雙向流，可以參考文檔：

*   implementing Readable streams
*   implementing Writable streams

Stream 雖然很神奇，但自己實現 Stream 也可能會存在隱藏的性能問題，比如：

<pre>class MyReadable extends Readable {_read(size) {while (null !== (chunk = getNextChunk())) {this.push(chunk);}}
}</pre>

當我們調用?new MyReadable().pipe(xxx)?時，會把?getNextChunk()?所得到的 chunk 都 push 出去，直到讀取結束。但如果此時管道的下一步處理速度較慢，就會導致數據堆積在內存中，導致內存占用變大，GC 速度降低。

而正確的做法應該是，根據?this.push()?返回值選擇正確的行為，當返回值為?false?時，說明此時堆積的 chunk 已經滿了，應該停止讀入。

<pre>class MyReadable extends Readable {_read(size) {while (null !== (chunk = getNextChunk())) {if (!this.push(chunk)) {return false  }}}
}</pre>

這個問題在 Node.js 官方的一篇文章中有詳細的介紹： Backpressuring in Streams

7、C++ 擴展一定比 JavaScript 快嗎？

Node.js 非常適合 IO 密集型的應用，而對于計算密集的業務，很多人都會想到用編寫 C++ Addon 的方式來優化性能。但實際上 C++ 擴展并不是靈丹妙藥，V8 的性能也沒有想象的那么差。

比如，我在今年九月份的時候把 Node.js 的?net.isIPv6()?從 C++ 遷移到了 JS 的實現，讓大多數的測試用例都獲得了 10%- 250% 不等的性能提升（具體PR可以看這里）。

JavaScript 在 V8 上跑得比 C++ 擴展還快，這種情況多半發生在與字符串、正則表達式相關的場景，因為 V8 內部使用的正則表達式引擎是 irregexp ，這個正則表達式引擎比 boost 中自帶的引擎（?boost::regex?）要快得多。

還有一處值得注意的就是，Node.js 的 C++ 擴展在進行類型轉換的時候，可能會消耗非常多的性能，如果不注意 C++ 代碼的細節，性能會很大地下降。

這里有一篇文章對比了相同算法下 C++ 和 JS 的性能（需翻墻）： How to get a performance boost using Node.js native addons 。其中值得注意的結論就是，C++ 代碼在對參數中的字符串進行轉換后（?String::Utf8Value?轉為?std::string?），性能甚至不如 JS 實現的一半。只有在使用 NAN 提供的類型封裝后，才獲得了比 JS 更高的性能。

換句話說，C++ 是否比 JavaScript 更加高效需要具體問題具體分析，某些情況下，C++ 擴展不一定就會比原生 JavaScript 更高效。如果你對自己的 C++ 水平不是那么有信心，其實還是建議用 JavaScript 來實現，因為 V8 的性能比你想象的要好得多。

8、使用 node-clinic 快速定位性能問題

說了這么多，有沒有什么可以開箱即用，五分鐘見效的呢？當然有。

node-clinic 是 NearForm 開源的一款 Node.js 性能診斷工具，可以非常快速地定位性能問題。

<pre>npm i -g clinic
npm i -g autocannon</pre>

使用的時候，先開啟服務進程：

<pre>clinic doctor -- node server.js</pre>

然后我們可以用任何壓測工具跑一次壓測，比如使用同一個作者的 autocannon （當然你也可以使用 ab、curl 這樣的工具來進行壓測。）：

<pre>autocannon http://localhost:3000</pre>

壓測完畢后，我們 ctrl + c 關閉 clinic 開啟的進程，就會自動生成報告。比如下面就是我們一個中間件服務的性能報告：

我們可以從 CPU 的使用曲線看出，這個中間件服務的性能瓶頸不在自身內部的計算，而在于 I/O 速度太慢。clinic 也在上面告訴我們檢測到了潛在的 I/O 問題。

下面我們使用?clinic bubbleprof?來檢測 I/O 問題：

<pre>clinic bubbleprof -- node server.js</pre>

再次進行壓測后，我們得到了新的報告：

這個報告中，我們可以看到，?http.Server?在整個程序運行期間，96% 的時間都處于 pending 狀態，點開后，我們會發現調用棧中存在大量的 empty frame，也就是說，由于網絡 I/O 的限制，CPU 存在大量的空轉，這在中間件業務中非常常見，也為我們指明了優化方向不在服務內部，而在服務器的網關和依賴的服務相應速度上。

想知道如何讀懂?clinic bubbleprof?生成的報告，可以看這里： https://clinicjs.org/bubblepr…

同樣，clinic 也可以檢測到服務內部的計算性能問題，下面我們做一些“破壞”，讓這個服務的性能瓶頸出現在 CPU 計算上。

我們在某個中間件中加入了空轉一億次這樣非常消耗 CPU 的“破壞性”代碼：

<pre>function sleep() {let n = 0while (n++ < 10e7) {empty()}
}
function empty() { }module.exports = (ctx, next) => {sleep()// ......return next()
}</pre>

然后使用?clinic doctor?，重復上面的步驟，生成性能報告：