基于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消息總線的應用提供參考及改進思路.