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