影響效能的因素

訊息延時和訊息流量是兩個主要的效能指標，通常取決於一般訊息完成訊息傳送程序的各個步驟所花費的時間。以下顯示的步驟適用於持續可靠傳送訊息的情況。下圖描述這些步驟。

圖 11–1 透過 Message Queue 服務傳送訊息

訊息傳送步驟

1. 訊息由訊息產生用戶端傳送到代理程式。

2. 代理程式讀取訊息。

3. 訊息會置於永久性存放區中，以確保其可靠性。

4. 代理程式確認接收到訊息，以確保其可靠性。

5. 代理程式判斷訊息的路由狀況。

6. 代理程式寫出訊息。

7. 訊息由代理程式傳送到訊息使用用戶端。

8. 訊息使用用戶端確認接收到訊息，以確保其可靠性。

9. 代理程式處理用戶端確認，以確保其可靠性。

10. 代理程式確定已處理用戶端確認。

    由於這些是連續的步驟，因此，在從訊息產生用戶端傳送訊息到使用用戶端時，其中任何步驟都可能成為瓶頸。大部份的步驟都取決於訊息傳送系統的實體特徵：網路頻寬、電腦處理速度、訊息服務架構等。但是，還有些步驟是取決於訊息傳送應用程式的特徵和要求的可靠性層級。

    以下各小節說明應用程式設計因素與訊息傳送系統因素對於效能的影響。當在訊息傳送中應用程式設計和訊息傳送系統因素相互操作時，將單獨考量每個種類。

影響效能的應用程式設計因素

應用程式設計決策會對整體訊息傳送效能產生顯著的效果。

影響訊息傳送可靠性的因素，對效能的影響最為重要。這些因素如下：

• 傳送模式 (永久性/非永久性訊息)

• 作業事件的使用

• 確認模式

• 長期和非長期訂閱

其他影響效能的應用程式設計因素如下：

• 選擇器的使用 (訊息篩選)

• 訊息容量

• 訊息內文類型

以下各小節說明影響訊息傳送效能的以上各個因素。一般來說，要在效能與可靠性之間進行取捨與平衡：提昇可靠性的因素往往會降低效能。

表 11–1 顯示各種應用程式設計因素通常如何影響訊息傳送效能。表格顯示兩種方案 (一個可靠性高但效能低的方案，另一個效能高但可靠性低的方案)，以及每一個方案的應用程式設計因素選擇。在這兩種極端的方案之間，有多種選擇和取捨可影響可靠性和效能。

表 11–1 高可靠性和高效能方案的比較

應用程式設計因素	可靠性高但效能低的方案	效能高但可靠性低的方案
傳送模式	永久性訊息	非永久性訊息
使用作業事件	已處理的階段作業	無作業事件
確認模式	AUTO_ACKNOWLEDGE 或 CLIENT_ACKNOWLEDGE	DUPS_OK_ACKNOWLEDGE
長期/非長期訂閱	長期訂閱	非長期訂閱
選擇器的使用	訊息篩選	無訊息篩選
訊息容量	大量的小訊息	少量的大訊息
訊息內文類型	複雜的內文類型	簡單的內文類型

傳送模式 (永久性/非永久性訊息)

永久性訊息可在代理程式發生故障的情況下，確保訊息傳送。代理程式會在所有預定用戶確認他們已使用訊息前，將訊息儲存在永久性存放區中。

永久性訊息的代理程式處理速度會比非永久性的訊息處理速度慢，原因如下：

• 代理程式必須以可靠的方式儲存永久性訊息，以便在代理程式發生故障時，才不會遺失永久性訊息。

• 代理程式必須確認每個永久性訊息的接收。一旦產生訊息的方法未傳回異常，就確保會傳送至代理程式。

• 代理程式可能需要確定訊息使用用戶端對於永久性訊息的確認，依用戶端的確認模式而定。

對於佇列以及長期訂閱者的主題而言，處理非永久性訊息的效能大約快 40%。我們是使用容量為 10k 的訊息和 AUTO_ACKNOWLEDGE 模式取得這些結果。

作業事件的使用

作業事件可確保在已處理的階段作業中產生的所有訊息以及使用的所有訊息，都會分別當成一個單位予以處理或不處理 (回復)。

Message Queue 支援本機作業事件和分散式作業事件。

已處理的階段作業中產生或確認訊息的速度，會比在未處理階段作業中的速度慢，原因如下：

• 附加資訊必須隨每個產生訊息一起儲存。

• 某些狀況會儲存作業事件中通常不需要儲存的訊息 (例如，傳送到未訂閱主題目標的永久性訊息通常會遭到刪除，但是在作業事件開始時，有關訂閱的資訊還無法取得)。

• 作業事件中的訊息使用和確認資訊，必須在確定作業事件時進行儲存和處理。

確認模式

一種確保 JMS 訊息可靠傳送的機制，用戶端會確認 Message Queue 代理程式所傳送的訊息已被使用。

如果在用戶端尚未確認訊息時關閉階段作業，或在處理確認前代理程式發生故障，則代理程式會重新傳送訊息，並設定 JMSRedelivered 旗標。

