Rabbitmq 性能測試

背景：

線上環境，出了一塊兒事故，初步定位是rabbitmq server。

經過抓包發現，是有多個應用使用同一臺rabbitmq server。而且多個應用使用rabbitmq的方式也不同。發現有如下兩種方式：

1. 每次produce 一條消息，開閉channel一次

2. 每次produce 一條消息，開閉connection一次，開閉channel一次。

這種使用方法是咱們懷疑的一個點，除此以外還有懷疑的點有：

1. rabbitmq cluster的配置問題

2. rabbitmq server的硬件問題(體如今磁盤的io_wait 升高，tcp鏈接數的上升)

3. rabbitmq 自己的問題？

4. 網絡抖動和網絡延遲？

 

由於可能性比較多，因此，作一次全面的評估和定位仍是有必要的。

有些任務交給IT和運維去追蹤了。我這邊主要負責一下客戶端使用方式的評估

目標：

1. 確認使用兩種使用方法(見上文)，是否會形成瓶頸？

2. 確認兩種使用方法，在什麼狀況下會出問題？是否會百分百能夠重現？

從理論上，rabbitmq文檔，以及抓包數據來講：每條消息開關一次connection 必然是效率最低的。

試想一下，每條消息體，須要創建和關閉一條tcp鏈接，中間還要摻雜着AMQP的控制報文，多麼的浪費資源！！！！

簡單的測評結果以下：

方法描述	高峯消息量	參數	備註
共用一個connection，每條消息開關一次channel。	2000msg/s	1個線程，無消費者	使用本機Rabbitmq,本地java client
每條消息開關一次connection	200msg/s	1個線程，無消費者	使用本機Rabbitmq,本地java client

 

 

 

 

 

 

上面這個結果是一個簡單的測試結果。

在嘗試混合使用兩種模式訪問本地rabbitmq的時候，出現了一下問題。問題也很奇怪，有一個方法的進程啓動後，另一種就會SocketTimeout。

 

後面只好在測試環境找了臺Rabbitmq Server。

而後google了一把，原來有個jmeter-rabbitmq-plugin。太帥了。功能不全是本身要的，不要緊，改唄。代碼參見：https://github.com/lykm02/JMeter-Rabbit-AMQP 。(我更新了maven build 方式和一些jar version信息，在branch support_maven_xx 上)

放到jmeter中，就可使用jmeter來壓了。

結論是：確實connection的使用方式 會影響到rabbitmq的內部，從而致使其餘鏈接到同一rabbitmq的鏈接收到影響。

具體工做原理，由於涉及到rabbitmq的源碼，目前沒有深刻研究。