基于ActiveMQ消息總線的性能測(cè)試方法

王 鵬，從 波，李國(guó)杰，匡海燕，劉靜靜

(許繼電氣股份有限公司，河南 許昌 461000)

0 引 言

當(dāng)前，互聯(lián)網(wǎng)和電子行業(yè)正在蓬勃發(fā)展.軟件需要提供更加健壯、 敏捷、 有效的服務(wù)[1].隨著信息技術(shù)的不斷進(jìn)步，互聯(lián)網(wǎng)技術(shù)的飛速發(fā)展，日常事務(wù)更加依賴于各種各樣的IT系統(tǒng)，促使應(yīng)用系統(tǒng)大量的開(kāi)發(fā)和部署，這些系統(tǒng)極大地提高了企業(yè)的信息化程度[2].但同時(shí)由于各個(gè)系統(tǒng)采用的平臺(tái)和技術(shù)存在很大的差異，導(dǎo)致這些系統(tǒng)彼此互相獨(dú)立和分離，系統(tǒng)之間的通信變得越來(lái)越困難，出現(xiàn)了“信息孤島”的現(xiàn)象[3].而網(wǎng)絡(luò)技術(shù)的高速發(fā)展為此提供了更好的解決方案，計(jì)算環(huán)境由分布式取代傳統(tǒng)的集中式，由消息中間件[4]來(lái)提供各系統(tǒng)間的消息傳遞.

消息總線是一種可以跨越進(jìn)程的通信機(jī)制，用于系統(tǒng)間及上下游的消息傳遞.消息總線承擔(dān)系統(tǒng)內(nèi)實(shí)時(shí)消息傳輸功能，為上層應(yīng)用屏蔽了繁瑣復(fù)雜的底層通信細(xì)節(jié)[5].消息總線的引入有效降低了各系統(tǒng)或模塊間的耦合程度，但同時(shí)消息總線的性能效率也成為影響整個(gè)系統(tǒng)性能的關(guān)鍵因素.如何選擇能夠滿足整個(gè)系統(tǒng)要求的消息中間件成為系統(tǒng)開(kāi)發(fā)過(guò)程中不可缺少的環(huán)節(jié).

1 基于ActiveMQ的消息總線介紹

ActiveMQ[6]作為消息中間件，被廣泛應(yīng)用于企業(yè)級(jí)消息總線的設(shè)計(jì).它是由Apache開(kāi)發(fā)并發(fā)布的一款開(kāi)源的消息中間件，具有獨(dú)立通用的基本特性，支持集群[7]，支持訂閱-發(fā)布和負(fù)載均衡兩種消息收發(fā)模式[8]，支持持久化和非持久化兩種消息存儲(chǔ)模式，支持持續(xù)和非持續(xù)兩種訂閱模型，具備跨平臺(tái)的特性，可以適應(yīng)目前大多數(shù)的企業(yè)級(jí)應(yīng)用.

本文旨在對(duì)ActiveMQ本身的性能層面開(kāi)展全面的測(cè)試和分析，此節(jié)將主要從應(yīng)用的角度，對(duì)以下4個(gè)性能影響較大的方面展開(kāi)描述.

1.1 訂閱-發(fā)布模式

訂閱-發(fā)布模式，即類(lèi)似于傳統(tǒng)的異步消息收發(fā)模式.在“訂閱-發(fā)布”模式下，所有需要某主題(Topic)的消費(fèi)者(Consumer)均需要“訂閱”該主題(Topic)，而消息生產(chǎn)者(Message)發(fā)布該消息后，消息總線會(huì)將該消息復(fù)制多份，分別發(fā)送給所有“訂閱”的消費(fèi)者，如圖 1 所示.

圖 1 訂閱-發(fā)布模式消息傳遞圖Fig.1 Sub-pub mode messaging

1.2 負(fù)載均衡模式