對於未處理的階段作業而言，用戶端可以選擇三種確認模式中的一種，而每一種模式都具有各自的效能特徵：

• AUTO_ACKNOWLEDGE。一旦用戶處理訊息後，系統會自動確認訊息。此模式可確保提供者發生故障後最多會重新傳送一次訊息。

• CLIENT_ACKNOWLEDGE。此應用程式會控制確認訊息的端點。確認先前的確認後，所有訊息會在該階段作業中進行處理。在處理一組確認時，如果代理程式發生故障，則會重新傳送群組中一個或多個訊息。

• DUPS_OK_ACKNOWLEDGE。此模式引導系統在惰性狀態下確認訊息。提供者發生故障後，可以重新傳送多個訊息。

(使用 CLIENT_ACKNOWLEDGE 模式與使用作業事件相似，但如果在處理期間提供者發生故障，則前者不確保會一併處理所有的確認。)

確認模式影響效能的原因如下：

• 在 AUTO_ACKNOWLEDGE 和 CLIENT_ACKNOWLEDGE 模式中，代理程式與用戶端之間需要有額外的控制訊息。額外控制訊息會增加額外的處理經常性耗用時間，並且可能會干擾 JMS 有效負載訊息，因而造成處理延遲。

• 在 AUTO_ACKNOWLEDGE 和 CLIENT_ACKNOWLEDGE 模式中，用戶端必須等待代理程式確定已處理用戶端的確認，才能夠使用其他訊息。(代理程式的此項確認作業可確保代理程式不會意外重新傳送這些訊息。)

• 必須以用戶所接收全部永久性訊息的確認資訊來更新 Message Queue 永久性存放區，因此會降低效能。

長期和非長期訂閱

主題目標的訂閱者分為兩類：長期訂閱者和非長期訂閱者。

長期訂閱可提高可靠性，但會降低流量速度，原因如下：

• Message Queue 訊息服務必須永久儲存指定到每個長期訂閱的訊息清單，以便當代理程式發生故障時，可在回復後使用此清單。

• 長期訂閱的永久性訊息會永久儲存，以便於當代理程式發生故障時，仍然可以在代理程式回復後，於對應的用戶成為使用中狀態時重新傳送訊息。相反的，非長期訂閱的永久性訊息不會永久儲存 (一旦代理程式故障，對應用戶的連線會中斷，而且不會重新傳送訊息)。

我們以兩個狀況比較長期訂閱者與非長期訂閱者的效能：容量為 10k 的永久性和非永久性訊息。這兩種狀況都使用 AUTO_ACKNOWLEDGE 確認模式。只有在永久性訊息的狀況下，長期訂閱的效能才會受到影響 (總共降低了大約 30%)。

選擇器的使用 (訊息篩選)

應用程式開發者通常會將訊息組指向特定用戶。他們會藉由將每個訊息組指向唯一實體目標，或使用單一實體目標並為用戶註冊一個或多個選擇器，以達成此目的。

選擇器是一個字串，請求僅將包含符合此字串特性值的訊息傳送到特定用戶。例如，選擇器 NumberOfOrders >1 僅會傳送包含 NumberOfOrders 特性值 2 或更高值的訊息。

使用選擇器建立用戶會降低效能 (與使用多個實體目標比較)，因為每個訊息都需要額外的處理。使用選擇器時必須剖析選擇器，如此一來，選擇器可與之後的訊息相符合。此外，在路由每個訊息時，必須擷取每個訊息的訊息特性並與選擇器進行比較。但是，使用選擇器可在訊息傳送應用程式中提供更多彈性。

訊息容量

因為必須將更多資料從訊息產生用戶端傳送到代理程式，以及從代理程式傳送到訊息使用用戶端，而且對於永久性訊息，必須儲存較大的訊息，所以訊息容量會影響效能。

但是，藉由將較小訊息批次到單一訊息，可以最小化個別訊息的路由和處理，以改善整體效能。在此情況下，會遺失個別訊息狀態的相關資訊。

在我們的測試中，將傳送至佇列目標的容量為 1k、10k 和 100k 之訊息的流量 (以 KB/秒為單位) 相互比較 (使用 AUTO_ACKNOWLEDGE 確認模式)；我們發現，非永久性訊息傳送在傳送 1k 訊息時大約快 50%，10k 訊息時大約快 20%，100k 訊息時大約快 5%。訊息容量會明顯影響永久性和非永久性訊息。100k 訊息大約是 10k 的 10 倍快，10k 大約是 1k 的 5 倍快。

訊息內文類型

JMS 支援 5 種訊息內文類型，依複雜性大致排列如下：

• BytesMessage 包含一組位元組，其格式由應用程式所決定。

• TextMessage 是一個簡單的 Java 字串。

• StreamMessage 包含一串 Java 原始值。

• MapMessage 包含一組「名稱-值」對。

• ObjectMessage 包含一個 Java 串列化物件。

雖然通常狀況下，使用何種訊息類型是依應用程式的需求而定，但是更複雜的類型 (MapMessage 和 ObjectMessage ) 會增加效能耗用：因為對資料進行串列化和取消串列化作業會消耗效能。效能耗用取決於資料簡單或複雜的程度。

影響效能的訊息服務因素

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

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

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