8177790
上篇文章我提到用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反向代理和负载均衡，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反向代理和负载均衡，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反向代理+负载均衡+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/