多核單伺服器各種配置和業務壓力下的node.js效能測試

本文為原創文章，出自http://cnodejs.org，轉載請註明出處和作者
 作者：snoopy
 原文：http://cnodejs.org/blog/?p=2334

上篇文章我提到用taskset綁定多核cpu來運行node.js可以提高其穩定性和效能，我們拿資料說話，今天花了一天時間用來做壓力測試，結果雖然僅供參考，但是也能說明一些問題。

聲明：此次效能測試資料絕對真實，結果僅供參考。

網路環境：內網
 壓力測試伺服器：
 伺服器系統：Linux 2.6.18
 伺服器配置：Intel(R) Xeon(TM) CPU 3.40GHz 4 CPUS
 記憶體：6GB

發包伺服器：
 發包工具：apache 2.2.19內建的ab測試載入器
 伺服器系統：Linux 2.6.18
 伺服器配置：Pentium(R) Dual-Core CPU E5800 @ 3.20GHz 2CPUS
 記憶體：1GB

第一輪測試：空架構測試

服務端node.js代碼：
var http=require('http');
var server = http.createServer(function(request, response) {
response.writeHead(200, {'Content-Type':'text/plain'});
response.end('Hello World\n'); })
server.listen(8880); //註：這裡會根據情況設定8880-8883 這4個連接埠
console.log('Server running at http://10.1.10.150:8880/');

灰常簡單的代碼，返回”hello world”，也是官方範例程式碼。 我們先測node.js空架構裸奔效能，具體業務的效能要接下來會進行測試。

Nginx端代碼：
upstream node_server_pool {
server 10.1.10.150:8880 ;
server 10.1.10.150:8881 ;
server 10.1.10.150:8882 ;
server 10.1.10.150:8883 ;
}
server {
listen 8888;
server_name 10.1.10.150;
location / {
proxy_pass http://node_server_pool;
}
}

第一種測試：在服務端只開一個node.js服務，連接埠為8880，直接通過ab對8880連接埠進行壓力測試。
1000/10 1000/30
3000/10 3000/30
5000/30 7000/30
8000/30
Rps 1801
1613 1995
1993 2403
2233 1963
Tpq 0.63
0.62 0.49
0.46 0.42
0.45 0.52
fail 0
0 0 0
0 0
170

說明：
 1000/10:代表命令./ab -c 1000 -t 10 http://10.1.10.150:8880/
 rps:代表每秒處理請求數，並發的主要指標
 tpq:每個請求處理的時間，單位毫秒。
 fail:代表平均處理失敗請求數。

第二種測試：

 Node.js開8882-8883這2個連接埠，通過taskset分別綁定到2個不同的CPU上去，然後利用nginx反向 Proxy和負載平衡，nginx監聽8888連接埠，將nginx開兩個進程，綁定到另外兩個cpu上，所以ab測試包將發到8888連接埠。

小竅門：之前我曾經開4個node.js綁定4個CPU然後nginx開4個進程，綁定4個CPU，結果悲劇了，壓測一直卡死，原來是node.js和nginx搶CPU造成的，後來楚漢分界，nginx用前2個CPU，而node.js拿後兩個cpu。另外nginx也像汽車一樣，要先熱車，重啟後先隨便壓測幾次，然後過一會水溫就上來了，就可以踩油門了，哈哈。

第一步對nginx負載平衡的測試，訪問8888連接埠，然後一個個關掉node.js進程，發現當全部關掉後，頁面不能訪問，負載平衡設定成功。 第二步測試cpu綁定情況，單獨對8881-8882連接埠進行ab壓測，發現只有對應綁定cpu功耗很高，綁定單獨cpu成功。
1000/30 3000/30
4000/30 5000/30
7000/30
Rps 2526
2471 2059
2217 2016
Tpq 0.43
0.41 0.47
0.44 0.48
fail 0
0 0 0
50

 第三種測試：

 Node.js開8881-8883這3個連接埠，通過taskset分別綁定到3個不同的CPU上去，然後利用nginx反向 Proxy和負載平衡，nginx監聽8888連接埠，將nginx開一個進程，綁定到另外第一個cpu上，所以ab測試包將發到8888連接埠。
1000/30 3000/30
5000/30 7000/30
Rps 2269
2305 2164
2149
Tpq 0.43
0.43 0.45
0.48
fail 0
0 0 0

 第一輪評測總結： 單進程
雙進程 三進程
commond 5000/30
3000/30 3000/30
Rps 2403
2471 2305
Tpq 0.42
0.41 0.43
fail 0
0 0

註：這裡僅拿出相近的峰值的資料進行比較。

 為什麼第三種方式會比第二種方式效能更差呢？明明多開了一個node.js進程來處理請求，其實是nginx轉寄速度造成的，這就類似讓一輛STI跑在小馬路上，縱然STI馬力大，但是路況太差，跑不快，不如讓邁騰跑在高架上。

在空架構，不涉及業務處理的情況下，單開node.js和雙開node.js效能相差無及，畢竟nginx轉寄也要消耗掉一部分效能，提升大約5%-10%左右。當然穩定性提升100%。

 接下來我們開始第二輪效能測試，在有業務處理壓力的情況下，我們看看2者之間的差別。

第二輪測試：有業務處理壓力的測試

 nginx代碼不變，node.js代碼改為： 
var http = require('http');
var server = http.createServer(function (request, response) {
for(var i=0;i<180000;i++){
var j = i/3;
}
response.writeHead(200, {'Content-Type': 'text/plain'});
response.end('Hello World\n'); })
server.listen(8882);
console.log('Server running at http://10.1.10.150:8882/');

這裡唯一不同的是增加了一個迴圈，類比業務處理。

第二輪測試結果：

process
單進程 雙進程
三進程 單進程
雙進程 三進程
單進程 雙進程
三進程

Commond
1000/30 1000/30
1000/30 3000/30
3000/30 3000/30
5000/30 5000/30
5000/30

rps 203
311 432
198 300
451 202
294 412

tpq 4.93
3.2 2.37
5.03 3.33
2.2 4.94
3.42 2.44

50%req
4500ms 1500ms
750ms 5000ms
2000ms 1500ms
7000ms 2000ms
2000ms

Fail 0
0 0
0 0 0
235 0
0

說明：
 1000/30:代表命令./ab -c 1000 -t 30 http://10.1.10.150:8888/
 rps:代表每秒處理請求數，並發的主要指標
 tpq:每個請求處理的時間，單位毫秒。
 fail:代表平均處理失敗請求個數
 50%req:代表50%的請求在多少毫秒內返回。

兩輪測試結果總結：

 Var type1 = 裸奔node.js服務
 Var type2= nginx反向 Proxy+負載平衡+node.js多開綁定cpu

在業務處理比較簡單的情況下，type1和type2的效能差別不是很大，但是當業務處理壓力上來以後，type2每秒處理請求數效能提升100%，從使用者響應速度上提升200%，從穩定性上提升200%。綜上所述，在一台4核cpu伺服器上需要啟動node.js服務的話，最好的方式就是前1個cpu綁定nginx進程使用，後3個cpu綁定node.js進程。

 我的部落格地址，內有圖有真相：http://snoopyxdy.blog.163.com/