RocketMQ性能测试结果

0. 测试环境

阿里云,内存型R5,2核16G内存,5台机器。

RocketMq部署采用Docker,自己定制了镜像,参见:docker-rocketmq

1. 单机测试

单机: NameServer、Broker、Test程序都部署在一台机器上。

1.1 单机 发送线程与TPS

此时默认msgLen=100,主要看线程数的增加,对于同步发消息性能的影响。

可以看到12个线程后,TPS ~= 12K/s,之后线程数再增加,也不会有很大增长了。

我选用的R5机器,只有2个核心,而且应该是有其他隔离限制,所以性能不太高,之后可以换更好的机器再测试。

1.2 单机 消息长度与TPS

此时固定线程数为8,主要看消息长度的增加,对于同步发消息性能的影响。

这里看到影响不太明显,并且TPS普遍偏低。

分析了下。主要原因是

  1. 都部署在一台机器上,有一定相互影响
  2. 当时物理机可能有别人在搞事情,导致资源受限

后面的集群测试,结果比较符合预期。

2. 集群测试

集群测试: 1台ns,3台broker(master only no slave 异步刷盘),打压单独1台

2.1 集群 线程数与TPS

固定30个topic,均匀分布到3台broker上

可以看到,TPS可以打到25k,大概是单机的2倍。

2.2 集群 消息长度与TPS

和上面单机测试相比,集群测试结果符合预期。

即随着消息长度增加,TPS逐渐下降。

对于常见长度(msgLen < 1k),下降不太明显。

2.3 集群 Topic数量与TPS

测试topic数量对同步发消息的影响。

500个topic平均分配到3台broker上。

结论是至少在500个Topic内,没有太大影响。

打压程序用Java写的,放到了github上,perf-rocketmq,供参考。

另外,我这里用的阿里云ECS,性能难免受限,各位感兴趣,可以用更好的机器测一下。

欢迎汇报更好的测试结果。

附原始打压数据:

 

 

Leave a Reply

Your email address will not be published.