Windows下兩種iocp實現(xiàn)的差距
之前幾天說過，因為經(jīng)典iocp實現(xiàn)（以下簡稱經(jīng)典實現(xiàn)）多個io線程綁定在一個iocp上，這樣內部管理了iocp隊列的處理，內部決定是不是需要線程切換，我上次修改的一個版本（以下簡稱實現(xiàn)2），用了多個io線程，每個iocp隊列僅綁定一個io線程，一組用戶共享一個io線程，這和經(jīng)典的多線程epoll模型的做法是很相似的，這樣每個io線程是可以獨立控制了，但理論上這種做法沒有發(fā)揮iocp自動管理線程切換的優(yōu)勢，昨晚沒事用這兩種實現(xiàn)分別做了個echoserver測試了一下，這兩套實現(xiàn)代碼僅40行左右不同，其他完全一樣，效果真的是差很多，測試僅用一個進程模擬了4000個客戶端，每秒1個包，先看實現(xiàn)2的，cpu占14%，2個io線程，1個accept線程，1個主線程，其他線程都沒干活閑置。
|
Cpu
|
Memory
|
Threads
|
handles
|
|
14
|
40088k
|
8
|
4236
|
再看經(jīng)典實現(xiàn)，cpu幾乎一直是0%，2個io線程，accept也是在io線程里面處理，其他跟實現(xiàn)2一樣，測試客戶端也一樣。
|
Cpu
|
Memory
|
Threads
|
handles
|
|
0
|
39244k
|
7
|
4336
|
說實話，在測試之前我也沒想到有這么大的差距，經(jīng)典實現(xiàn)就是1.2w個連接連上來還是這樣，就是內存占用多一點：
|
Cpu
|
Memory
|
Threads
|
handles
|
|
0
|
112068k
|
7
|
12280
|
習慣上總有人喜歡拿epoll和iocp來對比，我到現(xiàn)在也沒看到真正公平的對比，就算是相對公平的也沒見到，因為在我看來，要對比硬件應該是一樣的，os都應該是最新的，最重要的是，server端程序應該都是發(fā)揮了各自優(yōu)勢的，如果拿我這里的實現(xiàn)2去代表iocp的水平和epoll對比，勢必造成比epoll差很多的結果，然而這顯然是不正確的。
epoll經(jīng)典多線程模式實際實現(xiàn)和實現(xiàn)2很相似，理論上也有類似的線程切換問題，不知道效率怎樣。