在騰訊新聞搶金達人活動 node 同構直出渲染方案的總結文章中我們整體瞭解了下同構直出渲染方案在我們專案中的使用。正如我在上篇文章結尾所說的：

應用型技術的難點不是在克服技術問題，而是在於能夠不斷的結合自身的產品體驗，發現其中存在的體驗問題，不斷使用更好的技術方案去優化使用者的體驗，為整個產品發展添磚加瓦。

我們在根據產品的體驗效果選擇了 react 同構直出渲染方案，必然也要保證當前方案的可用性和可靠性。例如我們的服務能同時支撐多少人訪問，當用戶量增大時是否可以依然保證使用者的正常訪問，如何保證 CPU、記憶體等正常運作，而不被一直佔用無法釋放等。因此，這裡我們應當下我們專案的幾項資料：

1. 專案一天的訪問量是多少，高峰期的訪問量是多少，即併發的使用者量有多少；
2. 我們的單機服務最大能支援多少 QPS；
3. 高併發時的服務響應時間如何，頁面，介面的失敗率有多少；
4. CPU 和記憶體的使用情況，是否存在 CPU 使用不充分或者記憶體洩露等問題；

這些資料，都是我們上線前要知道的。壓力測試的重要性就提現出來了，我們在上線前進行充分的測試，能夠讓我們掌握程式和伺服器的執行效能，大致申請多少臺機器等等。

1. 初次壓力測試

我們這裡使用autocannon來對專案進行壓測。注意，我們現在還沒有進行任何的優化措施，就是要先暴露出問題來，然後針對性的進行優化。

每秒鐘 60 的併發，並持續 100 秒：

autocannon -c 60 -d 100

壓測後的資料：

從圖片中可以看到，每秒 60 的併發請求量時，QPS 平均有 266 左右，不過還有 23 個請求超時了，響應時間還可以，99%的請求在 1817ms 毫秒內完成。就目前這幾項資料來看，資料處理能力並不理想，我們還有很大的提升空間。

2. 解決方案

針對上面壓測出來的資料不理想，我們這裡需要採取一些措施了。

2.1 記憶體管理

我們現在寫純前端時，幾乎已經很少關注記憶體的使用了，畢竟在前端發展的過程中，記憶體的垃圾回收機制相對來說比較完善，而且前端頁面的生存週期比較短。如果真是要特別注意的話，也是早期在 IE 瀏覽器中，js 與 dom 的互動過程中可能會產生記憶體的洩露。而且如果真會真要是洩露的話，也只會影響當前終端的使用者，其他的使用者暫時不會受到影響。

而服務端則不同，所有使用者都會訪問當前執行的程式碼，只要程式有一丁點的記憶體洩露，在成千上萬的訪問量下，都會造成記憶體的堆積，垃圾無法回收，最終造成嚴重的記憶體洩露，並導致程式崩潰。為了預防記憶體洩露，我們在記憶體管理方面，主要三方面的內容：

1. V8 引擎的垃圾回收機制；
2. 造成記憶體洩露的原因；
3. 如何檢測記憶體洩露；

Node 將 JavaScript 的主要應用場景擴充套件到了伺服器端,相應要考慮的細節也與瀏覽器端不同, 需要更嚴謹地為每一份資源作出安排。總的來說,記憶體在 Node 中不能隨心所欲地使用，但也不是完全不擅長。

2.1.1 V8 引擎的垃圾回收機制

在 V8 中，主要將記憶體分為新生代和老生代兩代。新生代的物件為存活時間比較短的物件，老生代中的物件為存活時間較長的或常駐記憶體的物件。

預設情況下，新生代的記憶體最大值在 64 位系統和 32 位系統上分別為 32 MB 和 16 MB。V8 對記憶體的最大值在 64 位系統和 32 位系統上分別為 1464 MB 和 732 MB。

為什麼這樣分兩代呢？是為了最優的 GC 演算法。新生代的 GC 演算法 Scavenge 速度快，但是不合適大資料量；老生代針使用 Mark-Sweep（標記清除） & Mark-Compact（標記整理） 演算法，合適大資料量，但是速度較慢。分別對新舊兩代使用更適合他們的演算法來優化 GC 速度。

2.1.2 記憶體洩露的原因

記憶體洩露的情況有很多，例如記憶體當快取、佇列、重複的事件監聽等。

記憶體當快取這種情況中，通常有用一個變數來快取資料，然後沒有過期時間，一直填充資料，例如下面一個簡單的例子：

let cached = new Map();

server.get('*', (req, res) => {
    if (cached.has(req.url)) {
        return cached.get(req.url);
    }
    const html = app.render(req, res);
    cached.set(req.url, html);
    res.send(html);
});

除此之外，還有閉包也是其中的一種情況。這種使用記憶體的不好的地方是，它沒有可用的過期策略，只會讓資料越來越多，最終造成記憶體洩露。更好的方式使用第三方的快取機制，例如 redis、memcached 等，這些都有良好的過期和淘汰策略。

