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

本章涵蓋一些如何分析與調校 Message Queue 服務的主題，以最佳化您訊息傳送應用程式的效能。它包括以下主題：

關於效能

效能調校程序

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

最佳化效能的程序以應用程式設計為起點，接著在部署應用程式後，調校訊息服務繼續。效能調校程序包括以下階段：

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

效能類型

一般而言，效能為訊息服務從產生者傳送訊息到用戶之速度和效率的測量。但是，依您的需要，您可能需要注意幾個不同方面的效能。

連線負載可支援訊息產生者、訊息用戶或運作之連線系統的數目。

穩定性訊息服務的整體可用性，或如何逐漸降低可用性以防大量負載或失敗。

效率訊息傳送的效率；與計算已使用訊息相關的訊息流量測量。

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

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

效能評定

效能評定為建立用於您訊息傳送應用程式與測量訊息流量之測試套件的程序，或用於此測試套件的其他方面效能。

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

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

使用此效能評定，您可以修改部分您測試套件的特徵。藉由小心控制所有可能影響效能的因素 (請參閱影響效能的應用程式設計因素)，您可以注意到變更部分因素會如何影響效能評定。例如，您可以將連線數目或訊息大小增加五倍或十倍，即可發現效能受到影響。

相反地，您可以將基於應用程式的因素維持一致，並以某種控制方法變更您的代理程式配置 (例如，變更連線特性、執行緒池特性、JVM 記憶體限制、限制運作方式、內建與外掛持續性等)，接著您可以注意到這些變更如何影響效能。

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

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

基本使用式樣

一旦部署並執行訊息傳送應用程式，建立基本使用式樣是很重要的。您必須知道尖峰需求何時出現並可以將需求數目化。例如，需求通常會因一般使用者的數目、活動級別、天數或前述所有因素而有變化。

若要建立基本使用式樣，您必須長時間監視您的訊息伺服器，查看類似下面的資料：

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

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

如果某個實體目標的使用度較其他實體目標高，那麼您可能要將此實體目標的訊息記憶體限制設定的比其他實體目標的限制高，或者要相應地調整限制運作方式。

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

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

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

影響效能的因素

訊息延時和訊息流量為兩個主要的效能指示器，它們的值通常取決於一般訊息完成訊息傳送程序中各個步驟所花費的時間。以下顯示的步驟用於永久性、可靠且已傳送之訊息的情況下。下圖描述這些步驟。

這些訊息是由生產型用戶端傳送到訊息伺服器。

訊息伺服器在訊息中進行讀取

訊息置於永久性儲存體中，以確保其可靠性

訊息伺服器會確認訊息的接收，以確保其可靠性

訊息伺服器會判斷訊息的路由

訊息伺服器會在訊息外等候

這些訊息是由訊息伺服器傳送至使用用戶端

使用用戶端會確認訊息的接收，以確保其可靠性

訊息伺服器會處理用戶端確認，以確保其可靠性

訊息伺服器會確認是否已處理用戶端確認

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

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

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

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

以下各節描述影響訊息傳送效能的各個因素。一般來說，要在效能與可靠性間取得平衡：即提昇可靠性的因素往往會降低效能。

表 11-1 顯示各種應用程式設計因素通常如何影響訊息傳送效能。表格顯示兩個方案 - 高可靠性和低效能方案、高效能和低可靠性方案 - 且顯示特定應用程式設計因素的選擇。在這兩個方案中，有許多影響可靠性和效能的選擇和平衡。

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



備註	以下各圖為使用基於檔案的持續性，在雙 CPU、1002 Mhz、Solaris 8 系統上產生的效能資料。效能測試首先會預熱 Message Queue 代理程式，以便 Just-In-Time 編譯器最佳化系統和預備的永久性資料庫。預熱代理程式後，會建立一個產生者和用戶，並以 30 秒的時間產生訊息。會記錄用戶接收所有產生訊息的所需時間，且計算流量速率 (每秒幾個訊息)。會在應用程式設計因素的不同組合，重複使用此方案，如表 11-1 所示。

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

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

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

代理程式必須可靠地儲存永久性訊息，如此一來，代理程式故障時才不會遺失永久性訊息。

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

