影響效能的訊息服務因素

訊息傳送應用程式的效能不只受到應用程式設計的影響，也受到執行訊息路由和傳送的訊息服務影響。

以下各節介紹可影響效能的這種訊息服務因素。瞭解這些因素的影響，是增減訊息服務功能、診斷和解決已部署應用程式中可能會出現之效能瓶頸的關鍵。

影響 Message Queue 服務效能的最重要因素如下：

• 硬體

• 作業系統

• Java 虛擬機器 (JVM)

• 連線

• 代理程式限制和運作方式

• 訊息服務架構

• 資料存放區效能

• 用戶端執行階段配置

以下各小節說明影響訊息傳送效能的以上各個因素。

硬體

對於 Message Queue 代理程式和用戶端應用程式而言，CPU 處理速度和可用記憶體是決定訊息服務效能的主要因素。增加處理能力可以減少許多軟體限制，而增加記憶體可以同時增加處理速度和能力。然而，升級硬體以克服這些瓶頸通常需要一筆花費。

作業系統

因為不同作業系統的效率也不同，因此即便是相同的硬體平台，效能也會各有差異。例如，作業系統使用的執行緒模型，對於代理程式可支援的同步運作之連線數目會有重大影響。一般而言，在全部硬體都相同的狀況下，Solaris 系統通常比 Linux 系統快，而 Linux 系統通常比 Windows 系統快。

Java 虛擬機器 (JVM)

代理程式是在主機 JVM 中執行且受其支援的 Java 處理程序。因此，JVM 處理是決定代理程式路由和傳送訊息的速度和效率的重要因素。

尤其是，JVM 的記憶體資源管理相當重要。必須為 JVM 配置足夠的記憶體，以因應增加的記憶體負載。另外，JVM 會定期收回未使用的記憶體，而記憶體收回作業會延遲訊息處理。JVM 記憶體堆疊越大，記憶體收回過程中可能的延遲時間就越長。

連線

用戶端和代理程式之間的連線數目和速度，會影響訊息服務可處理的訊息數目以及訊息傳送的速度。

代理程式連線限制

所有對代理程式的存取都透過連線進行。對於同步運作之連線數目的任何限制，都會影響目前可同時使用代理程式的訊息產生用戶端或訊息使用用戶端的數目。

與代理程式的連線數目，通常會受到可用執行緒數目的限制。您可以將 Message Queue 配置為支援專用的執行緒模型，或是支援共用的執行緒模型 (請參閱執行緒池管理)。

專用執行緒模型的執行速度非常快，因為每個連線都有專用執行緒；但是，連線數目受到可用執行緒數目的限制 (每個連線都使用一個輸入執行緒和一個輸出執行緒)。共用執行緒模型在連線數目上沒有限制；但是，在連線數目超過共用執行緒時，會產生明顯的經常性耗用時間和流量延遲，特別是在連線忙碌時。

傳輸協定

Message Queue 軟體可讓用戶端使用各種低層級的傳輸協定，與代理程式進行通訊。Message Queue 支援連線服務中描述的連線服務 (以及對應的協定)。

協定是根據應用程式需求 (加密、可透過防火牆存取) 而選擇的，但是所選擇的結果會影響整體效能。

圖 11–2 傳輸協定速度

我們的測試比較了 TCP 和 SSL 在兩種狀況下的流量：高可靠性方案 (將 1K 的永久性訊息傳送到包含長期訂閱的主題目標，並且使用 AUTO_ACKNOWLEDGE 確認模式)，和高效能方案 (將 1K 的非永久性訊息傳送到不包含長期訂閱的主題目標，並且使用 DUPS_OK_ACKNOWLEDGE 確認模式)。

一般而言，我們發現協定對於可靠性高的方案影響較小。這可能是因為，在可靠性高的方案中，所需要的永久性經常性耗用時間是限制流量的更重要因素，其影響比協定速度的影響更大。另外：

• TCP 提供與代理程式進行通訊的最快速方法。

