这年头做网络并发模型的,如果说没用过epoll,八成是要遭人鄙视的。那么,epoll的性能到底有多好?
先看下面这张图
但凡学过epoll的人都看过这样类似的图。图的纵轴是每秒的http响应数,其实就是系统的吞吐量(Throughput),横轴则是并发的连接数。很明显,epoll的性能要远好于传统的poll,在整个横轴范围内,无论并发的连接数是多少,epoll都保持了稳定的吞吐量。这也是为什么我们要选择epoll的原因。因为它能够支持海量并发连接,它能够解决C10K problem 。
(epoll和poll的差别在很多地方都找得到,简而言之,传统的select/poll对于监听的socket采取轮询的方式,每次轮询都要线性查看所有的socket;而epoll的优点是它每次只对活跃的socket进行操作)
如果只是到此为止,那么可能所有的人都会认为,epoll代表着先进的生产力,我们应该摒弃poll而拥护epoll(很多初学者如我一开始都是这么想的)。
别急,再来看另一个实验:
图的纵轴表示的是epoll比poll速度的比例(这里有些不清楚,“faster”这个词到底是指什么?throughput?latency?)。而横轴很有意思,它表示的是监听的所有socket中active(活跃数)和total(总数)的比。举例说,有一千个用户同时连接到了系统,这时候total就是1000,但是,这一千个用户中只有一个用户在发送请求,那么active的值就是1。整个图所表示的意思是,如果active/total的比值很小,那么epoll要比poll快好几倍(图的左侧),但是,如果active/total的值比较大(接近1),那么,epoll的性能可能和poll没有太大差别,甚至更差(图的右侧)。而这篇文章的作者得到一个经验的临界值:当active/total为0.6时,两者性能几乎相等。
结论是不是出乎意料?其实细想一下,也很好理解。当active/total的值很小的时候,说明活跃的连接数不多,这时候poll仍然要轮询所有的连接,而epoll只需要处理活跃的那部分。可是,当active/total的值接近1的时候,这时候大部分连接都是活跃的,poll的轮询命中率会很高,而epoll的优势相应的就不明显了。
所以,即便是epoll和poll,也很难说其中的一个就一定比另一个好。那么,对于其它的一些并发模型,比如multi-thread,比如thread pool,就更难分出个绝对的胜负了。每一个都有适合的应用场景。