原文地址：http://www.51testing.com/html/78/23978-143163.html

1.測試概要
1.1 關于
這篇文檔中涉及的基于JMS的消息系統能為應用程序提供可靠的，高性能的，異步的通訊機制。在不同的JMS解決方案中，性能是關鍵因素，但不是唯一的因素。每個方案都有不可比擬的屬性和特性，還要考慮諸如實現難易、有效性、獲得支持的性價比，等等。另外，標準的性能測試只能近似模擬各個企業的特定需求下的真實環境。
1.2 測試人員和工作量
測試人：nb_bull
工作量：50小時
1.3 測試方案
基于JMS的消息傳遞分為兩方面，基于隊列的點對點模式和對于主題的發布-訂閱模式，這次主要針對Topic方式執行測試。
測試中每個發送者和接收者所發送和接收的消息數目都將被記錄。數值采樣將會從測試系統初始化完成時開始，并在規定的時間段內持續進行，于系統開始關閉前結束.
1.4 測試環境與配置
所有的測試都在兩臺服務器（主從）上完成，消息消費者和提供者被安裝在x86的機器上，配置為2.40G CPU和1.0GB內存，操作系統為Windows?XP，所有機器在同一個網段的局域網內相連。
1.5 測試場景
1.5.1 集群類型
本次性能測試主要測試比較幾種Master-Slave集群配置方案和默認配置，我們對每個JMS項目采用默認的out-of-the-box配置。
a.Pure Master Slave
b.Shared File System Master Slave
c.JDBC Master Slave（DB only）（采用默認數據源）
d.JDBC Master Slave(File&DB）（采用c3P0數據源）
e.單點非集群模式
1.5.2 測試場景
單個提供者，單個用戶，和單個主題或隊列（1 producer, 1 subscriber, and 1 topic）
1.5.3 消息配置
java.naming.provider.url：tcp://localhost:61616?jms.useAsyncSend=true&wireFormat.maxInactivityDuration=0
消息發布時采用異步發送流（useAsyncSend）模式，加入wireFormat.maxInactivityDuration=0 這樣的參數，避免ActiveMQ在一段時間沒有消息發送時拋出 "Channel was inactive for too long"異常。
消息內容：
<?xml version="1.0" encoding="UTF-8" ?><message><messageVersion>2</messageVersion><transactionId>17584926994300501924</transactionId><feeCode>2HSKYYXC</feeCode><spcode>11</spcode><phoneNum>13886344486</phoneNum><hsMan>rebound</hsMan><hsType>f420</hsType><vmVer>1940</vmVer><hsVer>101935</hsVer><imei>135790246811220</imei><imsi>460005804931145</imsi><appId>400001</appId><appVer>-1</appVer><feetype>0</feetype><provider>1</provider><reserve>0</reserve><moTime>20090708175847</moTime><cost>2.0</cost><chargeVer>0</chargeVer><application>0</application><module>0</module><appcontext>ABcWEwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==</appcontext></message>
消息大小646字節，會被消息產生者重復使用。
1.5.4 ActiveMQ相關
部署的ActiveMQ版本為現網部署的5.1.0版本。
采用AMQ Message Store的ActiveMQ缺省持久化存儲方式，所有方案持久化使能persistent=”true”,日志等級設置為INFO。持久化時配置增大ActiveMQ緩存大小，<policyEntry queue=">" memoryLimit="100mb"/><policyEntry topic=">" memoryLimit="100mb"/>。
1.5.5.測試方案
方案一：在測試PC1上使用測試腳本往ActiveMQ集群以non-persistent方式異步發布JMS消息，在測試PC2上采用jmeter非持續訂閱（non-durable Subscrition）方式接收消息。
方案二：在測試PC1上使用測試腳本往ActiveMQ集群以persistent方式異步發布JMS消息，在測試PC2上采用jmeter非持續訂閱（non-durable Subscrition）方式接收消息。
方案三：在測試PC1上使用測試腳本往ActiveMQ集群以persistent方式異步發布JMS消息，在測試PC2上采用開發人員提供的監聽模塊持續訂閱（durable Subscrition）方式接收消息。

2測試結果及缺陷分析
2.1 測試執行情況與記錄
2.1.1方案一
Publish: non-persistent, useAsyncSend
Subscrition:non-duration(jmeter listen)
主題模式：1 producer, 1 subscriber, and 1 topic
ActiveMQ集群方案?每秒消息數(msg/sec)
Pure Master Slave?7541
Shared File System Master Slave?7760
?JDBC Master Slave（DB only）?7260
JDBC Master Slave（File&DB）?7681
單點非集群模式?8226
數字代表在每個測試時間間隔中每秒發送的消息數。數值越高代表性能越好。
測試中發布的消息被jmeter迅速接收處理，各種部署方式數據處理性能接近。
2.1.2方案二
Publish: persistent, useAsyncSend
Subscrition:non-duration（jmeter listen）
主題模式：1 producer, 1 subscriber, and 1 topic
ActiveMQ集群方案?每秒消息數(msg/sec)
Pure Master Slave?6663
Shared File System Master Slave?7189
JDBC Master Slave（DB only）?7002
JDBC Master Slave(File&DB）?7052
單點非集群模式?7471
數字代表在每個測試時間間隔中每秒發送的消息數。數值越高代表性能越好。
測試中發布的消息被jmeter迅速接收處理，各種部署方式數據處理性能接近。
2.1.2方案三
Publish: persistent, useAsyncSend
Subscrition:duration(采用開發人員提供的subscription模塊)
主題模式：1 producer, 1 subscriber, and 1 topic
ActiveMQ集群方案?每秒消息數(msg/sec)
Pure Master Slave?\
Shared File System Master Slave?25
JDBC Master Slave（DB only）默認數據源?3
JDBC Master Slave(File&DB）采用c3P0數據源?22
單點非集群模式?55
該方案采用開發人員提供的訂閱模塊進行對集群進行持續訂閱，測試中可以發現：
1.由于該訂閱模塊的處理能力較差，導致大量發送數據的堆積擁塞，每秒的處理消息能力糟糕。
2.JDBC模式使用c3P0數據源后，運行效率更加穩定和高效。
3.Pure Master Slave在此測試場景下，由于數據的大量擁塞迅速失去響應。

3測試結論與建議
3.1 測試結論
1.Pure Master Slaver集群方式重新啟動MQ服務后原來連著的用戶發送訂閱消息，MQ會一直提示”Cannot lookup a connection that had not been registered”（ActiveMQ5.1）。
2. JDBC Master Slave（DB only）集群方式使用默認數據源進行測試時，頻繁寫入數據庫，導致性能低下，MQ日志開始頻繁報出“ERROR StoreDurableSubscriberCursor?? - Failed to get current cursor”的錯誤信息，JDBC Master Slave(File&DB）集群方式，使用默認數據源進行測試時，系統日志頻繁報出“ERROR JournalPersistenceAdapter –Failed to checkpoint a message store: java.util.concurrent.ExecutionException: java.io.IOException: Already started. ”（更換了c3P0數據源后該問題可解決）。

3.Shared File System Master Slave在本次采用activeMQ5.1進行集群測試的時候也發現了一個BUG，在集群運行一段時候后會出現slave MQ的crash，日志顯示為“java.io.FileNotFoundException: **/*****/***/******/journal/control.dat (Too many open files)”，在ActiveMQ的網站上找到了該BUG的錯誤報告。可通過升級到ACtiveMQ5.3或下載一個補丁jar包放到lib的方式來解決。
3.目前開發提供的數據訂閱模塊在可持續訂閱（duration）時處理效率較差，后續需要進行優化。
3.2 部署建議
1．Increase the memory limit of the broker in activemq.xml，在實際上線時需要評估消息發布、接送之間的msg流量差，增大memory limit，如512MB或更大,同時需要注意配置分配給ActiveMQ的JVM內存是大于該配置容量。
2.建議以后對持續訂閱模塊進行性能評估后再上線部署，以防止消息訂閱者性能低下而在ActiveMQ上造成數據堵塞；并保證持續訂閱者的穩定性，避免出現長時間掉線的情況，測試證明消息堵塞對MQ性能的影響是很嚴重的。也可以通過配置消息生存時間、配置自動清除緩存等方式解決該隱患。
3.如果使用數據庫模式的話建議使用c3p0的數據源。
4.使用non-persistent 方式速度較快，對于偶爾丟失少量數據不敏感的應用極為適合。

至此，該階段的集群性能評估已經可以告一段落，完整診斷以后系統性能的瓶頸主要是在持續訂閱模塊上。而采用c3po數據源后的JDBC Master Slave性能與Shared File System Master Slave?性能比較接近。Pure Master Slave的問題在apache網站上搜索據說該BUG已在ActiveMQ5.2后fixed,不過鑒于該集群方案的穩定性和以及故障后本身固有的處理缺陷暫不采用。

順便提及jmeter在測試JMS中碰到的幾個問題：

1.Jmeter默認的傳送方式是同步:在集群時可以在jndi中采用failover:(tcp://172.16.11.241:61616,tcp://172.16.11.242:61616)?jms.useAsyncSend=true這樣的方式修改為異步方式。

2.jmeter默認采用非持久（non-persist)發布：這個貌似在發布/訂閱模式下無法修改，很奇怪在隊列模式下是有該切換選項的。

3.jmeter默認采用非持續（non-duration)訂閱：這個也貌似無法修改。

4.jmeter的訂閱模塊有一個BUG：要使用listen方法監聽系統必須先切換到receive方式再切換回來才能生效。

可見jmeter對JMS測試的支持仍然是不夠完善的，如果要全面的測試JMS各種發布訂閱模型，還是不得不采用手寫測試腳本的方法去完成。

轉載于:https://www.cnblogs.com/davidwang456/p/4515041.html

總結

以上是生活随笔為你收集整理的使用jmeter对ActiveMQ集群性能方案进行评估--转载的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。