6.5.1 muduo 与Boost.Asio、libevent2 的吞吐量对比（1）

我在编写muduo 的时候并没有以高并发、高吞吐为主要目标。但出乎我的意料，ping pong 测试表明，muduo 的吞吐量比Boost.Asio 高15% 以上；比libevent2 高18% 以上，个别情况甚至达到70%.

测试对象

boost 1.40 中的asio 1.4.3

asio 1.4.5 （http://think-async.com/Asio/Download）

libevent 2.0.6-rc （http://monkey.org/~provos/libevent-2.0.6-rc.tar.gz）

muduo 0.1.1

测试代码

asio 的测试代码取自http://asio.cvs.sourceforge.net/viewvc/asio/asio/src/tests/performance/，未做更改。

我自己编写了libevent2 的ping pong 测试代码，路径是recipes/pingpong/libevent/。

由于这个测试代码没有使用多线程，所以只对比muduo 和libevent2 在单线程下的性能。

muduo 的测试代码位于examples/pingpong/，代码如gist 17 所示。

muduo 和asio 的优化编译参数均为-O2 -finline-limit=1000。

$ BUILD_TYPE=release ./build.sh # 编译muduo 的优化版本 

测试环境

硬件： DELL 490 工作站， 双路Intel 四核Xeon E5320 CPU， 共8 核， 主频1.86GHz，内存16GiB。

软件：操作系统为Ubuntu Linux Server 10.04.1 LTS x86_64，编译器是g++ 4.4.3。

测试方法

依据asio 性能测试18 的办法，用ping pong 协议来测试muduo、asio、libevent2在单机上的吞吐量。

简单地说，ping pong 协议是客户端和服务器都实现echo 协议。当TCP 连接建立时，客户端向服务器发送一些数据，服务器会echo 回这些数据，然后客户端再echo 回服务器。这些数据就会像乒乓球一样在客户端和服务器之间来回传送，直到有一方断开连接为止。这是用来测试吞吐量的常用办法。注意数据是无格式的，双方都是收到多少数据就反射回去多少数据，并不拆包，这与后面的ZeroMQ 延迟测试不同。

我主要做了两项测试：

单线程测试。客户端与服务器运行在同一台机器，均为单线程，测试并发连接数为1/10/100/1000/10 000 时的吞吐量。

多线程测试。并发连接数为100 或1000，服务器和客户端的线程数同时设为1/2/3/4。（由于我家里只有一台8 核机器，而且服务器和客户端运行在同一台机器上，线程数大于4 没有意义。）

在所有测试中，ping pong 消息的大小均为16KiB。测试用的shell 脚本可从http://gist.github.com/564985 下载。

在同一台机器测试吞吐量的原因如下：

现在的CPU 很快，即便是单线程单TCP 连接也能把千兆以太网的带宽跑满。如果用两台机器，所有的吞吐量测试结果都将是110MiB/s，失去了对比的意义。（用Python 也能跑出同样的吞吐量，或许可以对比哪个库占的CPU 少。）

在同一台机器上测试，可以在CPU 资源相同的情况下，单纯对比网络库的效率。也就是说在单线程下，服务端和客户端各占满1 个CPU，比较哪个库的吞吐量高。

测试结果

单线程测试的结果（见图6-3），数字越大越好。

（点击查看大图）图6-3