根據用戶端的確認模式，代理程式可能需要確認使用用戶端對永久性訊息的確認。

永久性和非永久性模式間效能的差異性非常明顯。圖 11-2 比較兩個可靠傳送情況下，永久性和非永就性訊息的流量：傳送 10K 大小的訊息到到佇列和包含長期訂閱的主題。這兩種情況皆會使用 AUTO_ACKNOWLEDGE 確認模式。

作業事件使用

作業事件是所有作業事件階段作業中產生訊息和使用訊息的保證，兩種訊息的處理方法如下：處理作為一個單位、不處理 (回轉) 作為一個單位。

作業事件階段作業中產生或確認訊息的速度會比在非作業事件階段作業中的速度慢，原因如下：

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

在一些情況下，會儲存作業事件中的訊息，但通常是不會儲存這些訊息 (例如，通常會刪除傳送到未訂閱之主題目標的永久性訊息，但是在作業事件開始時，會無法使用有關訂閱的資訊)。

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

確認模式

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 訊息伺服器必須持續儲存指定到每個長期訂閱的訊息清單，如此一來，一旦訊息伺服器發生故障，即可在回復後使用此清單。

會持續儲存長期訂閱的永久性訊息，如此一來，一旦訊息伺服器發生故障，即可在回復後重新傳送訊息，同時對應的用戶會變為使用中狀態。相反地，不會持續儲存非長期訂閱的永久性訊息 (一旦訊息伺服器發生故障，會中斷對應用戶的連線，且不會重新傳送訊息)。

圖 11-3 比較包含長期與非長期訂閱兩種情況的主題目標流量：永久性與非永久性的 10K 大小訊息。這兩種情況皆會使用 AUTO_ACKNOWLEDGE 確認模式。

您可以從圖 11-3 發現只有在永久性訊息的情況下，使用長期訂閱才會對效能產生明顯影響；如同上述說明，在此情況下發生影響是因為只會持續儲存用於長期訂閱的永久性訊息。

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

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

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

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

訊息容量

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

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

圖 11-4 比較兩種情況下，1K、10K 和 100K 大小訊息每秒的流量 (以千位元組為單位)：永久性與非永久性的訊息。在所有情況下，皆會將訊息傳送到佇列目標，並使用 AUTO_ACKNOWLEDGE 確認模式。

圖 11-4 顯示在兩種情況下，傳送較大訊息的耗用時間會比傳送較小訊息的耗用時間短。您也可以發現在 1K 與 10K 大小訊息中，非永久性訊息的效能改善比率比永久性訊息的效能改善比率高出將近 50%，但在 100K 大小訊息中並沒有這種情形，這可能是因為在此情況下，網路頻寬成為訊息流量的瓶頸。

訊息內文類型

JMS 支援五種訊息內文類型，以下大致上依其複雜性順序顯示：

一般而言，依應用程式需求規定訊息類型時，更複雜的類型 (MapMessage 和 ObjectMessage) 會增加效能耗用串列化和解串列化資料的效能。效能耗用取決於資料簡單或複雜的程度。

影響效能的訊息服務因素

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

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

硬體

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

作業系統

因為不同作業系統的效率，效能會有所變化，即使是在同樣的硬體平台亦有差別。例如，作業系統部署的執行緒模型，對訊息伺服器可支援的運作連線數目會有極大影響。一般而言，在所有硬體皆同等的情況下，Solaris 系統通常會比 Linux 系統快，而 Linux 系統又比 Windows 系統快。

Java 虛擬機器 (JVM)

訊息伺服器為在主要 JVM 中執行且支援的 Java 程序。因此，JVM 處理是決定訊息伺服器路由和傳送訊息之速度和效率的重要因素。

要特別注意的是，JVM 的記憶體資源管理是非常重要的。必須在 JVM 配置足夠的記憶體，以適應增加的記憶體負載。除此之外，JVM 會定期回收未使用的記憶體，且記憶體回收會延遲訊息處理。JVM 記憶體堆疊的容量越多，記憶體回收過程中可能發生的延遲時間越長。

連線

用戶端和代理程式間的連線數目和速度，會影響訊息伺服器處理訊息的數目和傳送訊息的速度。

訊息伺服器連線限制