同時，也有一些佇列方面的處理，例如有些日誌的寫入操作，當海量的資料需要寫入時，就會造成佇列的堆積。這時，我們設定佇列的超時策略和拒絕策略，讓一些操作儘快地釋放掉。

再一個就是事件的重複監聽。例如對同一個事件重複監聽，忘記移除（removeListener），將造成記憶體洩漏。這種情況很容易在複用物件上新增事件時出現，所以事件重複監聽可能收到如下警告：

Warning: Possible EventEmitter memory leak detected. 11 /question listeners added。Use emitter。setMaxListeners() to increase limit

2.1.3 排查的手段

我們從記憶體的監控圖中可以看到，在使用者量基本保持不變的情況下，記憶體是一直在緩慢上漲，說明我們產生了記憶體洩露，使用的記憶體並沒有被釋放掉。

這裡我們可以通過node-heapdump等工具來進行判斷，或者稍微簡單點，使用--inspect命令實現：

node --inspect server.js

然後開啟 chrome 連結chrome://inspect來檢視記憶體的使用情況。

通過兩次的記憶體抓取對比發現，handleRequestTimeout()方法一直在產生，且每個 handle 方法中有無數個回撥，資源無法被釋放。

通過定位檢視使用的 axios 程式碼是：

if (config.timeout) {
    timer = setTimeout(function handleRequestTimeout() {
        req.abort();
        reject(createError('timeout of ' + config.timeout + 'ms exceeded', config, 'ECONNABORTED', req));
    }
}

這裡程式碼看起來是沒任何問題的，這是在前端處理中一個很典型的超時處理解決方式。

由於 Nodejs 中，io 的連結會阻塞 timer 處理，因此這個 setTimeout 並不會按時觸發，也就有了 10s 以上才返回的情況。

貌似問題解決了，巨大的流量和阻塞的 connection 導致請求堆積，伺服器處理不過來，CPU 也就下不來了。

通過定位並檢視axios 的原始碼：

if (config.timeout) {
    // Sometime, the response will be very slow, and does not respond, the connect event will be block by event loop system.
    // And timer callback will be fired, and abort() will be invoked before connection, then get "socket hang up" and code ECONNRESET.
    // At this time, if we have a large number of request, nodejs will hang up some socket on background. and the number will up and up.
    // And then these socket which be hang up will devoring CPU little by little.
    // ClientRequest.setTimeout will be fired on the specify milliseconds, and can make sure that abort() will be fired after connect.
    req.setTimeout(config.timeout, function handleRequestTimeout() {
        req.abort();
        reject(
            createError(
                'timeout of ' + config.timeout + 'ms exceeded',
                config,
                'ECONNABORTED',
                req
            )
        );
    });
}

額，我之前使用的版本比較早，跟我本地使用的程式碼不一樣，說明是更新過了，再檢視這個檔案的9 月 16 日的改動歷史：

這裡我們就需要把 axios 更新到最新的版本了。而且經過本地大量測試，發現在高負載下 CPU 和記憶體都在正常範圍內了。

2.2 快取

快取真是效能優化的一把好手，服務不夠，快取來湊。不過快取的型別有很多種，我們應當根據專案的實際情況，合理地選擇使用快取的策略。這裡我們使用了 3 層的快取策略。

在 nginx 中，可以使用 proxy_cache 設定要快取的路徑和快取的時間，同時可以啟用proxy_cache_lock。

當 proxy_cache_lock 被啟用時，當多個客戶端請求一個快取中不存在的檔案（或稱之為一個 MISS），只有這些請求中的第一個被允許傳送至伺服器。其他請求在第一個請求得到滿意結果之後在快取中得到檔案。如果不啟用 proxy_cache_lock，則所有在快取中找不到檔案的請求都會直接與伺服器通訊。

不過這個欄位的啟用也要非常慎重，當訪問量過大時，會造成請求的堆積，必須等待第一個請求返回完成後，才能處理後面的請求。

proxy_cache_path /data/cached keys_zone=answer:16m levels=1:2 inactive=60m;

server {
    location / {
        proxy_cache answer;
        proxy_cache_valid 1m;
    }
}

在業務層面，我們可以啟用 redis 快取，來快取整個頁面、頁面的某個部分或者介面等等，當穿透 nginx 快取時，可以啟用 redis 快取。使用第三方快取的特點我們在之前的文章也說了：多個程序之間可以共享，同時減少專案本身對快取淘汰演算法的處理。

當前面的兩層快取失效時，進入到我們的 node 服務層。二層的快取機制，能實現不同的快取策略和快取粒度，業務需要根據自身場景， 選用適合自己業務的快取即可。

3. 效果

這時我們專案的效能怎樣了呢？

autocanon -c 1000 -d 100

從圖片裡可以看到，99%的請求在182ms內完成，每秒平均處理的請求有15707左右，相比我們最開始只能處理200多個請求，效能足足提升了60倍多。

相關閱讀：

騰訊新聞搶金達人活動node同構直出渲染方案的總結

我的部落格原文地址：https://www.xiabingbao.com/post/node/node-high-performance.html

來自騰訊的前端開發工程師，與你分享前端快樂：wenzichel

相關推薦