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很相似，理論上也有類似的線程切換問題，不知道效率怎樣。