第 11 章 分析與調校訊息服務

本章涵蓋的數個主題，說明如何分析與調校 Message Queue^TM 服務，以便將訊息傳送應用程式的效能最佳化。它包括以下主題：

• 關於效能

• 影響效能的因素

• 調校配置以改善效能

關於效能

本節提供效能調校的一些背景資訊。

效能調校程序

訊息傳送應用程式的效能取決於應用程式和 Message Queue 服務之間的互動。因此，最佳化效能需要應用程式開發者和管理員共同的努力。

最佳化效能的程序從應用程式設計開始，然後是部署應用程式，接著再對訊息服務進行調校。效能調校程序包括以下階段：

• 定義應用程式的效能需求

• 設計應用程式時必須考量影響效能的因素 (特別是可靠性與效能之間的取捨)

• 建立基準效能測量

• 調校或重新配置訊息服務以最佳化效能

以上略述的程序通常是反覆的。在部署應用程式期間，Message Queue 管理員應評估訊息服務是否符合應用程式的一般效能需求。如果效能評定測試符合這些需求，管理員可以根據本章說明調校系統。但是，如果效能評定測試不符合效能需求，則可能需要重新設計應用程式或修改架構部署。

效能類型

一般而言，效能是指訊息服務從產生器傳送訊息到用戶的速度和效率之測量結果。但是，您可能會依您的需要關注效能的不同方面。

連線負載

系統可支援之訊息產生器、訊息用戶或同步運作連線的數目。

訊息流量

每秒導入訊息傳送系統的訊息數目或訊息容量。

延時

從訊息產生器傳送特定訊息到訊息用戶所需的時間。

穩定性

訊息服務的整體可用性，或者在負載量較大或失敗時訊息服務緩慢降低的程度。

效率

訊息傳送的效率，亦即與已使用之運算資源相關的訊息流量測量結果。

通常這些不同方面的效能都相互關聯。如果訊息流量高，則表示訊息不太可能積存於代理程式中；因此，延時時間會比較短 (單一訊息可迅速傳送)。但是，延時可取決於很多因素：通訊連結的速度、代理程式處理速度，以及用戶端處理速度等。

無論如何，會有數個不同方面的效能。對您最重要的方面通常取決於特定應用程式的需求。

效能評定

效能評定是針對訊息傳送應用程式建立測試套件，並且為此測試套件測量訊息流量或其他方面效能的程序。

例如，您可以建立一個測試套件，讓數個訊息產生用戶端使用數個連線、階段作業和訊息產生器，以某個特定速率，將標準容量的永久性或非永久性訊息傳送到數個佇列或主題 (這些都取決於您的訊息傳送應用程式設計)。同樣地，此測試套件包括數個訊息使用用戶端，這些用戶端會使用數個連線和階段作業，以及在測試套件實體目標中以特定確認模式使用訊息的特定類型訊息用戶。

使用標準的測試套件，您可以測量訊息產生和使用間所需的時間或平均訊息流量速率，並且可以監視系統以觀察連線執行緒用法、訊息儲存資料、訊息流量資料和其他相關度量。在效能受到不良影響之前，您就可以迅速增加訊息產生的速率、訊息產生器的數目或其他變數。您可以達到的最大流量為您訊息服務配置的效能評定。

使用此效能評定，您可以修改部分測試套件的特徵。請謹慎控制所有可能影響效能的因素 (請參閱影響效能的應用程式設計因素)，您可以對變更其中某些因素會如何影響效能評定進行記錄。例如，您可以將連線數目或訊息容量增加 5 倍或 10 倍，然後記下效能所受的影響。

反過來，您也可以保持以應用程式為基礎的因素不變，而以某種控制方法變更代理程式配置 (例如，變更連線特性、執行緒池特性、JVM 記憶體限制、限制運作方式、檔案式與 JDBC 型永久性... 等等)，並記錄這些變更對於效能所產生的影響。

應用程式的效能評定會提供資訊，這些資訊在您要藉由調校訊息服務增加已部署應用程式的效能時會有所幫助。效能評定可以更加準確地預測一個變更或一組變更的效果。

一般來說，效能評定應在受控制的測試環境中執行，並且要時間足夠長以讓訊息服務穩定執行。(啟動時，及時 (Just-In-Time) 編譯會將 Java 程式碼轉為機器碼，這會對效能造成不良影響。)

