你的位置:首页 > ASP.net教程

[ASP.net教程]EQueue 2.0 性能测试报告


前言

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

  1. EQueue开源地址:https://github.com/tangxuehua/equeue
  2. EQueue相关文档:http://www.cnblogs.com/netfocus/category/598000.html
  3. 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,异步刷盘;

消息大小(字节) 发送TPS 消费TPS 发送网络吞吐量 消费网络吞吐量Broker磁盘写入吞吐量 Broker CPUBroker内存Producer CPUProducer内存Consumer CPUConsumer内存
 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,异步刷盘;

消息大小(字节) 发送总TPS 消费总TPS 发送总网络吞吐量 消费总网络吞吐量Broker磁盘写入吞吐量 Broker CPUBroker内存Producer CPUProducer内存Consumer CPUConsumer内存
 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%

结束语

一些说明

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

测试结论

从上面的测试结果可知:

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