EQueue 2.0 性能测试报告

小程序：扫一扫查出行
【扫一扫了解最新限行尾号】
复制小程序

前言

最近用了几个月的时间，一直在对EQueue做性能优化。到现在总算告一段落了，现在把一些优化的结果分享给大家。EQueue是一个分布式的消息队列，设计思路基本和阿里的RocketMQ一致，只是是用纯C#写的，这点大家应该都知道了。

EQueue开源地址：https://github.com/tangxuehua/equeue
EQueue相关文档：http://www.cnblogs.com/netfocus/category/598000.html
EQueue Nuget地址：http://www.nuget.org/packages/equeue

之前EQueue 1.*版本，消息持久化是使用SQLServer的，之前也想做性能测试，但发现效果不理想。所以放弃了测试，转为专心对消息持久化这块进行优化。之前的持久化设计是通过Sql Bulk Copy的方式异步批量持久化消息。但是当数据库服务器和Broker本身部署在不同的服务器上时，持久化消息也会走网卡，消耗带宽，影响消息的发送和消费的TPS。而如果数据库服务器部署在Broker同一台服务器上，则因为SQLServer本身也会消耗CPU以及内存，也会影响Broker的消息发送和消费的TPS。所以，经过考虑后，最终决定狠下心来，采用终极方案来持久化消息，就是通过本地顺序写文件的方式来持久化消息。支持异步刷盘和同步刷盘两种方式。采用文件存储后，EQueue可以轻易的支持大量消息的堆积，你的硬盘有多大，就能堆积多少量的消息。

到现在为止，经过不断的测试，功能上我认为已经比较稳定了，性能也基本满足我的要求。另外，EQueue单纯的消息持久化模块（MessageStore）以及TCP通信层的性能是非常高的。MessageStore我设计时，尽量独立一些，因为我发现写文件和读文件的设计是通用的，以后可以被复用到其他项目，所以我设计时，确保持久化模块的通用性；而TCP通信层，也是也是一样，通用和高效。目前我自己写的通信层（在ECommon类库中）可以轻松把网卡压满。

关于EQueue 2.0文件持久化版本的具体设计，我下一篇文章会具体介绍，本文主要是想分享一下EQueue 2.0的性能测试结果。为大家在使用到线上环境前做架构选型给出性能方面的参考。

测试目的

测试单个EQueue Broker服务器的发送消息、消费消息的性能。

硬件环境

全部采用UCloud云主机进行测试。一台Broker，4台Client机器。Broker的配置为8核16G内存，120G的SSD硬盘，Client的配置为4核8G内存，普通硬盘。所有服务器操作系统均为Windows Server 2012。具体如下图所示：

测试场景1

1台生产者、1台消费者、1台Broker，异步刷盘，每隔100ms刷一次盘。

消息大小（字节）	发送TPS	消费TPS	发送网络吞吐量	消费网络吞吐量	Broker磁盘写入吞吐量	Broker CPU	Broker内存	Producer CPU	Producer内存	Consumer CPU	Consumer内存
128	56400	56400	10MB	13MB	13MB	35%	35%	30%	12%	30%	13%
512	41000	41000	22MB	25MB	25MB	32%	35%	30%	13%	30%	13%
1024	29000	29000	30MB	34MB	34MB	32%	35%	27%	12%	25%	13%
2048	20000	20000	41MB	43MB	43MB	30%	35%	27%	12%	25%	13%

测试场景2

2台生产者、2台消费者、1台Broker，异步刷盘，每隔100ms刷一次盘。

消息大小（字节）	发送总TPS	消费总TPS	发送总网络吞吐量	消费总网络吞吐量	Broker磁盘写入吞吐量	Broker CPU	Broker内存	Producer CPU	Producer内存	Consumer CPU	Consumer内存
128	50000	50000	8.6MB	11MB	11MB	46%	35%	19%	13%	19%	13%
512	40000	40000	21MB	24MB	24MB	48%	35%	19%	13%	19%	13%
1024	31200	31200	32MB	35MB	35MB	47%	35%	19%	13%	19%	13%
2048	23000	23000	48MB	51MB	51MB	45%	35%	19%	13%	19%	13%

