当前位置:天才代写 > tutorial > C语言/C++ 教程 > 通过伐鼓传花措施来比拟 muduo 与 libevent2 的事件处理惩罚效

通过伐鼓传花措施来比拟 muduo 与 libevent2 的事件处理惩罚效

2017-11-02 08:00 星期四 所属: C语言/C++ 教程 浏览:44

副标题#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。

通过击鼓传花法子来相比 muduo 与 libevent2 的事件处理惩罚处罚效


#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 的事件处理惩罚处罚效

结论:在事件处理惩罚效率方面,muduo 与 libevent2 总体较量靠近,各擅胜场。在并发量出格大的情 况下(大于 10k),muduo 略微占优。

查察本栏目

 

    关键字:


天才代写-代写联系方式