http://laokaddk.blog.51cto.com/368606/607227
第一篇
使用epoll的注意事项:
1. ET模式比LT模式高效,但比较难控制。
2. 如果某个句柄期待的事件不变,不需要EPOLL_CTL_MOD,但每次读写后将该句柄modify一次有助于提高稳定性,特别在ET模式。
3. socket关闭后最好将该句柄从epoll中delete(EPOLL_CTL_DEL),虽然epoll自身有处理,但会使epoll的hash的节点数增多,影响搜索hash的速度。
http://blog.sina.com.cn/s/blog_5378b283010008gh.html
第二篇
这一篇没仔细测试过,要仔细测试
接上篇文章,这段时间一直对使用EPOLL关联socket的网络通讯进行测试,功能测试就不用说了,网络上有很多实现例子,都可以参考;我主要集中在压力测试和稳定情况的分析,现有了自己的一点体会,特贴出来供大家批驳。
首先描述一下测试环境:Linux服务器,内核版本:2.6.9,g++版本3.4.6,EPOLL都使用ET模式。
第一个体会是关于监听套接字m_hListenSocket和epoll关联。一般的例子都是创建监听套接字和EPOLL描述苻后使用如下代码建立关联:
建立连接后,任何客户端和服务器监听端口建立连接的功能测试都是正常的,可以建立连接、收发数据等。
但开启压力测试后发现了新问题:
150个连接每间隔1秒和服务器建立连接,EPOLL只返回给我130个请求,并建立了130个连接;反复测试了多次,都是如此,那剩余的客户端请求那里去了?
接着测试了300个连接,发现EPOLL只返回给我280个请求,也吃掉了20个请求;如果先建立150个连接,再一个一个的请求会发生什么呢?测试的情况是第131个请求不是151个请求,是被EPOLL吃掉的请求出来了;也就是说新请求可以把EPOLL未投递给我的消息顶出来,EPOLL一直保持着20个请求不返回,为什么会有这种现象呢?解决办法是什么呢?
带着这些疑问,反复进行了测试,发现使用EPOLL提供的LT模式,没有这种问题,但CPU消耗实在是太高了,不能接受。
测试了接收和发送数据了TCP套接字,由于每次发送数据后都使用如下代码,和epoll重新建立了关联,所以没有发生过EPOLL吃掉消息的问题。注意如不使用代码再次建立关联,则不能使用户socket持续发送数据。
同时获得这个启发,是不是ET模式下,接受客户端请求建立连接时,EPOLL也要和监听套接字m_hListenSocket重新建立关联呢?随即增加了如下代码进行了测试:
这下好了,无论是150个连接还是300个,EPOLL都可以完整的反馈给我了。看来这一步是必须的,但为什么EPOLL一定要吃掉20个请求呢,这点是我最不能理解呢?如果没有关联,那第2个请求或第3个就应当不返回了,真诚希望能有高手给予一个明确的答复。