基準使用式樣

部署並執行訊息傳送應用程式之後，請務必建立基準使用式樣。您必須知道尖峰需求出現的時間並可以將需求數目化。例如，需求通常會因一般使用者的數目、作業層級、每天的時間或所有這些因素而有所變化。

若要建立基準使用式樣，您必須長時間監視訊息服務，查看下列資料：

• 連線數目

• 儲存於代理程式中 (或特定實體目標中) 的訊息數目

• 傳入和傳出代理程式 (或特定實體目標) 的訊息流量

• 使用中用戶數目

您還可以使用度量資料中提供的平均值與尖峰值。

檢查這些出乎設計意料之外的基準度量是非常重要的。經由此動作，您會檢查用戶端程式碼是否正常運作：例如，連線未處於開啟狀態，或使用的訊息未處於未確認狀態。這些編碼錯誤會耗用代理程式資源，並且可能對效能有很明顯的影響。

基準使用式樣可幫助您判斷如何將系統調校到最佳化效能。例如：

• 如果某個實體目標的使用頻繁程度比其他實體目標高出許多，則您可能需要將此實體目標的訊息記憶體限制設定得較高，或者據此調整限制行為。

• 如果所需的連線數目明顯大於最大執行緒池容量允許的大小，那麼您可能要增加執行緒池大小，或調校共用執行緒模型。

• 如果尖峰訊息流量遠大於平均流量，則可能會影響您在記憶體不足時使用的限制運作方式。

一般而言，您對使用式樣的瞭解越多，您調校系統用於未來需求的式樣與計劃的能力越好。

影響效能的因素

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

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

調校配置以改善效能

以下各小節說明配置調整如何影響效能。

系統調校

以下各小節描述您可對作業系統、JVM 和通訊協定所做的調整。

Solaris 調校：CPU 使用、分頁/交換/磁碟 I/O

請參閱您系統的文件來調校您的作業系統。

Java 虛擬機器調整

依預設，代理程式會使用 192MB 的 JVM 堆疊容量。此容量對大量的訊息負載通常過小，所以應增加其大小。

當代理程式將要耗盡 Java 物件使用的 JVM 堆疊儲存區空間時，會使用各種技術 (如流量控制和訊息交換) 來釋放記憶體。在極端情況下，它甚至會關閉用戶端連線以釋放記憶體，並降低訊息的傳入量。因此，最好將最大 JVM 堆疊儲存區空間設定得足夠大，以避免發生此類情況。

但是，如果將最大 Java 堆疊儲存區空間設定得過大 (相對於系統實體記憶體)，代理程式會持續增加 Java 堆疊儲存區空間，直至整個系統的記憶體用完。這會導致效能降低、不可預料的代理程式當機，和/或影響系統上執行的其他應用程式和服務的運作。一般而言，您需要允許足夠用於作業系統和機器上其他執行應用程式的實體記憶體。

一般而言，最好先評估正常時段和尖峰時段的系統記憶體使用量，然後再配置 Java 堆疊容量，該容量大小應足以提供良好的效能，但又不至於大到導致系統記憶體問題。

若要變更代理程式的最小和最大堆疊容量，請在啟動代理程式時，使用 -vmargs 指令行選項。例如：

/usr/bin/imqbrokerd -vmargs "-Xms256m -Xmx1024m"

此指令會將 Java 堆疊容量的下限設定為 256MB，上限為 1GB。

• 在 Solaris 或 Linux 上，如果經由 /etc/rc* (也就是 /etc/init.d/imq) 啟動代理程式，則請在 /etc/imq/imqbrokerd.conf (Solaris) 或 /etc/opt/sun/mq/imqbrokerd.conf (Linux) 檔案中，指定代理程式指令行引數。請查看檔案中的註解，以取得更多資訊。

• 在 Windows 上，如果將代理程式當成 Windows 服務啟動，則請使用 -vmargs 選項，將 JVM 引數指定到 imqsvcadmin install 指令。請參閱第 13 章, 指令行參照中的服務管理員公用程式。

在任何狀況下，都請檢查代理程式的記錄檔或使用 imqcmd metrics bkr -m cxn 指令，以驗證設定。

調校傳輸協定

選擇符合應用程式需求的協定後，可進行額外調校 (以選取的協定為基礎) 以改善效能。

以下 3 個代理程式特性可用來修改協定效能：

