前面我們比較了 muduo 和 libevent2 的吞吐量，得到的結(jié)論是 muduo 比 libevent2 快 18%。有人會(huì)說(shuō)，libevent2 并不是為高吞吐的應(yīng)用場(chǎng)景而設(shè)計(jì)的，這樣的比較不公平，勝之不武。為了公平起見(jiàn)，這回我們用 libevent2 自帶的性能測(cè)試程序（擊鼓傳花）來(lái)對(duì)比 muduo 和 libevent2 在高并發(fā)情況下的 IO 事件處理效率。
測(cè)試對(duì)象
測(cè)試環(huán)境
測(cè)試用的軟硬件環(huán)境與《muduo 與 boost asio 吞吐量對(duì)比》和《muduo 與 libevent2 吞吐量對(duì)比》相同，另外我還在自己的筆記本上運(yùn)行了測(cè)試，結(jié)果也附在后面。
測(cè)試內(nèi)容
測(cè)試的場(chǎng)景是：有 1000 個(gè)人圍成一圈，玩擊鼓傳花的游戲，一開(kāi)始第 1 個(gè)人手里有花，他把花傳給右手邊的人，那個(gè)人再繼續(xù)把花傳給右手邊的人，當(dāng)花轉(zhuǎn)手 100 次之后游戲停止，記錄從開(kāi)始到結(jié)束的時(shí)間。
用程序表達(dá)是，有 1000 個(gè)網(wǎng)絡(luò)連接 (socketpairs 或 pipes)，數(shù)據(jù)在這些連接中順次傳遞，一開(kāi)始往第 1 個(gè)連接里寫(xiě) 1 個(gè)字節(jié)，然后從這個(gè)連接的另一頭讀出這 1 個(gè)字節(jié)，再寫(xiě)入第 2 個(gè)連接，然后讀出來(lái)繼續(xù)寫(xiě)到第 3 個(gè)連接，直到一共寫(xiě)了 100 次之后程序停止，記錄所用的時(shí)間。
以上是只有一個(gè)活動(dòng)連接的場(chǎng)景，我們實(shí)際測(cè)試的是 100 個(gè)或 1000 個(gè)活動(dòng)連接（即 100 朵花或 1000 朵花，均勻分散在人群手中），而連接總數(shù)（即并發(fā)數(shù)）從 100 到 100,000 (十萬(wàn))。注意每個(gè)連接是兩個(gè)文件描述符，為了運(yùn)行測(cè)試，需要調(diào)高每個(gè)進(jìn)程能打開(kāi)的文件數(shù)，比如設(shè)為 256000。
libevent2 的測(cè)試代碼位于 test/bench.c，我修復(fù)了 2.0.6-rc 版里的一個(gè)小 bug，修正后的代碼見(jiàn) http://github.com/chenshuo/recipes/blob/master/pingpong/libevent/bench.c
muduo 的測(cè)試代碼位于 examples/pingpong/bench.cc，見(jiàn) http://gist.github.com/564985#file_pingpong_bench.cc
測(cè)試結(jié)果與討論
第一輪，分別用 100 個(gè)活動(dòng)連接和 1000 個(gè)活動(dòng)連接，無(wú)超時(shí)，讀寫(xiě) 100 次，測(cè)試一次游戲的總時(shí)間（包含初始化）和事件處理的時(shí)間（不包含注冊(cè) event watcher）隨連接數(shù)（并發(fā)數(shù)）變化的情況。具體解釋見(jiàn) libev 的性能測(cè)試文檔 http://libev.schmorp.de/bench.html ，不同之處在于我們不比較 timer event 的性能，只比較 IO event 的性能。對(duì)每個(gè)并發(fā)數(shù)，程序循環(huán) 25 次，刨去第一次的熱身數(shù)據(jù)，后 24 次算平均值。測(cè)試用的腳本在 http://github.com/chenshuo/recipes/blob/master/pingpong/libevent/run_bench.sh 。這個(gè)腳本是 libev 的作者 Marc Lehmann 寫(xiě)的，我略作改用，用于測(cè)試 muduo 和 libevent2。
第一輪的結(jié)果，請(qǐng)先只看紅線(xiàn)和綠線(xiàn)。紅線(xiàn)是 libevent2 用的時(shí)間，綠線(xiàn)是 muduo 用的時(shí)間。數(shù)字越小越好。注意這個(gè)圖的橫坐標(biāo)是對(duì)數(shù)的，每一個(gè)數(shù)量級(jí)的取值點(diǎn)為 1, 2, 3, 4, 5, 6, 7.5, 10。
從紅綠線(xiàn)對(duì)比可以看出：
1. libevent2 在初始化 event watcher 上面比 muduo 快 20% （左邊的兩個(gè)圖）
2. 在事件處理方面（右邊的兩個(gè)圖）：a) 在 100 個(gè)活動(dòng)連接的情況下，libevent2 和 muduo 分段領(lǐng)先。當(dāng)總連接數(shù)（并發(fā)數(shù)）小于 1000 時(shí)，二者性能差不多；當(dāng)總連接數(shù)大于 30000 時(shí)，muduo 略占優(yōu)；當(dāng)總連接數(shù)大于 1000 小于 30000 時(shí)，libevent2 明顯領(lǐng)先。b) 在 1000 個(gè)活動(dòng)連接的情況下，當(dāng)并發(fā)數(shù)小于 10000 時(shí)，libevent2 和 muduo 得分接近；當(dāng)并發(fā)數(shù)大于 10000 時(shí)，muduo 明顯占優(yōu)。
這里我們有兩個(gè)問(wèn)題：1. 為什么 muduo 花在初始化上的時(shí)間比較多？ 2. 為什么在一些情況下它比 libevent2 慢很多。
我仔細(xì)分析了其中的原因，并參考了 libev 的作者 Marc Lehmann 的觀點(diǎn) ( http://lists.schmorp.de/pipermail/libev/2010q2/001041.html )，結(jié)論是：在第一輪初始化時(shí)，libevent2 和 muduo 都是用 epoll_ctl(fd, EPOLL_CTL_ADD, …) 來(lái)添加 fd event watcher。不同之處在于，在后面 24 輪中，muduo 使用了 epoll_ctl(fd, EPOLL_CTL_MOD, …) 來(lái)更新已有的 event watcher；然而 libevent2 繼續(xù)調(diào)用 epoll_ctl(fd, EPOLL_CTL_ADD, …) 來(lái)重復(fù)添加 fd，并忽略返回的錯(cuò)誤碼 EEXIST (File exists)。在這種重復(fù)添加的情況下，EPOLL_CTL_ADD 將會(huì)快速地返回錯(cuò)誤，而 EPOLL_CTL_MOD 會(huì)做更多的工作，花的時(shí)間也更長(zhǎng)。于是 libevent2 撿了個(gè)便宜。
為了驗(yàn)證這個(gè)結(jié)論，我改動(dòng)了 muduo，讓它每次都用 EPOLL_CTL_ADD 方式初始化和更新 event watcher，并忽略返回的錯(cuò)誤。
第二輪測(cè)試結(jié)果見(jiàn)上圖的藍(lán)線(xiàn)，可見(jiàn)改動(dòng)之后的 muduo 的初始化性能比 libevent2 更好，事件處理的耗時(shí)也有所降低（我推測(cè)是 kernel 內(nèi)部的原因）。
這個(gè)改動(dòng)只是為了驗(yàn)證想法，我并沒(méi)有把它放到 muduo 最終的代碼中去，這或許可以留作日后優(yōu)化的余地。（具體的改動(dòng)是 muduo/net/poller/EPollPoller.cc 第 115 行和 144 行，讀者可自行驗(yàn)證。）
同樣的測(cè)試在雙核筆記本電腦上運(yùn)行了一次，結(jié)果如下：（我的筆記本的 CPU 主頻是 2.4GHz，高于臺(tái)式機(jī)的 1.86GHz，所以用時(shí)較少。）
結(jié)論：在事件處理效率方面，muduo 與 libevent2 總體比較接近，各擅勝場(chǎng)。在并發(fā)量特別大的情況下（大于 10k），muduo 略微占優(yōu)。
關(guān)于 muduo 的更多介紹請(qǐng)見(jiàn)《發(fā)布一個(gè)基于 Reactor 模式的 C++ 網(wǎng)絡(luò)庫(kù)》。muduo 的項(xiàng)目網(wǎng)站是 http://code.google.com/p/muduo ，上面有個(gè) class diagram 可供參考。