RabbitMQ DeclareQueue和DeclareBind Slow

因爲配置是冪等的，所以建議在諸如BasicPublish（）或BasicConsume（）之類的操作之前先聲明DeclareQueue（）和DeclareBind（）。它確實有這種功能，但其缺點似乎是性能從每秒15k條消息到我機器上1.5k的性能下降。似乎沒有關於解決方法的明確文檔。有什麼想法嗎？RabbitMQ DeclareQueue和DeclareBind Slow

來源

2012-03-18 AronMiller

您能否引用此推薦的來源？ – 2012-03-20 17:41:05

RabbitMQ網站上的教程通常會指定此模式。其他地方可能會有更多的闡述。所需要的是在聲明之前進行預先檢測的輕量級方法，儘管假設存在，那麼declarequeue會在內部使用它。 – AronMiller 2012-03-22 18:22:46

我很喜歡這個建議的性能影響。我沒有爲自己嘗試過，但我不覺得有什麼影響，儘管10倍是很有意義的。

在任何情況下，我們選擇忽略此建議，轉而使用實用程序腳本基於XML中定義的方式創建和綁定隊列。我們的構建服務器會在將代碼庫部署到目標交換機之前執行該實用程序。隊列本身在隊列定義XML文件中定義，然後我們使用app.config作爲我們的配置實用程序來保存交換，主機和虛擬主機信息，以便我們可以利用XML轉換（使用慢獵豹）來轉換構建特定版本輸出。這種方法允許我們將交換配置與我們的代碼庫同步，而不受常量隊列和綁定聲明的影響。

希望這會有所幫助。 Steve

來源

2012-03-19 22:52:53

感謝您的評論。我會考慮這條道路。只要檢測到隊列從第一次初始化消失後的穩健性就可以執行，這似乎是合理的。你覺得你的代碼可以很好地處理這個問題嗎？ – AronMiller 2012-03-22 19:39:24

我的集成測試在各自的設置中調用PurgeQueue。如果某個隊列出於某種原因被刪除，那麼集成測試將失敗。 – 2012-03-23 11:24:26

每次調用聲明，綁定和使用時，都必須與服務器通信，因此每次發佈或獲取消息時都要這樣做，這會對您的進程產生一定程度的影響。

參考Java tutorials，每個示例在生命週期和消費者的每個生命週期中僅聲明和綁定隊列一次，因此我不確定您可能在哪裏看到此指導。

也就是說，交換或隊列可能從您的下方刪除。如果這是一個問題，您可以使用錯誤處理來重新聲明交換，隊列和綁定，以確保這種情況不會導致應用程序崩潰。

來源

2012-03-27 16:05:16

RabbitMQ DeclareQueue和DeclareBind Slow

回答

相關問題