Node负载能力测试

需求很简单，就是提供一个服务接口收集端上传来的日志文件并保存，要求能承受的QPS为5000。

以前从来都没考虑过Node服务的负载能力，用 koa + co-busboy 接受上传文件请求并用 fs 直接写文件开发完服务并用 pm2 进行进程管理，总觉得心里不踏实，便开始在服务器上，测试 Node 服务的负载能力。

服务器信息：

系统：CentOS release 6.7

CPU：48核

压测命令：（在另一台服务器上运行命令）

siege -c 10 -b -t 1m -l test.log http://xxx.xxx.xxx.xxx:3001 > siege.log

测试简单 Node 服务负载：(使用简陋的方法统计QPS的大概值)

server.js

let http = require('http');
let count = 0,
    start_timestamp = new Date().getTime();

let server = http.createServer((req, res) => {
    try {
        let cur_timestamp = new Date().getTime();
        count++;
        if (cur_timestamp - start_timestamp >= 1000) {
            console.log(count);
            start_timestamp = cur_timestamp;
            count = 0;
        }
        res.writeHead(200, {'Content-Type': 'text/plain'});
        res.end('hello world');
    } catch (e) {
        console.log(`err: ${e.message}`);
    }
});
server.listen(3001);
console.log('run on 3001');

压测结果：

使用两台不同的服务器同时运行压测命令得到的结果：

如图可看出在服务器上单进程 Node 服务的性能极限，那么换成 koa 再来测一下会有什么结果呢？

server_koa.js

const Koa = require('koa');
const app = new Koa();

let count = 0,
    start_timestamp = new Date().getTime();

app.use(async (ctx) => {
    try {
        let cur_timestamp = new Date().getTime();
        count++;
        if (cur_timestamp - start_timestamp >= 1000) {
            console.log(count);
            start_timestamp = cur_timestamp;
            count = 0;
        }
        ctx.body = 'hello world';
    } catch (e) {
        console.log(`err ${e.message}`);
    }
});

app.listen(3001);
console.log('run on 3001');

看来用 Koa 的话对极限QPS的影响还是比较大的

如果使用 pm2 管理简单服务，结果如何？

左图为 pm2 使用 1 个实例，右图为使用 4 个实例，可以明显看到实例增加能大大提高程序负载能力，但是使用 2 台机器压测的结果却是这样：

有点奇怪了，照理来说 4 个实例的处理能力怎么说加起来应该远超过 1w 才对，试着加大实例数量到 48，再用 2 台机器压测结果如下：

提升的效果不是很让人满意，使用 3 台机器压测结果：

即使在 48 核的服务器上开了 48 个进程来跑，极限 QPS 也止步 1w。值得注意的是在 48 核的服务器上用 pm2 来跑 server_koa.js，极限 QPS 与跑 server.js 相近，都是略小于 1w。这说明此时极限 QPS 已经不是制约在服务代码实现上，而应该从 Node 底层实现寻找答案，在网上找了半天找到这篇博客干货比较多：http://taobaofed.org/blog/2015/10/29/deep-into-node-1/  

由于 Node 的文件 I/O、事件循环的通知是 Libuv 维护的线程池来操作，且默认线程池的大小是 4，那么通过修改线程池大小 UV_THREADPOOL_SIZE 会发生什么现象呢？在 server.js 最顶上添加代码：

process.env.UV_THREADPOOL_SIZE = 64;

压测结果如下：

结果没有明显变化。这是因为 Linux 下，网络 I/O 采用的是 epoll 异步模型，不是通过线程池的方式处理。

如何修改 epoll 的参数来提升极限QPS呢？