負(fù)載均衡模式，即類(lèi)似于傳統(tǒng)的同步消息收發(fā)模式.在“負(fù)載均衡”模式下，消息消費(fèi)者和消息生產(chǎn)者進(jìn)行“點(diǎn)對(duì)點(diǎn)”的方式進(jìn)行通信.消息生產(chǎn)者(Message)僅會(huì)發(fā)送消息給一個(gè)消息消費(fèi)者，消息消費(fèi)者將及時(shí)給予回復(fù)，實(shí)現(xiàn)兩者之間的點(diǎn)對(duì)點(diǎn)有效通信，如圖 2 所示.

圖 2 負(fù)載均衡模式消息傳遞圖Fig.2 Load balance mode messaging

1.3 持久化消息存儲(chǔ)及持續(xù)訂閱模型

持久化和非持久化消息存儲(chǔ)，主要是指消息生產(chǎn)者發(fā)布消息之后，消息中心服務(wù)器是否進(jìn)行持久化的存儲(chǔ).

持續(xù)訂閱和非持續(xù)訂閱，主要是針對(duì)“訂閱-發(fā)布”模式.即當(dāng)訂閱者注冊(cè)為持續(xù)訂閱時(shí)，即便訂閱者已經(jīng)下線，“訂閱-發(fā)布”模式下的隊(duì)列仍將持續(xù)保存消息的發(fā)布，直到訂閱者獲取該條消息為止，與訂閱者是否在線無(wú)關(guān).

2 主要性能測(cè)試內(nèi)容及方法

在軟件測(cè)試過(guò)程中，性能測(cè)試能夠評(píng)測(cè)系統(tǒng)的運(yùn)行性能，然后結(jié)合系統(tǒng)性能來(lái)改進(jìn)軟件對(duì)于系統(tǒng)的基本運(yùn)行要求[9].

目前國(guó)內(nèi)外對(duì)ActiveMQ消息總線更加關(guān)注其消息傳遞的可靠性，對(duì)性能測(cè)試研究較少，大多是在形成完整系統(tǒng)后通過(guò)黑盒測(cè)試方法進(jìn)行整體驗(yàn)證，而忽略了消息總線本身的性能瓶頸.本文通過(guò)白盒的測(cè)試方法，直接對(duì)消息總線本身進(jìn)行性能測(cè)試.

消息總線主要性能指標(biāo)將體現(xiàn)在消息的轉(zhuǎn)發(fā)延時(shí)及轉(zhuǎn)發(fā)吞吐量等方面.而基于ActiveMQ設(shè)計(jì)的消息總線，對(duì)其性能測(cè)試相關(guān)內(nèi)容的確定，將結(jié)合同步及異步的傳輸模式、 持久化和非持久化存儲(chǔ)及持續(xù)和非持續(xù)訂閱等多重組合情況，考慮對(duì)轉(zhuǎn)發(fā)延時(shí)和轉(zhuǎn)發(fā)吞吐量的影響.區(qū)別于普通的黑盒性能測(cè)試方法，本文主要從源碼的角度探討其更加精確的性能數(shù)據(jù)獲取方法.測(cè)試框架如圖 3 所示，各分布式主機(jī)通過(guò)測(cè)試驅(qū)動(dòng)調(diào)用消息中間件服務(wù)，從而完成對(duì)消息的生產(chǎn)和消費(fèi).

圖 3 消息中間件測(cè)試框架圖Fig.3 Message middleware test framework

結(jié)合以上描述，本節(jié)將從以下幾個(gè)方面對(duì)基于ActiveMQ的消息總線開(kāi)展性能測(cè)試.

2.1 訂閱-發(fā)布模式轉(zhuǎn)發(fā)延時(shí)

圖 4 訂閱-發(fā)布模式轉(zhuǎn)發(fā)延時(shí)測(cè)試環(huán)境圖Fig.4 Sub-pub mode forwarding time-delay test environment

2.2 訂閱-發(fā)布模式吞吐量

圖 5 訂閱-發(fā)布模式吞吐量測(cè)試環(huán)境圖Fig.5 Sub-pub mode throughput test environment

2.3 負(fù)載均衡模式轉(zhuǎn)發(fā)延時(shí)

