epoll高效的原因,从下面几个方向来说:
文章目录
-
-
-
- 用户态将文件描述符传入内核的方式
-
- select:
- epoll:
- 内核监测文件描述符是否可读可写的方式
-
- select:
- epoll:
- 如何找到就绪的文件描述符并传递给用户
-
- select:
- epoll:
- 继续重新监听时如何重复以上步骤
-
- select:
- epoll:
- 在什么情况下select会比epoll高效呢
-
-
select:
select(int maxfdp,fd_set *readfds,fd_set *writefds,fd_set *errorfds,struct timeval *timeout);
根据API,可以看出select需要提供三个文件描述符(内部是位图,所以只用三个即可),分别监听读、写、异常。
epoll:
epoll_create的时候在内核高速cache中建红黑树以及就绪链表(存储已有监听事件到达的fd)。用户执行epoll_ctl的时候就会在红黑树中增加相应的节点。
select:
采取轮询的方式,遍历fd,最后返回一个描述符读写操作是否就绪的mask掩码,根据这个掩码给fd_set赋值。
epoll:
通过在epoll_ctl的时候想内核注册回调函数,内核在监测到文件描述符可读/可写的时候调用相应的回调,将文件描述符相关的结构体放入就绪链表中。
select:
用户并不知道哪些文件描述符处于就绪状态,需要遍历。
epoll:
epoll_wait的时候直接检查就绪链表,返回的fd都是已经就绪的,以此处理即可。
select:
将新的文件描述符重新传入内核态中,需要重新复制一次。
epoll:
无须重新传入,直接沿用红黑树中节点即可。
在少连接高并发的情况下。
因为,连接少意味着不会超过select1024的上限,高并发意味着一次wait每一个连接都会来数据。把扫描有事件连接时的O(n)的复杂度降至O(1)。
加上每次只需要复制4次fd_set从内核空间和用户空间往返,(sizeof(fd_set)=128),总体上比epoll要复制的量要少(sizeof(struct epoll_event)=12)(假设100个连接 12*100=1200)。在这种情况下select是要比epoll高效的。
到这里延伸一下,如果select支持大量连接,并且每一个连接都是相当活跃的,即还是O(n)->O(1)的情况。那么select的性能要比epoll高。
也就是说select的差距主要体现在每次内核O(n)的去遍历fd,用户也需要去遍历fd,造成效率低下。
(1764条消息) epoll比select高效的原因及select比epoll高效场景_比epoll更高效_Immortal_s的博客-CSDN博客