muduo 与 libevent2 吞吐量对比

libevent 是一款非常好用的 C 语言网络库,它也采用 Reactor 模型,正好可以与 muduo 做一对 比。

本文用 ping pong 测试来对比 muduo 和 libevent2 的吞吐量,测试结果表明 muduo 吞吐量 平均比 libevent2 高 18% 以上,个别情况达到 70%。

测试对象

libevent 2.0.6-rc (http://monkey.org/~provos/libevent-2.0.6-rc.tar.gz)

muduo 0.1.1 (http://muduo.googlecode.com/files/muduo-0.1.1-alpha.tar.gz) SHA1 Checksum: a446ea8a22915f439063d2bc52eb2dc4b9caf92d

测试环境与测试方法

测试环境与前文《muduo 与 boost asio 吞吐量对比》相同。

我自己编写了 libevent2 的 ping pong 测试代码,地址在 http://github.com/chenshuo/recipes/tree/master/pingpong/libevent/ 。由于这个测试代码没有使 用多线程,所以本次测试只对比单线程下的性能。

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

在同一台机器测试 吞吐量的原因:

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

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

测试结果

单线程吞吐量测试,数字越大越好:

以上结果让人大跌眼镜,muduo 居然比 libevent 快 70%!跟踪 libevent2 的源代码发现,它每次 最多从 socket 读取 4096 字节的数据 (证据在 buffer.c 的 evbuffer_read() 函数),怪不得吞吐量 比 muduo 小很多。因为在这一测试中,muduo 每次读取 16384 字节,系统调用的性价比较高。

buffer.c:#define EVBUFFER_MAX_READ      4096

时间: 2024-11-08 23:27:32

muduo 与 libevent2 吞吐量对比的相关文章

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

前面我们比较了 muduo 和 libevent2 的吞吐量,得到的结论是 muduo 比 libevent2 快 18%.有 人会说,libevent2 并不是为高吞吐的应用场景而设计的,这样的比较不公平,胜之不武.为了公平起 见,这回我们用 libevent2 自带的性能测试程序(击鼓传花)来对比 muduo 和 libevent2 在高并发 情况下的 IO 事件处理效率. 测试对象 libevent 2.0.6-rc, 源代码包 http://monkey.org/~provos/libe

muduo 与 boost asio 吞吐量对比

muduo (http://code.google.com/p/muduo) 是一个基于 Reactor 模式的 C++ 网络库,我在编写它 的时候并没有以高并发高吞吐为主要目标,但出乎我的意料,ping pong 测试表明,muduo 吞吐量比 boost.asio 高 15% 以上. 测试对象 boost 1.40 中的 asio 1.4.3 asio 1.4.5 (http://think-async.com/Asio/Download) muduo 0.1.1 (http://muduo

Muduo 网络编程示例(六)限制服务器的最大并发连接数

本文已以大家都熟悉的 EchoServer 介绍如何限制服务器的并发连接数. 本文的代码见 http://code.google.com/p/muduo/source/browse/trunk/examples/maxconnection/ <Muduo 网络 编程示例 系列>计划中的第六篇文章原本是"用于测试两台机器的带宽的 pingpong 程序", pingpong 协议的程序已经在<muduo 与 boost asio 吞吐量对比>和<muduo

Crystal 三种报表解决方案大对比:.NET 对象模型,报表应用服务器对象模型,水晶企业对象模型

对象|服务器|解决 概述 对于使用 .NET 平台的 Web 应用程序开发,Crystal Decisions 为开发者提供了三种愈加高级的报表对象模型: 1. 水晶报表 Visual Studio .NET 版 (.NET) 对象模型:捆绑在微软 Visual Studio .NET 和水晶报表 9 开发者版及高级版中. 2. 新增的报表应用服务器 (RAS) 对象模型:捆绑在水晶报表 9 开发者版及高级版中. 3. 水晶企业 (Crystal Enterprise) (CE) 对象模型:在水

四款路由器对比评测 360安全路由性价比最高

互联网业内知名人士,著名IT评论家 贾敬华在微博上发表了一篇文章,对四款路由器进行了一个拆解对比,下面就让我们来一起看看. 闲来无事,把家里四个路由器给拆了,基本都是之前评测的产品.四款路由器分别是:360安全路由.http://www.aliyun.com/zixun/aggregation/29923.html">TP-LINK的TL-WDR6300.磊科的NW774以及小米路由器. 通过下面的表格,我们可以一目了然的看到这些产品的硬件配置. 360路由器 沉金面板+高通芯片 360安

GFS, HDFS, Blob File System架构对比

分布式文件系统很多,包括GFS,HDFS,淘宝开源的TFS,Tencent用于相册存储的TFS (Tencent FS,为了便于区别,后续称为QFS),以及Facebook Haystack.其中,TFS,QFS以及Haystack需要解决的问题以及架构都很类似,这三个文件系统称为Blob FS (Blob File System).本文从分布式架构的角度对三种典型的文件系统进行对比. 我们先看GFS和HDFS.HDFS基本可以认为是GFS的一个简化版实现,二者因此有很多相似之处.首先,GFS和

如何用muduo实现memcached协议

最近花了两天时间用 muduo 部分实现了 memcached 服务器协议,代码位于 examples/memcached/server,能通过 memcached 的大部分测试用例(incr/decr 还没有实现). 这不是 memcached 的替代品(它没有实现LRU和超时功能,也没有实现二进制协议,更没有自己管理内 存),而是一个网络编程的示例(代码只有 1000 行,比 memcached 小很多),展示 muduo 风格的事 件驱动编程,以及将来性能优化的试验品(换句话说,现在这个版

HBase在单Column和多Column情况下批量Put的性能对比分析

针对HBase在单column family单column qualifier和单column family多column qualifier两种场景下,分别批量Put写入时的性能对比情况,下面是结合HBase的源码来简单分析解释这一现象. 1. 测试结果 在客户端批量写入时,单列族单列模式和单列族多列模式的TPS和RPC次数相差很大,以客户端10个线程,开启WAL的两种模式下的测试数据为例, 单列族单列模式下TPS能够达到12403.87,实际RPC次数为53次: 单列族多列模式下,TPS只有

《偏向锁,轻量级锁,重量级锁》优缺点对比

<偏向锁,轻量级锁,重量级锁>优缺点对比(Lock的优缺点对比) 锁 优点 缺点 适用场景 偏向锁 加锁和解锁不需要额外的消耗,和执行非同步方法相比仅存在纳秒级的差距 如果线程间存在锁竞争,会带来额外的锁撤销的消耗 适用于只有一个线程访问同步块场景 轻量级锁 竞争的线程不会阻塞,提高了程序的响应速度 如果始终得不到索竞争的线程,使用自旋会消耗CPU 追求响应速度,同步块执行速度非常快 重量级锁 线程竞争不使用自旋,不会消耗CPU 线程阻塞,响应时间缓慢 追求吞吐量,同步块执行速度较长