所有訊息伺服器的存取皆是透過連線。運作中連線數目的任何限制，皆會影響目前使用訊息伺服器之生產或使用用戶端的數目。

至訊息伺服器的連線數目通常會受到可用執行緒數目的限制。Message Queue 會使用執行緒池管理程式，以便配置支援專用的執行緒模型或共用的執行緒模型 (請參閱執行緒池管理程式)。

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

傳輸協定

Message Queue 軟體可讓用戶端使用各種低層傳輸協定，與訊息伺服器進行通訊。Message Queue 支援連線服務中敘述的連線服務 (和對應的協定)。

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

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

傳送和接收性訊息時，SSL 的速率為 TCP 的 50% 到 70% (傳送和接收永久性訊息時為 TCP 速率的 50%，非永久訊息時則將近 70%)。此外，使用 SSL 建立初始連線速度較慢 (可能會花費數秒)，因為用戶端和代理程式 (或 HTTPS 情況下的 Web Server) 需要建立加密傳輸資料時會用到的私密密鑰。效能會因額外處理所需加密和解密每個低層 TCP 封包而降低。

圖 11-6 比較 TCP 和 SSL 兩種情況下的流量：高可靠性方案 (傳送到包含長期訂閱之主題目標的 1K 永久性訊息，並使用 AUTO_ACKNOWLEDGE 確認模式) 及高效能方案 (傳送到不包含長期訂閱之主題目標的非永久性訊息，並使用 DUPS_OK_ACKNOWLEDGE 確認模式)。

圖 11-6 顯示高可靠性情況下較不造成影響的協定。這可能是因為在高可靠性情況中需要的持續性耗用時間，是限制流量的重要因素，其影響比對協定速度的影響大。

圖 11-6 傳輸協定的效能影響
圖表比較在高可靠性方案與高效能方案中，TCP 與 SSL 的訊息流量。效果以文字描述。

HTTP 的速度比 TCP 與 SSL 速度慢。HTTP 將 Web Server 上的 Servlet 使用作為用戶端與代理程式間的代理。效能耗用時間受到 HTTP 請求中封裝封包，與訊息通過兩個躍點 (用戶端至 Servlet、Servlet 至代理程式) 以到達代理程式之需求的影響。

HTTPS 速度較 HTTP 慢，因為 HTTPS 需要花費在用戶端與 Servlet 間和 Servlet 與代理程式間加密封裝的額外耗用時間。

訊息伺服器架構

可以將Message Queue 訊息伺服器實作作為單一代理程式或多重互連代理程式實例 - 代理程式叢集。

隨著連線至代理程式的用戶端數目的增加，以及要傳送的訊息數目的增加，代理程式將最終超過資源限制 (如檔案描述元、執行緒和記憶體限制)。提供增加載入的一個方法為將多個代理程式實例新增至 Message Queue 訊息伺服器，從而在多重代理程式間分布用戶端連線與訊息路由和傳送。

一般而言，此調整會使運作達到最佳狀態，如果用戶端 (尤其是訊息生產型用戶端) 在叢集上平均分散的話。由於耗用時間受到叢集中代理程式間訊息傳送的影響，所以包含連線數目限制或訊息傳送速率限制的叢集，所表現效能可能會比單一代理程式低。

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

代理程式限制和運作方式

訊息伺服器可能處理的訊息流量是訊息伺服器所支援之訊息傳送應用程式使用式樣的函數。然而，訊息伺服器在資源上受到限制：記憶體、CPU 週期等。因此，訊息伺服器可能會對點過度負載，造成沒有回應或不穩定的情況。

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

藉由謹慎監視與調校，這些可配置機制可用來平衡流入和流出訊息，如此一來，將不會發生系統過度負載情況。這些機制會耗用時間並限制訊息流量，但他們會維護作業完整性。

資料儲存效能

Message Queue 支援內建和外掛持續性。內建持續性是基於檔案的資料儲存。外掛持續性使用 Java 資料庫連線 (JDBC™) 介面，並需要 JDBC 相容的資料儲存。

內建持續性速度明顯比外掛持續性快；但是，JDBC 相容的資料庫系統可能會提供應用程式需要的容錯、安全與管理功能。

