可以采取哪些步驟來優化tibco JMS以提高性能？

Question

我們正在運行一個高吞吐量的系統，該系統利用tibco-ems JMS將大量消息往返於主服務器與客戶端連接之間傳遞。 我們已經進行了一些統計，並確定JMS是造成大量延遲的原因。 如何使tibco JMS更具性能？ 是否有任何資源可以很好地討論該主題。

Answer 1

如果您不需要持久性，則使用非持久性消息是一種選擇。 請注意，即使您確實需要持久性，有時也最好使用非持久性消息，如果發生崩潰，請執行其他恢復操作（例如重新發送所有消息）

這在以下情況下是相關的：

• 崩潰很少（因為恢復需要時間）
• 您可以輕松檢測到崩潰
• 您可以處理重復的消息（崩潰前您可能不知道確切地傳遞了哪些消息

EMS還提供了一些持久的機制，但是比經典的保證交付要少的防彈措施包括：

• 您可以使用“至少一次”或“最多一次”傳遞，而不是“僅一次”傳遞消息。
• 您可以使用預提取機制，該機制使客戶端在應用程序請求消息之前將消息提取到內存。

Answer 2

EMS不應成為瓶頸。 我已經完成了測試，並且服務器上的吞吐量非常低。

您需要嘗試確定瓶頸在哪里。 是消息的產生者還是消費者的問題。 消息是否堆積在隊列上。

您正在執行哪種類型的方案。

發布/訂閱還是要求回復？ 你有臨時隊列堆積嗎？ 過多的臨時隊列可能會導致性能問題。 （通常是因為他們沒有正確關閉某些東西而讓他們流連忘返）

您是否向持久訂閱者發布主題？ 嘗試橋接主題以排隊並從中讀取內容。 持久的訂戶也會導致性能下降，因為它需要跟蹤誰擁有所有郵件的副本。

確保您的發送過程中只有一個會話，並且該會話中有多個呼叫。 不要為每個操作打開完整的會話。 盡可能重復使用。 為消費者做同樣的事情。

完成后，請確保關閉。 EMS無法解決問題。 因此，如果您建立連接並僅關閉您的應用程序，則該連接仍然存在並占用資源。

即使發生崩潰，也要檢查您對丟失消息的容忍度。 如果您正在執行Client ack，而崩潰處理消息也沒關系，請切換到自動。 我也相信，如果您正在使用（TEMS-用於WCF的Tibco EMS），則會話確認存在問題。 因此，只有在處理完整個郵件后，我們才會從客戶端ACK切換到可以正常運行Dups且效果更好的郵件）