RocketMQ（五）性能测试报告

版权声明：本文为博主原创文章，未经博主允许不得转载。

目录(?)[+]

1 概述

1.1 编写目的

测试RocketMQ的写数据、读数据性能及稳定性

1.2 适用范围

对RocketMQ感兴趣的读者。

1.3 术语表

nameserver：

专为RocketMQ设计的轻量级名称服务。

producer：

消息生产者，负责生产消息，一般由业务系统负责生成消息。

consumer：

消息消费者，负责消费消息，一般是后台系统负责异步消息。

broker：

消息中转角色，负责存储消息，转发消息。

master：

broker中的主节点。

slave：

broker中的副节点。

异步复制：

消息写入master节点，再由master节点异步复制到slave节点，类似MySQL中的master-slave机制。

同步双写：

消息同时写入master节点和slave节点。

异步刷盘：

Broker的一种持久化策略，消息写入pagecache后，直接返回。由异步线程负责将pagecache写入硬盘。

同步刷盘：

Broker的一种持久化策略，消息写入pagecache后，由同步线程将pagecache写入硬盘后，再返回。

TPS：

每秒钟发送的消息个数。

1.4 参考资料

官方网站上的： 

1. RocketMQ用户指南 

2. RocketMQ原理简介 

3. RocketMQ最佳实践

2 性能测试目的

测试RocketMQ的写入、读取性能及稳定性。

3 测试环境

3.1 硬件环境（物理架构）

8台服务器（编号1~8）
nameserver部署在1上
1~2用于部署producer
3~6用于部署broker
7~8用于部署consumer

每台服务器均为以下硬件配置
CPU：E5-2420、8核*2、1.9G主频
内存：32G
硬盘：1T、RAID10

3.2 软件环境（逻辑架构）

每台服务器均为以下软件配置
操作系统：centos（内核 linux 2.6.32-358.el6.x86_64）
JDK：1.6（Java HotSpot 64-Bit Server VM）

4 软件整体性能评价

4.1 预期指标

预期RocketMQ可以满足日常业务性能需求。

4.2 实际表现

经过测试，RocketMQ稳定性高，未出现无法写入或读取的情况，未出现内存占用过高的情况。2台master、2台slave组成的broker集群，消息大写为2kb时，写入速度可达每秒60多MB，日可处理数据量约为7.2亿条，性能可以满足需求。

5 测试过程与具体结论

1）测试场景一 

1台生产者、1台broker、1台消费者，broker采用异步刷盘。消费者为1个线程，push消费模式。 
测试线程数和消息大小对TPS和吞吐量的影响。

测试结果1： 



测试结果2： 


 

以上测试情况消费者均能及时消费（延迟很小）

结论1： 
消息大小固定（2KB）时，随着生产者线程数的增加，TPS和吞吐量均会上升， 

但当线程增加到数量后，TPS和吞吐量会有所下降。 



结论2： 
生产者线程数（ 32个）固定时，随着消息大小的增加，TPS会先升后降， 

吞吐量会逐渐提升。 



2）测试场景二 

2台生产者，4台broker（2台master、2台slaver构成2个broker集群），2台消费者。每台生产者开启10个线程，消息均为2KB。每台消费者为1个线程，push消费模式。 
测试broker主从模式和写盘模式对TPS和吞吐量的影响

1、异步复制、异步刷盘的测试结果： 



2、异步复制、同步刷盘的测试结果： 



3、同步双写、异步刷盘的测试结果： 



4、同步双写、同步刷盘的测试结果 



结论：

同步双写模式比异步复制模式性能稍低，但不明显。

同步刷盘模式比异步刷盘模式性能低很多。

3）测试场景三 

2台生产者，4台broker（2台master、2台slave构成2个broker集群），2台消费者。每台生产者开启10个线程，消息大写均为2KB。每台消费者为1个线程，push消费模式。broker采用异步复制、异步刷盘模式。连续运行8小时。 
测试稳定性。

测试结果： 

所有消息均成功发送。具体结果可查看“rocketmq测试结果记录/2p-2m(异步复制-异步刷盘)-2s-2c-8小时稳定性测试”。

4）测试场景四 

2台生产者，4台broker（2台master、2台slave构成2个broker集群），2台消费者。每台消费者为一个线程，push消费模式。broker采用异步复制、异步刷盘模式。 
测试当前软硬件配置下broker极限写入速度。


 

以上测试情况消费者均能及时消费（延迟很小）。

结论： 
当前软硬件配置下，broker集群可以达到60多MB的写入速度（如果继续增加消息大小。还可以提高写入速度）。