• imq.protocol.protocolType .nodelay

• imq.protocol.protocolType .inbufsz

• imq.protocol.protocolType .outbufsz

對於 TCP 和 SSL 協定，這些特性會影響用戶端和代理程式之間訊息傳送的速度。對於 HTTP 和 HTTPS 協定，這些特性會影響 Message Queue 通道 Servlet (在 Web 伺服器上執行) 和代理程式之間訊息傳送的速度。HTTP/HTTPS 協定還有其他會影響效能的特性 (請參閱HTTP/HTTPS 調校)。

將會在以下各節描述協定調校特性。

nodelay

nodelay 特性會影響用於指定協定的 Nagle 演算法 (TCP/IP 上 TCP_NODELAY 傳輸層選項的值)。Nagle 演算法可用以改善使用慢速連線 (例如廣域網路 (WAN) 等) 之系統上的 TCP 效能。

使用該演算法時，TCP 會將資料包裝為較大的資料封包，從而避免傳送一些小的資料塊到遠端系統。如果寫入套接的資料未填滿所需緩衝區大小，那麼協定會在緩衝區填滿或特定延遲時間結束前，延遲傳送封包。一旦緩衝區填滿或發生逾時，即會傳送資料封包。

對於大部份的訊息傳送應用程式，如果傳送資料封包時沒有延遲 (未啟用 Nagle 演算法)，則效能為最佳。這是因為用戶端與代理程式之間大部份都是請求/回應式互動：用戶端傳送資料封包給代理程式且等待回應。例如，典型的互動包括：

• 建立連線

• 建立產生器或用戶

• 傳送永久性訊息 (代理程式會確定已接收訊息)

• 在 AUTO_ACKNOWLEDGE 或 CLIENT_ACKNOWLEDGE 階段作業中傳送用戶端確認 (代理程式會確定確認處理)

對於這些互動，大部份的資料封包都小於緩衝區大小。這表示，如果使用 Nagle 演算法，則代理程式在傳送回應到用戶之前，會延遲數毫秒。

但是，在連線速度緩慢和不需代理程式回應的狀況下，Nagle 演算法可改善效能。例如，在用戶端傳送非永久性訊息，或用戶端的確認未經代理程式確定 (DUPS_OK_ACKNOWLEDGE 階段作業) 等狀況下。

inbufsz/outbufsz

inbufsz 特性會設定輸入串流上的緩衝區大小，輸入串流可讀取來自通訊端的資料。同樣地，outbufsz 會設定輸出串流上的緩衝區大小，輸出串流由代理程式用來將資料寫入通訊端。

一般而言，兩個參數值皆應稍微大於接收或傳送的平均封包容量。根據經驗，請將這些特性值設定為比平均資料封包容量多 1 KB (四捨五入至最接近的以 KB 為單位之整數值)。例如，如果代理程式接收內文容量為 1 KB 的資料封包，則該封包 (訊息內文加上標頭和特性) 的總容量約為 1.2 KB；inbufsz 為 2 KB (2048 個位元組) 即可提供適當的效能。將 inbufsz 或 outbufsz 增加到超過此容量可能會稍微改善效能，但是將增加各個連線所需的記憶體。

HTTP/HTTPS 調校

除了前面兩小節描述的一般特性之外，HTTP/HTTPS 效能受限於用戶端發出 HTTP 請求到託管 Message Queue 通道 Servlet 之 Web 伺服器的速度。

Web 伺服器可能需要最佳化，以處理單一通訊端上的多個請求。從 JDK 1.4 版或更新版本開始，HTTP 與 Web 伺服器的連線會持續作用 (到 Web 伺服器的通訊端會保持開啟)，以便在 Web 伺服器處理多個 HTTP 請求時，將 Web 伺服器使用的資源降到最低。在相同用戶端應用程式上使用 JDK 1.4 版的效能，如果比使用較早 JDK 版本的效能低，則您可能需要調校 Web 伺服器持續作用的配置參數，以改善效能。

除了對 Web 伺服器進行此類調校，您也可以調整用戶端輪詢 Web 伺服器的頻率。HTTP 是請求型協定。這表示，使用 HTTP 型協定的用戶端會定期檢查 Web 伺服器，以查看是否有等待中的訊息。imq.httpjms.http.pullPeriod 代理程式特性 (以及類似的 imq.httpsjms.https.pullPeriod 特性) 會指定 Message Queue 用戶端執行階段輪詢 Web 伺服器的頻率。