圖 6 負(fù)載均衡模式轉(zhuǎn)發(fā)延時(shí)測(cè)試環(huán)境圖Fig.6 Load balance mode forwarding time-delay test environmen

2.4 負(fù)載均衡模式吞吐量

圖 7 負(fù)載均衡模式吞吐量測(cè)試環(huán)境圖Fig.7 Load balance mode throughput test environment

2.5 測(cè)試設(shè)計(jì)

以訂閱-發(fā)布模式吞吐量為例，充分利用開(kāi)源代碼的消息生產(chǎn)函數(shù)，以及消息接收回調(diào)函數(shù)進(jìn)行消息生產(chǎn)和消費(fèi).利用系統(tǒng)納秒時(shí)間獲取函數(shù)System::nanoTime()獲取精確時(shí)間，從而計(jì)算出更加精確的性能數(shù)據(jù).設(shè)計(jì)主要考慮以下幾個(gè)方面：

1) 消息消費(fèi)端接收回調(diào)模塊： 等待對(duì)應(yīng)消息發(fā)布后進(jìn)入消息消費(fèi)回調(diào)模塊，接收到數(shù)據(jù)后，對(duì)其進(jìn)行驗(yàn)證，并記錄接收消息個(gè)數(shù)，當(dāng)接收消息達(dá)到設(shè)置的發(fā)送最大條數(shù)時(shí)，返回一條消息給消息發(fā)布端.

2) 消息發(fā)布端發(fā)送模塊： 采用循環(huán)調(diào)用的方式進(jìn)行消息批量生產(chǎn)，記錄發(fā)送初始時(shí)鐘，即圖 4 中的TA1，設(shè)置等待消息正確接收標(biāo)記.

3 測(cè)試應(yīng)用案例

3.1 測(cè)試對(duì)象架構(gòu)

由ActiveMQ作為消息中間件[10,11]配置消息中心服務(wù)器，將其開(kāi)放接口進(jìn)行封裝供客戶端和控制中心程序使用，基于其訂閱-發(fā)布和負(fù)載均衡兩種消息收發(fā)模式，實(shí)現(xiàn)異步和同步兩種通信模式.

異步模式為客戶端向控制中心上送消息.客戶端作為消息生產(chǎn)者，連接到消息總線，向指定主題(Topic)發(fā)送消息，控制中心作為消息消費(fèi)者，如果訂閱了該主題(Topic)，則可以收到該消息.若其它客戶端或終端軟件對(duì)該消息感興趣，也可以訂閱該主題，并會(huì)同時(shí)收到該消息.

同步模式為控制中心向客戶端同步請(qǐng)求數(shù)據(jù).控制中心針對(duì)某一客戶端發(fā)出同步數(shù)據(jù)請(qǐng)求命令，被請(qǐng)求的客戶端收到消息后需立即對(duì)該消息做出響應(yīng)并按照同步數(shù)據(jù)請(qǐng)求命令中指定的目標(biāo)隊(duì)列(Queue)返回應(yīng)答結(jié)果.

消息總線性能測(cè)試主要架構(gòu)如圖 8 所示.

圖 8 消息總線性能測(cè)試環(huán)境架構(gòu)圖Fig.8 Message bus performance testing environment architecture

3.2 測(cè)試軟硬件環(huán)境配置

測(cè)試用的客戶端、 控制中心以及消息中心服務(wù)器配置如表 1 所示.

表 1 測(cè)試軟硬件配置環(huán)境

3.3 測(cè)試結(jié)果

結(jié)合以上測(cè)試方法，對(duì)消息總線同步/異步通信方式，以及持久化和非持久化存儲(chǔ)，持續(xù)和非持續(xù)訂閱等分別開(kāi)展測(cè)試，結(jié)果如下：

1) 異步模式轉(zhuǎn)發(fā)延時(shí)及吞吐量

轉(zhuǎn)發(fā)延時(shí)測(cè)試時(shí)，依次發(fā)送100 000條消息，消息長(zhǎng)度分別設(shè)置為1, 10, 20 KByte 等，通過(guò)計(jì)算獲取其平均轉(zhuǎn)發(fā)延時(shí)，測(cè)試記錄如表 2 所示.

