select / poll / epoll 差异

    众所周知,网络socket处理常见的三种方式是select / poll / epoll(linux) / 完成端口(windows),简单说一下各自的差异:

    select:

           1)每次轮循需要把监控的fd集合拷贝到内核

           2)轮循fd数组查看fd是否可读写

           3)最大fd值为1024,maxfd+1<=1024  (windows下为个数,linux下为值)

    poll:

           1)每次轮循需要把监控的fd集合拷贝到内核

           2)轮循fd数组查看fd是否可读写

           3)没有最大fd值限制

    epoll:

           1)epoll实现时开辟了一块共享内存,所以监控的fd集合不需要反复在用户态和内核态之间拷贝

           2)类似回调函数的机制,只返回可读写的fd集合

           3)没有最大fd限制

 

    性能:

           1)select 和 poll 性能随着 fd 个数增加 会呈线性下降

           2)epoll 性能根据活跃的 fd 的个数增加 呈线性下降,如果所有 fd 都处在活跃状态,那么epoll的性能和select/poll 差异不大

    使用建议:

           1)fd 个数较少的情况建议使用select / poll,逻辑简单,性能也差不了多少;

           2)fd个数较多特别是活跃fd较少的情况,使用epoll 性能上会比select/poll 高好多;

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
最近在开发im服务器 需要大并发链接 QT默认的是使用select模型的 这种轮询方式非常慢 在高并发连接 我们需要epoll才能发挥linux服务器的性能 而且使用简单 整个服务端代码架构无需修改 直接可以使用 只要在 main文件添加: int main int argc char argv[] { #ifdef Q OS LINUX QCoreApplication::setEventDispatcher new EventDispatcherLibEvent ; qInstallMessageHandler customMessageHandler ; #endif QCoreApplication a argc argv ; auto ser new ConfigServer; ser >startServer ; return a exec ; } 在 pro文件添加 linux{ LIBS + levent core SOURCES + common eventdispatcher libevent eventdispatcher libevent cpp common eventdispatcher libevent eventdispatcher libevent config cpp common eventdispatcher libevent eventdispatcher libevent p cpp common eventdispatcher libevent socknot p cpp common eventdispatcher libevent tco eventfd cpp common eventdispatcher libevent tco pipe cpp common eventdispatcher libevent tco cpp common eventdispatcher libevent timers p cpp HEADERS + common eventdispatcher libevent common h common eventdispatcher libevent eventdispatcher libevent h common eventdispatcher libevent eventdispatcher libevent config h common eventdispatcher libevent eventdispatcher libevent config p h common eventdispatcher libevent eventdispatcher libevent p h common eventdispatcher libevent libevent2 emul h common eventdispatcher libevent qt4compat h common eventdispatcher libevent tco h common eventdispatcher libevent wsainit h } 可以直接跨平台了使用了 csdn博客:http: blog csdn net rushroom">最近在开发im服务器 需要大并发链接 QT默认的是使用select模型的 这种轮询方式非常慢 在高并发连接 我们需要epoll才能发挥linux服务器的性能 而且使用简单 整个服务端代码架构无需修改 直接可以使用 只要在 main文件添加: [更多]
selectpollepoll都是Linux下的I/O多路复用机制,可以同时监视多个文件描述符,当某个文件描述符就绪(一般是读就绪或者写就绪),则立即通知相应程序进行处理。它们的主要区别在于实现方式和性能上的差异select是最古老的I/O多路复用机制,它使用一个fd_set类型的数组来存放需要监视的文件描述符,每次调用select时,都需要将这个数组从用户态拷贝到内核态,这个过程比较耗时。同时,select支持的文件描述符数量有限,一般为1024。 pollselect的改进版,它使用一个pollfd类型的数组来存放需要监视的文件描述符,每次调用poll时,只需要将这个数组从用户态拷贝到内核态一次,效率比select高。但是poll仍然存在一个问题,就是每次调用poll时都需要遍历整个数组来查找就绪的文件描述符,当需要监视的文件描述符数量很大时,这个过程会比较耗时。 epoll是Linux 2.6内核引入的新机制,它使用一个epoll_event类型的数组来存放需要监视的文件描述符,每次调用epoll时,只需要将这个数组从用户态拷贝到内核态一次,效率比poll更高。而且epoll支持的文件描述符数量非常大,一般为几万个,甚至可以达到百万级别。另外,epoll还支持两种工作模式:LT(Level Triggered)和ET(Edge Triggered),LT模式下,当文件描述符就绪时,epoll_wait会立即返回;而ET模式下,当文件描述符就绪时,epoll_wait只会通知一次,直到下次有新的数据到来才会再次通知。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值