epoll“传说中”的性能

注意，题目不是“传说中”的epoll。epoll我亲自用过，自然不是传说，但下文中的性能分析，皆为道听途说，并不是亲自做的实验。

这年头做网络并发模型的，如果说没用过epoll，八成是要遭人鄙视的。那么，epoll的性能到底有多好？
先看下面这张图， link：http://www.xmailserver.org/linux-patches/nio-improve.html

但凡学过epoll的人都看过这样类似的图。图的纵轴是每秒的http响应数，其实就是系统的吞吐量（Throughput），横轴则是并发的连接数。很明显，epoll的性能要远好于传统的poll，在整个横轴范围内，无论并发的连接数是多少，epoll都保持了稳定的吞吐量。这也是为什么我们要选择epoll的原因。因为它能够支持海量并发连接，它能够解决C10K problem 。
（epoll和poll的差别在很多地方都找得到，简而言之，传统的select/poll对于监听的socket采取轮询的方式，每次轮询都要线性查看所有的socket；而epoll的优点是它每次只对活跃的socket进行操作）

 

如果只是到此为止，那么可能所有的人都会认为，epoll代表着先进的生产力，我们应该摒弃poll而拥护epoll（很多初学者如我一开始都是这么想的）。
别急，再来看另一个实验：link：http://sheddingbikes.com/posts/1280829388.html

图的纵轴表示的是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，就更难分出个绝对的胜负了。每一个都有适合的应用场景。