|
|
|
|
| 关于2.6内核 epoll()的效率与使用框架,敬请各位大峡! |
  关于2.6内核 epoll()的效率与使用框架,敬请各位大峡! - lan_wjz [ 2005-03-25 15:18 | 645 byte(s)]
Re: 关于2.6内核 epoll()的效率与使用框架,敬请各位大峡! - mechgouki [ 2005-03-26 12:46 | 383 byte(s)]
Re: 关于2.6内核 epoll()的效率与使用框架,敬请各位大峡! - gxcooo [ 2005-03-26 22:29 | 246 byte(s)]
Re: 关于2.6内核 epoll()的效率与使用框架,敬请各位大峡! - mechgouki [ 2005-03-27 11:18 | 554 byte(s)]
Re: 关于2.6内核 epoll()的效率与使用框架,敬请各位大峡! - h_falls [ 2005-03-25 20:55 | 14 byte(s)]
|
|
|
|
[Original]
[Print]
[Top]
|
我最近测试了一下epoll()的效率,情况很不理想,感觉比poll()还要差一大截,不知道怎么搞的...
可能是我的程序框架不好,有哪位大峡能提供一个网络应用服务器的框架吗?谢谢!
我的程序结构:
epoll_create()
listen(MAX)
for(;;)
{
x=epoll_wait()
for(i=0;i<x;i++)
{
if(listen)
/* add listen in queue */
epoll_ctl()
if(read)
/* reading */
epoll_ctl()
if(write)
/* writing */
epoll_ctl()
}
}
|
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
这个完整的paper 的名字叫＜Comparing and Evaluating epoll, select, and poll Event Mechanisms＞ google应该
可以找到
它用了hp的一个研究项目来对比这些接口，其实对我们正确使用epoll很有帮助，只所以在前几个测试种epoll没有什么优势它分析出来是过多的epoll_ctl 造成－－－这个可能和这个server本身有关，它是http的，可能需要频繁的更改其FD,一般来说epoll_ctl越少越好．
不过最后一个用idle conns模拟同时连接数还是指出了epoll的效用，这也是epoll设计的本质
|
|
|
[Original]
[Print]
[Top]
|
|
|
声明: 本页内容为中国Linux论坛的内容镜像，文章的版权以及其他所有的相关权利属于中国Linux论坛和相应文章的作者，如果转载，请注明文章来源及相关版权信息。