epoll源码剖析 上

epoll的性能分析

 

epoll的性能凭什么就要比poll或者select好呢？

一个是事件集合:

    在每次使用poll或者select之前，都需要准备一个事件集合，传递给内核，进行分析 并在内核空间构建相应的数据结构来完成

对事件集合的注册。  epoll则不是这样，epoll维护了一个全局事件集合，通过epoll句柄，可以操纵这个事件的集合，增加，删除

或修改这个事件集合里的元素。如果事件集合变化没那么大，操纵系统内核就不需要每次重新扫描事件集合，构建内核空间数据结构。

还有一个是就绪列表:

    每次在使用poll或者select之后，应用程序都需要扫描整个感兴趣的事件集合，从中找到真正活动的事件。如果列表增长在K以上。每次扫描的时间也是惊人的。事实上，很多情况下，扫描一圈，可能发现只有几个真正活动的事件。

而epoll则不时这样，返回的直接就是活动的事件列表，应用程序减少了大量的扫描时间。

 

触发模式-边缘触发和条件触发

    如果某个套接字有 100 个字节可以读，边缘触发（edge-triggered）和条件触发（level-triggered）都会产生 read ready notification 事件，如果应用程序只读取了 50 个字节，边缘触发就会陷入等待；而条件触发则会因为还有 50 个字节没有读取完，不断地产生 read ready notification 事件。在条件触发下（level-triggered），如果某个套接字缓冲区可以写，会无限次返回 write ready notification 事件，在这种情况下，如果应用程序没有准备好，不需要发送数据，一定需要解除套接字上的 ready notification 事件，否则 CPU 就直接跪了。我们简单地总结一下，边缘触发只会产生一次活动事件，性能和效率更高。不过，程序处理起来要更为小心。