结束语

一些说明

因为EQueue的Producer发送消息时，本地会有缓存队列。所以Producer发送消息采用的线程数对发送TPS并无什么影响。所以，我上面的测试中并没有考虑发送线程数；
Broker的内存使用我们是可以控制的，我测试时配置为当内存使用到达40%时，开始自动清理内存，所以上面的测试结果，内存使用都不会超过40%；
因为消费者从Broker拉取消息时，EQueue的设计在内存足够的情况下，总是会将需要消费的消息缓存在非托管内存，所以消费者拉取消息时，总是从内存获取消息的。所以Broker没有磁盘的读取；且由于这个设计，消费者消费消息不会成为瓶颈，假设当前Broker上存在大量消息可以被消费，然后我们开一个Consumer，那消费速度是非常快的，1K大小的消息，10W TPS没有问题。所以，消息的消费不会成为瓶颈，除非消费者自己内部处理消息的代码太慢。这种情况下，消费者需要增加Consumer机器，确保消费速度跟得上发送速度。
上面的测试结果是基于UCloud的虚拟机，由于我没有物理机，所以不知道物理机上的性能。有条件的朋友我非常希望能帮忙测试下哦。像这种重要的分布式消息队列服务器，是应该部署在物理机上的。另外，我测试时，Producer和Consumer服务器使用的是普通的虚拟机，尽量真实的模仿一般应用的虚拟机配置。

测试结论

从上面的测试结果可知：

随着消息体的不断增大，发送消息的TPS不断降低，一般我们的消息大小为1KB，在有两个发送者客户端时，EQueue的发送消息TPS大概为31000。我觉得性能上应该满足大部分需求场景了。如果一个系统平均每秒产生31200个消息，一天是86400秒。那一天的消息量是27亿。这个数字已经很大了，呵呵。相信国内大部分网站都没有这么大的规模。当然我们不能这么简单的来算，实际的系统肯定有高峰期的，实际大家要根据自己的系统的高峰期发送消息的TPS来衡量具体要部署多少台EQueue Broker服务器。线上环境使用时，我们不能把Broker压满的，要给其有足够的处理余量，比如高峰期发送TPS为10W，每台Broker最大能承受3W，那我们至少要分配6台机器，确保应付可能出现的高峰。这样才能应付特别高的高峰。
大家可以看到上面的数据中，开两个生产者，两个消费者，消息大小为2KB时，Broker的进出总网络流量为99MB，这个数据还没有到达千兆网卡的总流量（125MB）。目前，我只申请了5台机器，4个客户端机器。但实际我们的应用的集群，客户端机器应该会更多，我不知道当客户端机器增加时，能否把Broker的网卡压满，如果压不满，则说明Broker本身的设计实现已经到达瓶颈了，也就是说EQueue Broker本身设计上可能还有性能优化的空间。
在上面的性能数据情况下，所有服务器的CPU，内存使用稳定，符合预期。在稳定性方面，我在个人笔记本上同时发送和消费消息，连续运行1天没有问题；也有其他网友帮忙测试了稳定性，运行几天也没有问题。各项指标均正常。所以我认为目前EQueue的稳定性应该问题不大了。
Broker的消息持久化，采用的是顺序写文件的方式；目前的测试结果来看，完全还没达到写文件的瓶颈；如果我们单独测试写文件模块的性能，可以轻松达到300MB每秒，而我们的千兆网卡最大流量也只有125MB。所以，消息持久化不会再成为很大的瓶颈了，但写文件的响应时间本身也会影响Broker对外的TPS，目前的响应时间为60ms，我感觉是比较慢的，不知道是否是虚拟机的原因，不知道物理机上会如何。我觉得SSD硬盘，写入文件的响应时间不会这么慢的。
最后一点，当Broker的客户端增加时，Broker的CPU的使用也会相应增加一点。这个可以理解，因为TCP长连接的数量多了一倍。而生产者和消费者服务器的CPU内存的使用都非常稳定，符合预期。