Windows下两种iocp实现的差距
之前几天说过，因为经典iocp实现（以下简称经典实现）多个io线程绑定在一个iocp上，这样内部管理了iocp队列的处理，内部决定是不是需要线程切换，我上次修改的一个版本（以下简称实现2），用了多个io线程，每个iocp队列仅绑定一个io线程，一组用户共享一个io线程，这和经典的多线程epoll模型的做法是很相似的，这样每个io线程是可以独立控制了，但理论上这种做法没有发挥iocp自动管理线程切换的优势，昨晚没事用这两种实现分别做了个echoserver测试了一下，这两套实现代码仅40行左右不同，其他完全一样，效果真的是差很多，测试仅用一个进程模拟了4000个客户端，每秒1个包，先看实现2的，cpu占14%，2个io线程，1个accept线程，1个主线程，其他线程都没干活闲置。
|
Cpu
|
Memory
|
Threads
|
handles
|
|
14
|
40088k
|
8
|
4236
|
再看经典实现，cpu几乎一直是0%，2个io线程，accept也是在io线程里面处理，其他跟实现2一样，测试客户端也一样。
|
Cpu
|
Memory
|
Threads
|
handles
|
|
0
|
39244k
|
7
|
4336
|
说实话，在测试之前我也没想到有这么大的差距，经典实现就是1.2w个连接连上来还是这样，就是内存占用多一点：
|
Cpu
|
Memory
|
Threads
|
handles
|
|
0
|
112068k
|
7
|
12280
|
习惯上总有人喜欢拿epoll和iocp来对比，我到现在也没看到真正公平的对比，就算是相对公平的也没见到，因为在我看来，要对比硬件应该是一样的，os都应该是最新的，最重要的是，server端程序应该都是发挥了各自优势的，如果拿我这里的实现2去代表iocp的水平和epoll对比，势必造成比epoll差很多的结果，然而这显然是不正确的。
epoll经典多线程模式实际实现和实现2很相似，理论上也有类似的线程切换问题，不知道效率怎样。