基于ActiveMQ消息总线的性能测试方法

王 鹏，从 波，李国杰，匡海燕，刘静静

(许继电气股份有限公司，河南 许昌 461000)

0 引 言

当前，互联网和电子行业正在蓬勃发展.软件需要提供更加健壮、 敏捷、 有效的服务[1].随着信息技术的不断进步，互联网技术的飞速发展，日常事务更加依赖于各种各样的IT系统，促使应用系统大量的开发和部署，这些系统极大地提高了企业的信息化程度[2].但同时由于各个系统采用的平台和技术存在很大的差异，导致这些系统彼此互相独立和分离，系统之间的通信变得越来越困难，出现了“信息孤岛”的现象[3].而网络技术的高速发展为此提供了更好的解决方案，计算环境由分布式取代传统的集中式，由消息中间件[4]来提供各系统间的消息传递.

消息总线是一种可以跨越进程的通信机制，用于系统间及上下游的消息传递.消息总线承担系统内实时消息传输功能，为上层应用屏蔽了繁琐复杂的底层通信细节[5].消息总线的引入有效降低了各系统或模块间的耦合程度，但同时消息总线的性能效率也成为影响整个系统性能的关键因素.如何选择能够满足整个系统要求的消息中间件成为系统开发过程中不可缺少的环节.

1 基于ActiveMQ的消息总线介绍

ActiveMQ[6]作为消息中间件，被广泛应用于企业级消息总线的设计.它是由Apache开发并发布的一款开源的消息中间件，具有独立通用的基本特性，支持集群[7]，支持订阅-发布和负载均衡两种消息收发模式[8]，支持持久化和非持久化两种消息存储模式，支持持续和非持续两种订阅模型，具备跨平台的特性，可以适应目前大多数的企业级应用.

本文旨在对ActiveMQ本身的性能层面开展全面的测试和分析，此节将主要从应用的角度，对以下4个性能影响较大的方面展开描述.

1.1 订阅-发布模式

订阅-发布模式，即类似于传统的异步消息收发模式.在“订阅-发布”模式下，所有需要某主题(Topic)的消费者(Consumer)均需要“订阅”该主题(Topic)，而消息生产者(Message)发布该消息后，消息总线会将该消息复制多份，分别发送给所有“订阅”的消费者，如图 1 所示.

图 1 订阅-发布模式消息传递图Fig.1 Sub-pub mode messaging

1.2 负载均衡模式

负载均衡模式，即类似于传统的同步消息收发模式.在“负载均衡”模式下，消息消费者和消息生产者进行“点对点”的方式进行通信.消息生产者(Message)仅会发送消息给一个消息消费者，消息消费者将及时给予回复，实现两者之间的点对点有效通信，如图 2 所示.

图 2 负载均衡模式消息传递图Fig.2 Load balance mode messaging

1.3 持久化消息存储及持续订阅模型

持久化和非持久化消息存储，主要是指消息生产者发布消息之后，消息中心服务器是否进行持久化的存储.

持续订阅和非持续订阅，主要是针对“订阅-发布”模式.即当订阅者注册为持续订阅时，即便订阅者已经下线，“订阅-发布”模式下的队列仍将持续保存消息的发布，直到订阅者获取该条消息为止，与订阅者是否在线无关.

2 主要性能测试内容及方法

在软件测试过程中，性能测试能够评测系统的运行性能，然后结合系统性能来改进软件对于系统的基本运行要求[9].

目前国内外对ActiveMQ消息总线更加关注其消息传递的可靠性，对性能测试研究较少，大多是在形成完整系统后通过黑盒测试方法进行整体验证，而忽略了消息总线本身的性能瓶颈.本文通过白盒的测试方法，直接对消息总线本身进行性能测试.

消息总线主要性能指标将体现在消息的转发延时及转发吞吐量等方面.而基于ActiveMQ设计的消息总线，对其性能测试相关内容的确定，将结合同步及异步的传输模式、 持久化和非持久化存储及持续和非持续订阅等多重组合情况，考虑对转发延时和转发吞吐量的影响.区别于普通的黑盒性能测试方法，本文主要从源码的角度探讨其更加精确的性能数据获取方法.测试框架如图 3 所示，各分布式主机通过测试驱动调用消息中间件服务，从而完成对消息的生产和消费.

图 3 消息中间件测试框架图Fig.3 Message middleware test framework

结合以上描述，本节将从以下几个方面对基于ActiveMQ的消息总线开展性能测试.

2.1 订阅-发布模式转发延时

图 4 订阅-发布模式转发延时测试环境图Fig.4 Sub-pub mode forwarding time-delay test environment

2.2 订阅-发布模式吞吐量

图 5 订阅-发布模式吞吐量测试环境图Fig.5 Sub-pub mode throughput test environment

