ActiveMQ极限性能参数测试结果

本文详细介绍了对ActiveMQ在Queue模式下进行极限性能测试的过程,涉及发送、接收和并发处理能力的评估。测试环境包括特定的硬件配置和多台虚拟机。结果显示,单发送吞吐量峰值约1700,单接收性能受数据库中未接收消息数量影响,而发送接收同步时,两者吞吐量相互影响,数据库查询成为接收性能瓶颈。


       ActiveMQ作为当前最流行的开源JMS实现,已经大量使用在运营产品中,售中产品也将使用ActiveMQ作为消息中间件JMS主要有两种工作模式:点对点模式(point-to)和发布/订阅模式(Publish/Subscribe),有些地方也称为面向队列模式(queue)和面向主题模式(topic)。本次根据RD需求只对Queue模型信息交互模式进行极限性能测试。

       测试中,需要部署三种抽象进行Queue模型消息模拟,分别是生产者、消费者和消息队列。根据RD需求,消息队列使用ActiveMQ并采用MySQL的Persistence的模式进行接收和发送工作;消费者和生产者,采用JMS原生接口和线程池模拟并发进行性能测试。

主要测试的ActiveMQ模拟的三个场景,分别是:第一,只发送不接收,测试出消息队列发送的极限;第二,只接收不发送,测试出消息队列对应消费者的极限;第三,发送接收同时工作,测试出消息队列的处理极限。

发送信息每个数据包为cust表一行数据的字符串长度和一个JAVA时间戳,大小大约为0.5KB左右。一个测试样本一个线程的发送数/接收量为10万条,从1条线程开始测试,每次增加3条行程(三台测试机一台增加1),直到吞吐量出现拐点(吞吐量为每秒发送数据条数)。

       ActiveMQ开源中间件和配合消息队列持久化的MySQL部署在:

db-testing-ecom380.db01.baidu.com物理机

CPU   Intel(R) Xeon(R) CPU E5620 @ 2.40GHz 8核 MEM  64G

模拟多线程发送和接收的工作采用JAVA编写,分别部署在3台机器上:

cq01-testing-sf113.vm.baidu.com    虚拟机

CPU   Intel(R) Xeon(R) CPU E5645 @ 2.40GHz 4核 MEM  16G

cq01-testing-sf114.vm.baidu.com    虚拟机

CPU   Intel(R) Xeon(R) CPU E5645 @ 2.40GHz 4核 MEM  16G

cq01-testing-ecom-sfcrm04.vm.baidu.com虚拟机

CPU   Intel(R) Xeon(R) CPU E5645 @ 2.40GHz 2核 MEM  16G

因为Jmeter提供的JMS测试Sample提供的接收发送服务不够灵活不能满足测试需求,因此只采用Jmeter测试工具对我所开发的测试工具进行验证。

       单开发送功能,吞吐量的峰值为:1700左右;峰值时,线程数为60。

单接收送功能,吞吐量的峰值为:;峰值时,线程数为。需要注意如果数据库里堆积大量未接收消息数据,接收效率将大大受到影响

同时开启收发功能,发送吞吐量的峰值为:1000左右;同时开启发送功能,接收吞吐量的峰值为:1000左右;峰值时,线程数分别为接收18-30,发送3-30。

要注意一点,在发送接收同步的时候,它们的吞吐量是相互影响的。接收数据是要对MySQL数据库进行查询操作,接收性能瓶颈主要在数据库ACTIVEMQ_MSGS表的查询上,ACTIVEMQ_MSGS的数量级对接收性能影响很大

1.       单发送模式:(7个CASE)

       只列举出了有代表性的几组数据:

线程数

1

3

12

18

30

60

90

吞吐量

416

1115

1213

1420

1250

1732

1233

         整个测试期间CPU、内存都无太大波动,不会对性能构成影响,activeMQ启动后整个测试代码运行过程中,MEM使用率一直低于1%;CPU也无太大波动,最高利用率到达70%但没有持续超过20s。

 

2.       单接收模式(7个CASE)

接收的性能及吞吐率与ActiveMQ依赖的持久化库内的消息数量有关,例如数据库中有100万条数据的接收效率和只有2万条的接收数量相差多达100倍左右,这个应该是接收数据是要对MySQL数据库进行查询操作,接收性能瓶颈主要在数据库ACTIVEMQ_MSGS表的查询上,ACTIVEMQ_MSGS的数量级对接收性能影响很大。因此这里都以读取1万条消息数据的背景为测试样本,只列举出了有代表性的几组数据:

线程数

1

3

9

18

30

60

吞吐量

55

102

231

281

335

815

下面固定用30个线程分别取不同数据量背景下的吞吐量:

数据量

900

9000

90000

900000

吞吐量

450

365

90

5.5

 

3.       发送接收同步模式(35个CASE)

只列举出了有代表性的几组数据:(线程数)

发送

接收

1

3

6

9

18

24

30

1

239|142

180|112

162|127

158|136

153|146

155|146

156|150

3

309|214

582|448

391|344

367|338

369|342

276|250

338|323

6

171|153

545|507

484|411

470|413

419|385

445|408

438|405

9

154|147

1015|937

1029|978

917|865

722|569

711|621

667|612

18

673|654

1030|1016

1048|1028

1042|989

1029|1005

1048|1017

1048|1016

 

接收的消费者随着线程的增加,吞吐量基本稳定在1000左右,因此不在提供更多接收线程数的测试数据。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值