• 傳送和接收訊息時，SSL 的速度比 TCP 慢了 50% 到 70% (如果是永久性訊息則慢了 50%；非永久訊息則慢了將近 70%)。此外，使用 SSL 建立初始連線的速度較慢 (可能會花費數秒)，因為用戶端和代理程式 (若為 HTTPS，則是 Web 伺服器) 需要建立私密金鑰以供加密所傳輸的資料時所使用。由於加密和解密每個低層級 TCP 資料封包都需要進行額外處理，因此效能會降低。

• HTTP 的速度比 TCP 或 SSL 慢。HTTP 將在 Web 伺服器上執行的 Servlet 當做用戶端與代理程式之間的代理。將資料封包封裝為 HTTP 請求，以及訊息必須通過兩個躍點 (用戶端至 Servlet、Servlet 至代理程式) 才能到達代理程式，都會影響效能的經常性耗用時間。

• HTTPS 的速度比 HTTP 慢，因為 HTTPS 需要額外的經常性耗用時間以加密用戶端與 Servlet 之間以及 Servlet 與代理程式之間的資料封包。

訊息服務架構

Message Queue 訊息服務可實作為單一代理程式，或實作為包含多個互連代理程式實例的叢集。

隨著連線至代理程式的用戶端數目增加，以及要傳送的訊息數目增加，代理程式最終會超過資源限制，例如，檔案描述元、執行緒和記憶體限制。因應負載增加的方法之一是，將多個代理程式實例增加至 Message Queue 訊息服務，從而在多個代理程式之間分發用戶端連線與訊息路由和傳送。

一般而言，如果用戶端 (尤其是訊息產生用戶端) 在叢集中均勻分布，如此延伸的效果會最好。由於經常性耗用時間受到叢集中代理程式間訊息傳送的影響，所以具有連線數目限制或訊息傳送速率限制的叢集，其表現效能可能會比單一代理程式低。

您還可以使用代理程式叢集來最佳化網路頻寬。例如，您可以在叢集中的一組遠端代理程式間使用速度較慢、距離較長的網路連結，而使用較高速度的連結將用戶端連線至其各自的代理程式實例。

如需有關叢集的更多資訊，請參閱第 9 章, 使用代理程式叢集。

代理程式限制和運作方式

代理程式可能需要處理的訊息流量，是代理程式所支援之訊息傳送應用程式使用式樣的一個函數。然而，代理程式在資源上受到限制：記憶體、CPU 週期... 等等。因此，代理程式可能會在超過限制時當機，造成沒有回應或不穩定的狀況。

Message Queue 訊息代理程式有內建機制，可管理記憶體資源，並預防代理程式耗盡記憶體。這些機制的可配置限制包括代理程式可保留的訊息數目和訊息容量、其個別實體目標，以及達到實體目標限制時可採取的運作方式。

透過謹慎的監視與調校，使用這些可配置的機制以平衡傳入和傳出訊息的流量，這樣就不會發生系統超載的狀況。這些機制會消耗經常性耗用時間並限制訊息流量，但他們會維護作業完整性。

資料存放區效能

Message Queue 支援檔案式與 JDBC 型永久性模組。檔案式永久性使用個別的檔案來儲存永久性資料。JDBC 型永久性使用 Java 資料庫連結 (JDBC™) 介面，並且需要 JDBC 相容的資料存放區。檔案型永久性通常快於 JDBC 型永久性；但是，某些使用者偏好 JDBC 相容存放區所提供的備援和管理控制。

在使用檔案式永久性的情況下，您可以指定永久性作業同步化包含資料存放區的常駐記憶體狀態，以保持最佳可靠性。這可以消除因系統當機而產生的資料遺失，但會影響效能。

用戶端執行階段配置

Message Queue 用戶端執行階段為用戶端應用程式提供 Message Queue 訊息服務的介面。它支援用戶端將訊息傳送至實體目標和從此類目標接收訊息所需的所有作業。設定連線工廠屬性值就能夠配置用戶端執行階段，讓您控制它在改善效能與訊息流量等方面的運作方式，例如連線流量測量、用戶流量限制與連線流量限制。如需有關這些功能、以及用來配置這些功能的屬性之更多資訊，請參閱用戶端執行階段訊息流量調校。