Windows下两种iocp实现的差距

 

 

之前几天说过,因为经典iocp实现(以下简称经典实现)多个io线程绑定在一个iocp上,这样内部管理了iocp队列的处理,内部决定是不是需要线程切换,我上次修改的一个版本(以下简称实现2),用了多个io线程,每个iocp队列仅绑定一个io线程,一组用户共享一个io线程,这和经典的多线程epoll模型的做法是很相似的,这样每个io线程是可以独立控制了,但理论上这种做法没有发挥iocp自动管理线程切换的优势,昨晚没事用这两种实现分别做了个echoserver测试了一下,这两套实现代码仅40行左右不同,其他完全一样,效果真的是差很多,测试仅用一个进程模拟了4000个客户端,每秒1个包,先看实现2的,cpu14%2io线程,1accept线程,1个主线程,其他线程都没干活闲置。

 

Cpu

Memory

Threads

handles

14

40088k

8

4236

 

再看经典实现,cpu几乎一直是0%2io线程,accept也是在io线程里面处理,其他跟实现2一样,测试客户端也一样。

Cpu

Memory

Threads

handles

0

39244k

7

4336

 

说实话,在测试之前我也没想到有这么大的差距,经典实现就是1.2w个连接连上来还是这样,就是内存占用多一点:

Cpu

Memory

Threads

handles

0

112068k

7

12280

 

习惯上总有人喜欢拿epolliocp来对比,我到现在也没看到真正公平的对比,就算是相对公平的也没见到,因为在我看来,要对比硬件应该是一样的,os都应该是最新的,最重要的是,server端程序应该都是发挥了各自优势的,如果拿我这里的实现2去代表iocp的水平和epoll对比,势必造成比epoll差很多的结果,然而这显然是不正确的。

 

epoll经典多线程模式实际实现和实现2很相似,理论上也有类似的线程切换问题,不知道效率怎样。

 

 

Posted on 2011-02-01 10:48 袁斌 阅读(11912) 评论(3)  编辑 收藏 引用 所属分类: c++网络

Feedback

# re: Windows下两种iocp实现的差距[未登录]  回复  更多评论   

2011-02-02 10:28 by by
iocp的優勢就是系統調度的工作線程,他會盡量進行無切換的線程調度。我之前做過試驗,壓力小時,工作線程幾乎只用到了第一個。你用固定的io線程正是摒棄的iocp的這個優勢。
epoll的優勢是高效的poll,但是他並不涉及線程,所有的線程處理都是靠線程系統本身來調度,並不會去針對epoll優化。並且epoll管理的只是狀態,並不會關心io操作本身,這也加重了編碼的負擔,以epoll為基礎的各種網絡框架參差不齊。
以前我用的時候,是以單線程epoll,多線程處理狀態的方式建立了框架。io操作都分布到多個線程。所有的狀態都放進一個隊列中,等待io線程去取用。

# re: Windows下两种iocp实现的差距  回复  更多评论   

2011-02-02 11:43 by 袁斌
@by
iocp编程理论上比epoll困难,因为:
1、winsock系列函数众多,常用的也有几十个函数,而且参数众多,而*nix只有区区几个函数。
2、epoll函数通知之后是非阻塞同步调用,而iocp是异步调用,更难理解,编程也更复杂。
3、iocp模式的框架几乎没有单线程模式的,而epoll的框架很多都是单线程的,这和iocp的多线程框架相比难度降低了很多。当然这个不绝对,要视不同实现而定。
iocp异步多线程模式的确是加大了资源管理的难度,我看过很多网络框架的实现,几乎都在这上面花了很多精力,但处理得好的极少,即使是无错的都不多。所以也没见过几个写得好的框架,同样采用iocp的不同实现,效率相差可能超过百倍,这可能比epoll的不同框架差距更大。
最近的frame2中IO线程分组调度是为了给每个io线程绑定特殊tls数据,并使得这些线程可直接接收指定消息更新tls数据,标准框架还是经典模式的,使用好多年了,高效稳定可靠。

# re: Windows下两种iocp实现的差距  回复  更多评论   

2011-02-04 11:52 by 杨粼波
by说的在理.


iocp可以看看这篇文章,挺好的.
http://wenku.baidu.com/view/a1f11287bceb19e8b8f6ba2d.html

只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   博问   Chat2DB   管理