通过击鼓传花程序来对比 muduo 与 libevent2 的事件处理效

通过击鼓传花程序来对比 muduo 与 libevent2 的事件处理效2014-04-03 陈硕前面我们比较了 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。