Windows下两种iocp实现的差距

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很相似,理论上也有类似的线程切换问题,不知道效率怎样。

 

 

评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值