如果 pullPeriod 值為 -1 (預設值)，則用戶端執行階段會在前一個請求傳回時立即輪詢伺服器，以便最有效發揮個別用戶端的效能。因此，各個用戶端連線均會獨占 Web 伺服器中的一個請求執行緒，因而可能會過度使用 Web 伺服器資源。

如果pullPeriod 值為正數，則用戶端執行階段會定期傳送請求到 Web 伺服器，以查看是否有擱置的資料。在此狀況下，用戶端不會獨占 Web 伺服器中的請求執行緒。因此，如果大量用戶端使用 Web 伺服器，則您可能需要將 pullPeriod 設定為正值，以節省 Web 伺服器資源。

調校檔案式永久性存放區

如需有關調校檔案式永久性存放區的資訊，請參閱永久性服務。

代理程式調校

以下各小節描述您可如何調整代理程式特性以改善效能。

記憶體管理：在代理程式負載過重時提高穩定性

您可以對每個目標個別配置記憶體管理，或是集中配置整個系統層級 (針對所有目標) 的記憶體管理。

使用實體目標限制

如需有關實體目標限制的資訊，請參閱第 6 章, 管理實體目標。

使用系統範圍限制

如果訊息產生器經常使訊息用戶超載，代理程式中可能會累積訊息。代理程式包含一個在記憶體不足情況下，降低產生器速度和將訊息移出使用中記憶體的機制，所以對代理程式可保留的訊息總數目 (和訊息容量) 做出硬式限制是明智之舉。

設定 imq.system.max_count 和 imq.system.max_size 代理程式特性，可控制這些限制。

例如：

imq.system.max_count=5000

以上定義的值，表示代理程式最多只會保留 5000 個未傳送/未確認的訊息。如果傳送額外訊息，則會被代理程式拒絕。如果為永久性訊息，那麼產生器在嘗試傳送訊息時會發生異常。如果為非永久性訊息，代理程式會直接丟棄訊息。

當傳送訊息時傳回異常，用戶端應稍作暫停並試著再傳送一次。(請注意，永遠不會因為代理程式接收訊息失敗而發生異常；所發生的異常都是由傳送端的用戶端所偵測到的異常。)

多重用戶佇列效能

多個佇列用戶在佇列目標中處理訊息的效率，取決於下列可配置的佇列目標屬性：

• 使用中的用戶數目 (maxNumActiveConsumers)

• 單一批次中可傳送到用戶的最大訊息數目 (consumerFlowLimit)

若要達到最佳的訊息流量，必須有充足的使用中用戶數目以滿足佇列產生訊息的速率，並且將佇列中的訊息路由並傳送到使用中用戶時，必須能讓使用的速率達到最快。「Sun Java System^TM Message Queue 技術摘要」中描述平衡多個用戶上訊息傳送的一般機制。

如果訊息累積在佇列中，那麼使用中用戶數目可能會不足以處理訊息負載。也有可能發生以下情形：以批次大小傳送到用戶的訊息會在用戶上進行備份。例如，如果批次大小 (consumerFlowLimit) 過大，一個用戶可能會接收佇列中的所有訊息，而其他使用中用戶則收不到任何訊息。如果用戶處理速度非常快，這可能不會發生問題。

但是，如果用戶的速度相對較慢，那麼您必須將訊息平均分發給用戶，如此一來，批次大小也會變小。批次大小越小，傳送訊息至用戶所需的經常性耗用時間就越長。然而，針對處理速度慢的用戶，網路效能改善比率通常會使用小型的批次大小。

用戶端執行階段訊息流量調校

本小節將討論影響效能的流量控制運作方式 (請參閱用戶端執行階段配置)。請將這些運作方式配置為連線工廠受管理物件的屬性。如需有關設定連線工廠屬性的資訊，請參閱第 8 章, 管理受管理物件。

訊息流量計數

用戶端傳送和接收的訊息 (有效負載訊息) 與 Message Queue 控制訊息，都會透過用戶端與代理程式之間的相同連線進行傳送。如果有效負載訊息的傳送阻擋了控制訊息，則會造成控制訊息 (例如代理程式確認) 延遲傳送。若要避免此擁塞狀況，Message Queue 會計算連線上的有效負載訊息流量。

