前言
下面關注一下rabbitmq實際使用時的性能問題和怎么進行一些優化。
性能測試
針對每個需要生產/消費者與rabbitmq進行通訊的方法進行測試
測試環境
-
排除網絡IO的干擾，采用生產者和消費者都在本地服務器的方式
-
內存16G，CPU4核，3.1GHZ
-
操作系統：oracle-linux
-
python版本：3.6.3
測試內容
-
創建10萬個connection連接的平均速度
-
創建10萬個信道的平均速度
-
創建10萬個相同隊列的平均速度
-
創建10萬個相同直連交換機的平均速度
-
創建10萬個相同主題交換機的平均速度
-
創建10萬個交換機和隊列綁定的平均速度
-
投遞10萬條10字節消息的的平均速度
-
投遞10萬條300K消息的的平均速度
測試使用的腳本
- 下載地址:rabbitmq對pika的性能測試
測試結果
connection連接:單線程496/s，多線程最大750/s
信道創建:單線程800/s，多線程850/s；
隊列創建:單線程3867/s，多線程3300/s
交換機創建:單線程3900/s,多線程3250/s
綁定創建:單線程2700/s,多線程2500/s
10字節消息投遞速度:10300msg/s
300k消息傳遞:2400msg/s
總結
-
可以看到信道的創建速度高於tcp連接，所以一般保持TCP連接而使用多個channel；
-
對於業務來說，一般是客戶端請求服務器提交數據，服務器連接rabbitmq存儲數據，那么服務器可以先創建tcp長連接池或channel信道池，到可以提交數據后，服務器直接調用連接對象傳遞數據。
-
隊列和交換機一般是設置持久化的，它們可以長期存在，而消費者也是預先定義的，可以將隊列的聲明，交換機聲明，綁定放在消費者端；
-
生產和消費同時消耗rabbitmq的資源，當生產消費不平衡，如生產大於消費造成消息堆積時，消費者的消費速度回隨着內存的減小變慢，可能造成性能的急劇惡化；
測試發現的一個問題
使用pika操作rabbitmq，在創建信道池后，如果一段時間rabbitmq的tcp連接沒有接受到請求，其會強制關閉tcp連接，造成信道池不可用，所以需要重新開啟TCP連接；