在使用內建持續性的情況下，您可以指定持續性作業同步化包含資料儲存的內部記憶體狀態，以最大化可靠性。這可以消除因系統當機而產生的資料遺失，但會影響效能。

用戶端執行階段配置

Message Queue 用戶端執行階段會提供用戶端應用程式到 Message Queue 訊息服務的介面。它支援用戶端將訊息傳送至實體目標和從此類目標接收訊息所需的所有作業。用戶端執行階段是可配置的 (藉由設定連線工廠屬性值)，它可讓您設定可改善效能與訊息流量的特性與運作方式。

例如，Message Queue 用戶端執行階段支援以下可配置運作方式：

連線流量計數 (imqConnectionFlowCount)，可幫助您避免 JMS 訊息和 Message Queue 控制訊息同時通過同一連線時，產生擁塞情形。

連線流量限制 (imqConnectionFlowLimit)，可幫助您藉由限制可透過連線傳送至用戶端執行階段的待使用訊息數目，來避免用戶端資源限制。

用戶流量限制 (imqConsumerFlowLimit)，可在多用戶佇列傳送情況中，幫助改善用戶之間的負載平衡 (沒有用戶會收到過多的訊息數)，並且有助於平衡所有連線用戶的流量。此特性限制每個用戶在連線中可傳送到用戶端執行階段的待使用訊息數目。也可將此特性配置為佇列目標特性 (consumerFlowLimit)。

調整配置以改善效能

系統調整

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

Java 虛擬機器調整

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

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

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

一般說來，最好是先評估正常時和高峰時的系統記憶體足跡，然後再配置 Java 堆疊儲存區容量，使其足以提供良好的效能，但又不會太大，以至出現系統記憶體問題。

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

此指令會將啟動時的 Java 堆疊大小設為 256MB，且將最大的 Java 堆疊大小設為 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 安裝指令。請參閱第 13 章「指令參照」中的 imqsvcadmin。

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

調校傳輸協定

一旦選擇符合應用程式需求的協定，則額外調校 (以選定的協定為基礎) 可能會改善效能。

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

nodelay

nodelay 特性會影響用於既定協定的 Nagle 演算法 (TCP/IP 上的 TCP_NODELAY 套接級別選項)。Nagle 演算法可使用慢速連線，例如廣域網路 (WAN)，來改善系統上的 TCP 效能。

使用該演算法時，TCP 會嘗試阻止一些小型資料區塊傳送到遠端系統 (藉由將資料隨附於較大封包中)。如果寫入套接的資料未填滿所需緩衝區大小，那麼協定會在緩衝區填滿或特定延遲時間結束前，延遲傳送封包。一旦緩衝區為填滿狀態或發生逾時，即會傳送封包。

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

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

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

inbufsz/outbufsz

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

一般而言，兩個參數值皆應稍微大於接收或傳送的平均封包大小。根據經驗，請將這些特性值設定為比平均封包大小多 1K (將近 1K)。

舉例來說，如果代理程式接收內文大小為 1K 的封包，那麼封包 (訊息內文 + 標頭 + 特性) 的總容量則約為 1,200 個位元組一個 2K (2,048 個位元組) 的 inbufsz 即可產生適當效能。

將 inbufsz 或 outbufsz 增加到超過此大小可能會稍微改善效能；但是，這可能會增加每個連線的所需記憶體。

HTTP/HTTPS 調校

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

Web Server 可能需要最佳化，以便處理單一套接上的多個請求。使用 JDK 1.4 或更新版本，HTTP 至 Web Server 的連線會保持暢通 (至 Web Server 的套接保持開啟狀態)，以便在 Web Server 處理多個 HTTP 請求時，最小化 Web Server 使用的資源。如果在同一個用戶端應用程式上，使用 JDK 1.4 版的效能比使用較早 JDK 版次的效能低，那麼您可能需要調校 Web Server 保持連線暢通的配置參數，以改善效能。

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

如果 pullPeriod 值為 -1 (預設值)，那麼用戶端執行階段會在前個請求傳回時馬上輪詢伺服器，以最大化個別用戶端的效能。因此，每個用戶端連線會獨占 Web Server 中的一個請求執行緒，這可能會過度使用 Web Server 資源。

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

