请教下在高并发的情况下,网络IO的处理效率问题 - CNode技术社区

用nodejs封装了一层应用层接口做webservice,使用了request去请求底层的http接口,这些接口因为计算的原因,普遍都在100ms以上(同一机房,网络延时可以忽略),我使用apache的ab压测,底层接口本身大约是200的qps。我封的node服务却只有70多qps,把请求接口注销掉的话有1000+qps。而且我打印了下请求接口的时间,同样的压力,比直接压测底层接口的时间多了几倍(400ms+)。 搜了下,libeio只有4个线程?是因为请求时间太长,libeio的线程被占用吗,类似于高速路上的收费站?不过我将pool.maxSocket改成200+后,qps达到了190左右。不太明白这块的原理,也没搜到理想的结果。所以想请教下各位这块的原理以及怎么处理会比较好

多核服务器? 考虑一下用cluster ?

对,多核,但是cluster还是Stability 1阶段。我这个线上重要服务还是不冒险使用处于试验性的,而且本身是放在nginx后的,所以会选择开多个进程。 关键是如果libeio就4个线程,如果请求的http接口时间比较长的话,感觉怎么这块都会是一个很大的瓶颈

@cekimy 如果你不放心你可以使用第三方的cluster,或者forever pm2

可以先看下是不是程序或者系统设置的问题, 如果都ok的话可以参考这边文章 Scaling Node.js Applications

4个线程是指文件io,网络io libuv压根地没有使用线程,在linux是走epoll,你的问题是node http client的max socket默认只有5,默认情况下对单host只有5个活跃socket连接,而且0.10.x及一下node的http agent都不是正在意义上的keepalive,你可以查看timewait有大量来观察。

优化已经好早有同学分享过了,将max socket设置大点,使用agentkeepalive 模块替换默认的http agent