有效負載訊息分為多個批次 (如連線工廠屬性 imqConnectionFlowCount 所指定)，因此只傳送已設定數目的有效負載訊息。批次傳送後，會暫停傳送有效負載訊息，而只傳送擱置的控制訊息。接著傳送其他有效負載訊息，然後傳送擱置控制訊息，重複此循環。

如果用戶端正在進行需要代理程式大量回應的作業，則 imqConnectionFlowCount 的值應保持較低：例如，如果用戶端正在使用 CLIENT_ACKNOWLEDGE 或 AUTO_ACKNOWLEDGE 模式、永久性訊息、作業事件或佇列瀏覽器，或者正在新增或移除用戶。而另一方面，如果用戶端在連線上只有簡易用戶，並且使用 DUPS_OK_ACKNOWLEDGE 模式，則您可以增加 imqConnectionFlowCount 的值，而不會影響效能。

訊息流量限制

在達到本機資源限制 (例如記憶體限制) 之前，Message Queue 用戶端執行階段可處理的有效負載訊息數目也會有所限制。到達此限制時，會對效能造成影響。因此，Message Queue 會限制每個用戶 (或每個連線) 在連線中傳送的訊息數目，以及在用戶端執行階段中進行緩衝以等待使用的訊息數目。

用戶流量限制

如果傳送到用戶端執行階段的有效負載訊息數超過了為任何用戶所設定的 imqConsumerFlowLimit 值，則會停止傳送訊息給該用戶。只有在傳送給該用戶的未使用訊息數低於此 imqConsumerFlowThreshold 設定值時，才會重新繼續傳送訊息。

以下範例說明這些限制的使用：考量主題用戶的設定值：

imqConsumerFlowLimit=1000
imqConsumerFlowThreshold=50

建立用戶時，代理程式會不間斷傳送第一批 1000 個訊息 (假設存在這些訊息) 給該用戶。傳送這 1000 個訊息之後，代理程式會停止傳送，直到用戶端執行階段要求傳送更多訊息。應用程式處理這些訊息前，用戶端執行階段會保留這些訊息。在要求代理程式傳送下一個批次之前，用戶端執行階段會允許應用程式使用至少 50% (imqConsumerFlowThreshold) 的訊息緩衝容量 (即 500 個訊息)。

在相同情況下，如果臨界值為 10%，則在要求傳送下一個批次之前，用戶端執行階段會等待應用程式至少使用 900 個訊息。

以下計算下一個批次的大小：

imqConsumerFlowLimit - (current number of pending msgs in buffer)

因此，如果imqConsumerFlowThreshold 為 50%，則下一個批次大小可介於 500 到 1000 之間，其實際數量取決於應用程式處理訊息的速度。

如果 imqConsumerFlowThreshold 設定過高 (接近 100%)，則代理程式會嘗試傳送較小的批次，以降低訊息流量。如果該值過低 (接近 0%)，則在代理程式傳送下一組批次之前，用戶端也許能完成處理其餘的緩衝訊息，這也會造成訊息流量下降。一般而言，除非您有特定的效能或可靠性考量，否則不需要變更 imqConsumerFlowThreshold 屬性的預設值。

用戶型流量控制 (尤其是 imqConsumerFlowLimit ) 是管理用戶端執行階段中記憶體的最佳方法。通常，根據用戶端應用程式，您會知道您在任何連線上需要支援的用戶數目、訊息容量和可用於用戶端執行階段的總記憶體容量。

連線流量限制

然而，在一些用戶端應用程式中，用戶數目可能是不確定的，它取決於一般用戶的選擇。在此情況下，您仍可以使用連線層級流量限制來管理記憶體。

連線層級流量控制可限制連線上所有用戶的緩衝訊息總數。如果此數目超過 imqConnectionFlowLimit 的值，則會停止透過連線傳送訊息，直到總數目低於連線限制為止。(只有將 imqConnectionFlowLimitEnabled 設定為 true，才會啟用 imqConnectionFlowLimit 屬性。)

階段作業中形成佇列的訊息數目為使用階段作業之用戶數目及用於每個用戶之訊息負載的函數。如果用戶端在產生和使用訊息中發生延遲，通常您可以藉由重新設定應用程式，以分發較大階段作業數目上的訊息產生器和用戶，或者分發較大連線數目上的階段作業，並因此改善效能。