MQ發佈/訂閱領域特定的接口通常比點對點更快嗎？

我正在使用具有點對點MQ通信的傳輸層的現有應用程序。MQ發佈/訂閱領域特定的接口通常比點對點更快嗎？

對於給定的每個帳戶列表，我們需要檢索一些信息。

目前，我們有這樣的事情與MQ進行通信：

responseObject getInfo(requestObject){ 
    code to send message to MQ 
    code to retrieve message from MQ 
}

正如你所看到的，我們等待，直到它徹底進行下一個帳戶之前完成。由於性能問題，我們需要對其進行修改。

我現在有兩種可能的情況。

1）在一個應用程序中創建一組線程來爲每個帳戶執行傳輸適配器。然後從每個任務獲取數據。我更喜歡這種方法，但是一些團隊成員認爲傳輸層對於這種改變是一個更好的地方，我們應該在MQ上而不是我們的應用上額外加載。

2）返修傳輸層使用發佈/訂閱模型。理想我想是這樣的：

void send (requestObject){ 
    code to send message to MQ 
} 

responseObject receive() 
{ 
    code to retrieve message from MQ 
}

然後，我將只發送請求的循環，後來檢索數據的循環。這個想法是，當第一個請求正在被後端系統處理時，我們不必等待響應，而是發送下一個請求。

我的問題是，它會比目前的順序檢索快很多嗎？

來源

2011-05-17 Dima

選項＃2與pub/sub無關。您可以像使用主題一樣輕鬆地將其實現爲隊列。 – mqrus 2011-05-18 18:36:04

問題標題把它當作P2P和pub/sub之間的一種選擇，但問題主體把它作爲線程和流水線處理之間的一種選擇。這是兩個完全不同的東西。

提供的任一代碼片段都可以很容易地使用P2P或pub/sub來放置和獲取消息。這個決定不應該以速度爲基礎，而應該基於接口是否需要將單個消息傳遞給多個接收者。如果答案是否定的，那麼無論您的應用程序的線程模型如何，您可能都希望堅持點對點的方式。

而且，順便說一句，標題中提出的問題的答案是「否」。當您使用點對點模型時，您的消息會立即解析到目標或傳輸隊列，並由WebSphere MQ從那裏路由它們。通過發佈/訂閱，您的消息將被轉交給內部代理進程，從而解決零到許多可能的目標。只有在這一步之後，發佈的消息纔會被放到一個隊列中，在隊列的剩餘部分中，它將像其他任何點對點消息一樣處理。雖然pub/sub通常不會比點對點慢，但代碼路徑更長，因此，所有其他事情都相同，它會增加更多的延遲。

問題的另一部分是關於並行性的。您提議要麼啓動多個線程，要麼打破應用程序，以便請求和回覆分開處理。第三種選擇是運行多個應用程序實例。你可以在你的設計中結合其中的任何或全部。例如，您可以啓動多個請求線程和多個回覆線程，然後針對多個隊列管理器處理應用程序實例。

此問題的關鍵在於消息是否具有彼此之間的親和性，以便對依賴性或應用程序實例或創建它們的線程進行排序。例如，如果我使用請求/回覆響應HTTP請求，則附加到HTTP會話的線程可能需要是接收答覆的線程。但是，如果回覆是真正異步的，並且我只需要用響應數據更新數據庫，那麼具有單獨的請求和回覆線程就很有幫助。

在任何一種情況下，動態調高或調低實例數量的能力都有助於管理峯值工作負載。如果這是通過線程來完成的話，那麼您的性能可伸縮性就會受限於單個服務器的上限。如果這是通過在相同或不同的服務器/ QMgr上啓動新的應用程序實例來實現的，那麼您將獲得可伸縮性和工作負載平衡。

請參閱關於這些問題的更多思考下面的文章：Mission:Messaging: Migration, failover, and scaling in a WebSphere MQ cluster

此外，轉到WebSphere MQ SupportPacs頁並查找性能的SupportPac針對您的平臺和WMQ版本。這些是以MP **開頭的名稱。這些將顯示連接應用程序實例的數量變化時的性能特徵。

來源

2011-05-18 11:36:09

哇，謝謝Rob！ – 2014-01-30 13:40:35

重做方法將使用較少的線程。這是否使應用程序更快取決於管理大量線程的開銷是否正在減慢你的速度。如果你的線程數少於1000（這是一個非常非常粗略的數量級估計！），我想這可能不是。如果你不止這些，那很可能。

來源

2011-05-17 17:34:34

這聽起來不像你正在考慮這種正確的方式。無論您使用哪種模式（點對點或發佈/訂閱），如果您的性能受到後端系統緩慢的限制，這兩者都不會加速此過程。但是，如果您理論上可以一次發出多個請求來對付後端系統，並希望加快速度，那麼您仍然不在乎是否進行點對點或發佈/訂閱。你真正關心的是同步和異步。

您目前檢索數據的方法顯然是同步的：您發送請求消息並等待相應的響應消息。如果您只需在一個方法中將所有請求消息（可能是循環）發送到一個方法中，然後使用單獨的方法（最好在不同的線程中）監視傳入主題的響應，則可以異步執行通信。這將確保您的代碼不會再阻止個別請求。（這大致對應於選項2，儘管沒有pub/sub。）

我認爲選項1可能非常不實用，取決於您實際需要做多少請求，儘管它也可以在不切換到一個pub/sub頻道。

來源

2011-05-17 17:36:26 dlev

MQ發佈/訂閱領域特定的接口通常比點對點更快嗎？

回答

相關問題