調校基於檔案的永久性儲存

代理程式調整

以下各節描述您可對代理程式特性進行的調整，並藉以改善效能。

記憶體管理：增加代理程式負載的穩定性

可以在目標對目標級別或系統範圍級別 (用於所有目標，整體) 上配置記憶體管理。

使用實體目標限制

使用系統範圍限制

如果訊息產生者嘗試過度執行訊息用戶，可能會在代理程式中累積訊息。代理程式包含一個在記憶體不足情況下，降低產生者速度和將訊息移出使用中記憶體的機制，所以對代理程式可保留的訊息總數目 (和訊息位元組) 做出硬式限制是明智之舉。

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

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

若要非永久性訊息如同永久性訊息一樣傳回異常，那麼請在用戶端使用的連線工廠物件上設定以下特性：

以上設定可能會降低傳送非永久性訊息至代理程式 (用戶端會在傳送下一個訊息前等待回應) 的效能，但是，這情況通常是可接受的，因為流入代理程式的訊息通常不是系統瓶頸。

當傳送訊息時傳回異常，用戶端應稍作暫停並試著再傳送一次。

多重用戶佇列效能

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

若要達到最佳化訊息流量，必須有足以跟上用於佇列之訊息產生速率的使用中用戶數目，且必需路由佇列中的訊息，接著將訊息傳送到使用中用戶。此方法會最大化訊息使用率。Sun Java System Message Queue 技術概述中描述平衡多重用戶上訊息傳送的一般機制。

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

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

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

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

訊息流量計數

用戶端傳送和接收的訊息 (JMS 訊息) 與 Message Queue 控制訊息，皆會忽略相同用戶端與代理程式間的連線。如果 JMS 訊息傳送阻擋控制訊息，則會造成控制訊息 (例如代理程式確認) 傳送的延遲。若要避免此擁塞情形，Message Queue 要計算連線上的 JMS 訊息流量。

JMS 訊息分為幾個批次 (以 imqConnectionFlowCount 特性指定)，因此只傳送一組數字。批次傳送後，JMS 訊息暫停傳送，只傳送擱置控制訊息。接著傳送其他 JMS 訊息，然後傳送擱置控制訊息，重複此循環。

如果用戶端正從代理程式要求許多回應 (例如用戶端使用 CLIENT_ACKNOWLEDGE 或 AUTO_ACKNOWLEDGE 模式、永久性訊息、作業事件、佇列瀏覽器) 或用戶端正在新增或移除用戶時，imqConnectionFlowCount 的值應保持較低。相反地，如果用戶端只有使用 DUPS_OK_ACKNOWLEDGE 模式來連線簡易用戶時，那麼您可以增加 imqConnectionFlowCount 的值，而不需顧及效能。

訊息流量限制

JMS 訊息的數目有一個限制，即在遇到本地資源限制 (例如記憶體) 前，Message Queue 用戶端執行階段可處理的 JMS 訊息數目限制。到達此限制時，會對效能造成影響。因此，Message Queue 可限制每個用戶可在連線中傳送，且在用戶端執行階段內進行緩衝的待使用訊息數目 (或每個連線的訊息數目)。

基於用戶的限制

如果任何用戶傳送至用戶端執行階段的 JMS 訊息數超過 imqConsumerFlowLimit 的值時，則會停止傳送訊息給該用戶。只有在傳送給該用戶的未使用訊息數低於此 imqConsumerFlowThreshold 之設定值時，才恢復傳送訊息。

建立用戶時，代理程式會不間斷地傳送包含 1,000 個訊息的初始批次 (假設訊息已存在) 給該用戶。傳送 1,000 個訊息後，代理程式會停止傳送，直到用戶端執行階段要求傳送其他訊息。應用程式處理這些訊息前，用戶端執行階段會保留這些訊息。接著，在要求代理程式傳送下一個批次前，用戶端執行階段會允許應用程式使用至少 50% (imqConsumerFlowThreshold) 的訊息緩衝容量 (例如 500 個訊息)。

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

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

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

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

基於連線的限制

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

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

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

上一頁目錄索引下一頁
Sun Java System Message Queue 3 2005Q1 管理指南