2.3 负载均衡模式转发延时

图 6 负载均衡模式转发延时测试环境图Fig.6 Load balance mode forwarding time-delay test environmen

2.4 负载均衡模式吞吐量

图 7 负载均衡模式吞吐量测试环境图Fig.7 Load balance mode throughput test environment

2.5 测试设计

以订阅-发布模式吞吐量为例，充分利用开源代码的消息生产函数，以及消息接收回调函数进行消息生产和消费.利用系统纳秒时间获取函数System::nanoTime()获取精确时间，从而计算出更加精确的性能数据.设计主要考虑以下几个方面：

1) 消息消费端接收回调模块： 等待对应消息发布后进入消息消费回调模块，接收到数据后，对其进行验证，并记录接收消息个数，当接收消息达到设置的发送最大条数时，返回一条消息给消息发布端.

2) 消息发布端发送模块： 采用循环调用的方式进行消息批量生产，记录发送初始时钟，即图 4 中的TA1，设置等待消息正确接收标记.

3 测试应用案例

3.1 测试对象架构

由ActiveMQ作为消息中间件[10,11]配置消息中心服务器，将其开放接口进行封装供客户端和控制中心程序使用，基于其订阅-发布和负载均衡两种消息收发模式，实现异步和同步两种通信模式.

异步模式为客户端向控制中心上送消息.客户端作为消息生产者，连接到消息总线，向指定主题(Topic)发送消息，控制中心作为消息消费者，如果订阅了该主题(Topic)，则可以收到该消息.若其它客户端或终端软件对该消息感兴趣，也可以订阅该主题，并会同时收到该消息.

同步模式为控制中心向客户端同步请求数据.控制中心针对某一客户端发出同步数据请求命令，被请求的客户端收到消息后需立即对该消息做出响应并按照同步数据请求命令中指定的目标队列(Queue)返回应答结果.

消息总线性能测试主要架构如图 8 所示.

图 8 消息总线性能测试环境架构图Fig.8 Message bus performance testing environment architecture

3.2 测试软硬件环境配置

测试用的客户端、 控制中心以及消息中心服务器配置如表 1 所示.

表 1 测试软硬件配置环境

3.3 测试结果

结合以上测试方法，对消息总线同步/异步通信方式，以及持久化和非持久化存储，持续和非持续订阅等分别开展测试，结果如下：

1) 异步模式转发延时及吞吐量

转发延时测试时，依次发送100 000条消息，消息长度分别设置为1, 10, 20 KByte 等，通过计算获取其平均转发延时，测试记录如表 2 所示.

表 2 异步模式转发延时记录

吞吐量测试时，一次性发送100 000条消息，消息长度分别设置为1, 10, 20 KByte 等，通过计算获取其转发吞吐量，测试记录如表 3 及表 4 所示.

表 3 异步模式转发消息条数吞吐量记录

表 4 异步模式转发数据量吞吐量记录

2) 同步模式转发延时及吞吐量

同步模式不必考虑存储和订阅方式，一次发送100 000条消息，消息长度分别设置为1, 10, 20 KByte等，通过计算获取其转发延时及吞吐量，如表 5 所示.

表 5 同步模式转发延时及吞吐量记录

3.4 测试分析

通过以上案例应用，该测试方法能够利运用ActiveMQ的开放接口，获取到单条性能数据，同时能够支撑批量性能测试，能够成功获取较为精确的性能数据，对基于ActiveMQ的消息总线应用有一定的指导意义.测试结果显示：

在异步(订阅-发布)模式下，在转发延时方面，选择持久化存储或持久化订阅方案后，实际性能影响并不大，在同一数量级； 在转发吞吐量方面，转发的数据量在消息长度为10 KByte左右时，达到峰值约790 Mbit/s，约占用千兆网络的80%； 转发吞吐量在选择持续订阅且持久化存储模式时，会造成转发吞吐量的明显变化，特别是消息长度较小时(1 KByte)，其数据吞吐量与其他几种模式相差30倍以上.

在同步(负载均衡)模式下，随着数据长度的增加，消息的平均转发延时略有增加，但整体数据吞吐量会明显增大，为提高传输效率，可以适当对短消息进行合并，再进行消息发布.

4 总 结

本文在充分分析基于ActiveMQ消息总线关键性能指标的基础上，提出了从源码角度获取精确性能数据的性能测试方法.结合实际硬件环境，使用该方法对基于ActiveMQ的消息总线开展了性能测试，从异步(订阅-发布)和同步(负载均衡)不同传输模式，持久化和非持久化不同存储方式，以及持续和非持续订阅等角度进行测试分析.结果显示，该方法能够正确获取较为精确的性能数据，找到各种模式下能够发挥最优性能的配置，为基于ActiveMQ消息总线的应用提供参考及改进思路.