副标题#e#
前面我们较量了 muduo 和 libevent2 的吞吐量，获得的结论是 muduo 比 libevent2 快 18%。有 人会说，libevent2 并不是为高吞吐的应用场景而设计的，这样的较量不公正，胜之不武。为了公正起 见，这回我们用 libevent2 自带的机能测试措施（伐鼓传花）来比拟 muduo 和 libevent2 在高并发 环境下的 IO 事件处理惩罚效率。
测试工具
libevent 2.0.6-rc， 源代码包 http://monkey.org/~provos/libevent-2.0.6-rc.tar.gz
muduo 0.1.2-alpha，源码 http://muduo.googlecode.com/files/muduo-0.1.2-alpha.tar.gz SHA1 Checksum: 9e7da4b46ad87602dd206eaedf54e67c17dfe4e1 。须编译为 release 版。
测试情况
测试用的软硬件情况与《muduo 与 boost asio 吞吐量比拟》和《muduo 与 libevent2 吞吐量比拟》沟通，别的我还在本身的条记本上运行了测试，功效也附在后头。
测 试内容
测试的场景是：有 1000 小我私家围成一圈，玩伐鼓传花的游戏，一开始第 1 小我私家手里有花 ，他把花传给右手边的人，那小我私家再继承把花传给右手边的人，当花转手 100 次之后游戏遏制，记录 从开始到竣事的时间。
用措施表达是，有 1000 个网络毗连 (socketpairs 或 pipes)，数据在 这些毗连中顺次通报，一开始往第 1 个毗连里写 1 个字节，然后从这个毗连的另一头读出这 1 个字 节，再写入第 2 个毗连，然后读出来继承写到第 3 个毗连，直到一共写了 100 次之后措施遏制，记 录所用的时间。
以上是只有一个勾当毗连的场景，我们实际测试的是 100 个或 1000 个勾当连 接（即 100 朵花或 1000 朵花，匀称分手在人群手中），而毗连总数（即并发数）从 100 到 100,000 (十万)。留意每个毗连是两个文件描写符，为了运行测试，需要调高每个历程能打开的文件数，好比设 为 256000。
libevent2 的测试代码位于 test/bench.c，我修复了 2.0.6-rc 版里的一个小 bug，批改后的代码见 http://github.com/chenshuo/recipes/blob/master/pingpong/libevent/bench.c
muduo 的测 试代码位于 examples/pingpong/bench.cc，见 http://gist.github.com/564985#file_pingpong_bench.cc
测试功效与接头
第一轮，分 别用 100 个勾当毗连和 1000 个勾当毗连，无超时，读写 100 次，测试一次游戏的总时间（包括初始 化）和事件处理惩罚的时间（不包括注册 event watcher）随毗连数（并发数）变革的环境。详细表明见 libev 的机能测试文档 http://libev.schmorp.de/bench.html ，差异之处在于我们不较量 timer event 的机能，只较量 IO event 的机能。对每个并发数，措施轮回 25 次，刨去第一次的热身数据， 后 24 次算平均值。测试用的剧本在 http://github.com/chenshuo/recipes/blob/master/pingpong/libevent/run_bench.sh 。这个剧本是 libev 的作者 Marc Lehmann 写的，我略作改用，用于测试 muduo 和 libevent2。
第一轮的结 果，请先只看红线和绿线。红线是 libevent2 用的时间，绿线是 muduo 用的时间。数字越小越好。注 意这个图的横坐标是对数的，每一个数量级的取值点为 1, 2, 3, 4, 5, 6, 7.5, 10。
#p#副标题#e#
从红绿线比拟可以看出：
1. libevent2 在初始化 event watcher 上面比 muduo 快 20% （ 左边的两个图）
2. 在事件处理惩罚方面（右边的两个图）：a) 在 100 个勾当毗连的环境下， libevent2 和 muduo 分段领先。当总毗连数（并发数）小于 1000 时，二者机能差不多；当总毗连数 大于 30000 时，muduo 略占优；当总毗连数大于 1000 小于 30000 时，libevent2 明明领先。b) 在 1000 个勾当毗连的环境下，当并发数小于 10000 时，libevent2 和 muduo 得分靠近；当并发数大于 10000 时，muduo 明明占优。
这里我们有两个问题：1. 为什么 muduo 花在初始化上的时间比 较多？ 2. 为什么在一些环境下它比 libevent2 慢许多。
我仔细阐明白个中的原因，并参考了 libev 的作者 Marc Lehmann 的概念 ( http://lists.schmorp.de/pipermail/libev/2010q2/001041.html )，结论是：在第一轮初始化时， libevent2 和 muduo 都是用 epoll_ctl(fd, EPOLL_CTL_ADD, …) 来添加 fd event watcher。差异之 处在于，在后头 24 轮中，muduo 利用了 epoll_ctl(fd, EPOLL_CTL_MOD, …) 来更新已有的 event watcher；然而 libevent2 继承挪用 epoll_ctl(fd, EPOLL_CTL_ADD, …) 来反复添加 fd，并忽略返 回的错误码 EEXIST (File exists)。在这种反复添加的环境下，EPOLL_CTL_ADD 将会快速地返回错误 ，而 EPOLL_CTL_MOD 会做更多的事情，花的时间也更长。于是 libevent2 捡了个自制。
为了 验证这个结论，我窜改了 muduo，让它每次都用 EPOLL_CTL_ADD 方法初始化和更新 event watcher， 并忽略返回的错误。
第二轮测试功效见上图的蓝线，可见窜改之后的 muduo 的初始化机能比 libevent2 更好，事件处理惩罚的耗时也有所低落（我猜测是 kernel 内部的原因）。
#p#分页标题#e#
这个窜改只 是为了验证想法，我并没有把它放到 muduo 最终的代码中去，这或者可以留作日后优化的余地。（具 体的窜改是 muduo/net/poller/EPollPoller.cc 第 115 行和 144 行，读者可自行验证。）
同 样的测试在双核条记本电脑上运行了一次，功效如下：（我的条记本的 CPU 主频是 2.4GHz，高于台式 机的 1.86GHz，所以用时较少。）
结论：在事件处理惩罚效率方面，muduo 与 libevent2 总体较量靠近，各擅胜场。在并发量出格大的情 况下（大于 10k），muduo 略微占优。
查察本栏目