表 2 異步模式轉(zhuǎn)發(fā)延時(shí)記錄

吞吐量測(cè)試時(shí)，一次性發(fā)送100 000條消息，消息長(zhǎng)度分別設(shè)置為1, 10, 20 KByte 等，通過(guò)計(jì)算獲取其轉(zhuǎn)發(fā)吞吐量，測(cè)試記錄如表 3 及表 4 所示.

表 3 異步模式轉(zhuǎn)發(fā)消息條數(shù)吞吐量記錄

表 4 異步模式轉(zhuǎn)發(fā)數(shù)據(jù)量吞吐量記錄

2) 同步模式轉(zhuǎn)發(fā)延時(shí)及吞吐量

同步模式不必考慮存儲(chǔ)和訂閱方式，一次發(fā)送100 000條消息，消息長(zhǎng)度分別設(shè)置為1, 10, 20 KByte等，通過(guò)計(jì)算獲取其轉(zhuǎn)發(fā)延時(shí)及吞吐量，如表 5 所示.

表 5 同步模式轉(zhuǎn)發(fā)延時(shí)及吞吐量記錄

3.4 測(cè)試分析

通過(guò)以上案例應(yīng)用，該測(cè)試方法能夠利運(yùn)用ActiveMQ的開(kāi)放接口，獲取到單條性能數(shù)據(jù)，同時(shí)能夠支撐批量性能測(cè)試，能夠成功獲取較為精確的性能數(shù)據(jù)，對(duì)基于ActiveMQ的消息總線應(yīng)用有一定的指導(dǎo)意義.測(cè)試結(jié)果顯示：

在異步(訂閱-發(fā)布)模式下，在轉(zhuǎn)發(fā)延時(shí)方面，選擇持久化存儲(chǔ)或持久化訂閱方案后，實(shí)際性能影響并不大，在同一數(shù)量級(jí)； 在轉(zhuǎn)發(fā)吞吐量方面，轉(zhuǎn)發(fā)的數(shù)據(jù)量在消息長(zhǎng)度為10 KByte左右時(shí)，達(dá)到峰值約790 Mbit/s，約占用千兆網(wǎng)絡(luò)的80%； 轉(zhuǎn)發(fā)吞吐量在選擇持續(xù)訂閱且持久化存儲(chǔ)模式時(shí)，會(huì)造成轉(zhuǎn)發(fā)吞吐量的明顯變化，特別是消息長(zhǎng)度較小時(shí)(1 KByte)，其數(shù)據(jù)吞吐量與其他幾種模式相差30倍以上.

在同步(負(fù)載均衡)模式下，隨著數(shù)據(jù)長(zhǎng)度的增加，消息的平均轉(zhuǎn)發(fā)延時(shí)略有增加，但整體數(shù)據(jù)吞吐量會(huì)明顯增大，為提高傳輸效率，可以適當(dāng)對(duì)短消息進(jìn)行合并，再進(jìn)行消息發(fā)布.

4 總 結(jié)

本文在充分分析基于ActiveMQ消息總線關(guān)鍵性能指標(biāo)的基礎(chǔ)上，提出了從源碼角度獲取精確性能數(shù)據(jù)的性能測(cè)試方法.結(jié)合實(shí)際硬件環(huán)境，使用該方法對(duì)基于ActiveMQ的消息總線開(kāi)展了性能測(cè)試，從異步(訂閱-發(fā)布)和同步(負(fù)載均衡)不同傳輸模式，持久化和非持久化不同存儲(chǔ)方式，以及持續(xù)和非持續(xù)訂閱等角度進(jìn)行測(cè)試分析.結(jié)果顯示，該方法能夠正確獲取較為精確的性能數(shù)據(jù)，找到各種模式下能夠發(fā)揮最優(yōu)性能的配置，為基于ActiveMQ消息總線的應(yīng)用提供參考及改進(jìn)思路.