|
| |
| Sun Java System Message Queue 3 2005Q4 管理指南 | |
第 11 章
分析與調校訊息服務本章涵蓋一些如何分析與調校 Message Queue 服務的主題，以最佳化訊息傳送應用程式的效能。它包括下列主題：
關於效能本節提供效能調校的一些背景資訊。
效能調校程序
訊息傳送應用程式的效能取決於應用程式和 Message Queue 服務間的互動。因此，最佳化效能需要應用程式開發者和管理員共同的努力。
最佳化效能的程序首先是應用程式設計，然後是部署應用程式，之後是調校訊息服務。效能調校程序包括以下階段：
以上略述的程序通常是反覆的。部署應用程式期間，Message Queue 管理員會評估應用程式一般效能需求的訊息伺服器合適性。如果效能評定測試符合這些需求，管理員可以根據本章說明調校系統。但是，如果效能評定測試不符合效能需求，則可能需要重新設計應用程式或修改架構部署。
效能類型
一般而言，效能是測量訊息服務從產生者傳送訊息到用戶的速度和效率。但是，您可能會依您的需要關注效能的不同方面。
連線負載 系統可支援之訊息產生者、訊息用戶或同步運作連線的數目。
穩定性 訊息服務的整體可用性，或者在負載量較大或失敗時訊息服務緩慢降低的程度。
效率 訊息傳送的效率；是與計算已使用資源相關的訊息流量的測量。
通常這些不同方面的效能是相互關聯的。如果訊息流量高，則表示訊息不太可能儲存於訊息伺服器中，因此，延時時間短 (單一訊息可迅速傳送)。但是，延時可取決於很多因素：通訊連結的速度、訊息伺服器處理速度和用戶端處理速度等。
無論如何，會有數個不同方面的效能。對您最重要的方面通常取決於特定應用程式的需求。
效能評定
效能評定為針對訊息傳送應用程式建立測試套件以及測量訊息流量的程序，或者適用於此測試套件的其他方面效能。
例如，您可能會建立一套測試套件，數個產生者用戶端會依據此測試套件，使用數個連線、階段作業和訊息產生者以某個特定速率，將大小標準的永久性或非永久性訊息傳送到數個佇列或主題 (皆取決於您訊息傳送應用程式的設計)。同樣地，測試套件包括數個使用數個連線和階段作業的用戶用戶端，以及在測試套件實體目標中，以特定確認模式使用訊息的訊息用戶 (特定類型)。
使用標準的測試套件，您可以測量訊息產生和使用間所需的時間或平均訊息流量速率，並且可以監視系統以觀察連線執行緒用法、訊息儲存資料、訊息流量資料和其他相關度量。接著，您可以在對效能產生不良影響前，急速增加訊息產生的速率、訊息產生者的數目或其他變數。您可以達到的最大流量為您訊息服務配置的效能評定。
使用此效能評定，您可以修改部分測試套件的特徵。小心控制所有可能影響效能的因素 (請參閱影響效能的應用程式設計因素)，您可以注意到變更部分因素是如何影響效能評定的。例如，您可以將連線數目或訊息大小增加五倍或十倍，即會注意到效能所受的影響。
相反地，您可以保持應用程式的因素不變，以某種控制方法變更您的代理程式配置 (例如，變更連線特性、執行緒池特性、JVM 記憶體限制、限制運戶方式、檔案型與 JDBC 型永久性等)，並注意這些變更對效能所產生的影響。
應用程式的效能評定會提供資訊，這些資訊在您要藉由調校訊息服務增加已部署應用程式的效能時會有所幫助。效能評定可以更加準確地預測一個變更或一組變更的效果。
一般來說，效能評定應在受控制的測試環境中執行，並且要時間足夠長以讓訊息服務穩定執行。(啟動時，Just-In-Time 編譯會將 Java 程式碼轉為機器程式碼，這會對效能造成不良影響。)
基本使用式樣
一旦部署並執行了訊息傳送應用程式，建立基本使用式樣是很重要的。您必須知道尖峰需求出現的時間並可以將需求數目化。例如，需求通常會因一般使用者的數目、活動層級、每天的時間或所有這些因素而有所變化。
若要建立基本使用式樣，您必須長時間監視您的訊息伺服器，查看下列資料：
您還可以使用度量資料中提供的平均值與尖峰值。
檢查這些出乎設計意料之外的基本度量是非常重要的。經由此動作，您會檢查用戶端程式碼是否正常運作：例如，連線未處於開啟狀態，或使用的訊息未處於未確認狀態。這些程式碼錯誤會使用訊息伺服器資源，且可能會明顯影響效能。
基本使用式樣可幫助您判斷如何將系統調校到最佳化效能。例如：
一般而言，您對使用式樣的瞭解越多，您調校系統用於未來需求的式樣與計劃的能力越好。
影響效能的因素訊息延時和訊息流量為兩個主要的效能指標，它們的值通常取決於一般訊息完成訊息傳送程序中各個步驟所花費的時間。以下顯示的步驟適用於持續可靠傳送訊息的情況。下圖描述這些步驟。
圖 11-1 透過 Message Queue 服務的訊息傳送
由於這些步驟是連續性的，所以在從產生者用戶端傳送訊息至用戶用戶端時，其中任何步驟都可能是瓶頸。大部分的步驟取決於訊息傳送系統的實體特徵：網路頻寬、電腦處理速度、訊息伺服器架構等。但是，還有些步驟是取決於訊息傳送應用程式的特徵和要求的可靠性層級。
下列小節說明應用程式設計因素與訊息傳送系統因素對效能的影響。當在訊息傳送中應用程式設計和訊息傳送系統因素相互操作時，將單獨考量每個種類。
影響效能的應用程式設計因素
應用程式設計決策會對整體訊息傳送效能產生顯著的效果。
影響效能最重要的因素為影響訊息傳送可靠性的因素。這些因素如下：
其他影響效能的應用程式設計因素如下：
下列各節描述影響訊息傳送效能的各個因素。一般來說，要在效能與可靠性間取得平衡：提昇可靠性的因素往往會降低效能。
表 11-1 顯示各種應用程式設計因素通常如何影響訊息傳送效能。表格顯示兩個方案 (高可靠性/低效能方案和高效能/低可靠性方案) 和特定應用程式設計因素的選擇。在這兩個方案中，有許多影響可靠性和效能的選擇和平衡。
備註
以下各圖為使用檔案型永久性，在雙 CPU、1002 Mhz、Solaris 8 系統上產生的效能資料。效能測試首先會預熱 Message Queue 代理程式，以便 Just-In-Time 編譯器最佳化系統和預備的永久性資料庫。
代理程式暖機後，會建立一個產生者和用戶，並以 30 秒的時間產生訊息。會記錄用戶接收所有產生訊息的所需時間，且計算流量速率 (每秒幾個訊息)。此方案會針對應用程式設計因素的不同組合而重複，如表 11-1 所示：
傳送模式 (永久性/非永久性訊息)
永久性訊息可確保訊息伺服器發生故障情況下的訊息傳送。代理程式會在所有預定用戶確認他們已使用訊息前，將訊息儲存在永久性儲存體中。
永久性訊息的代理程式處理速度會比非永久性的訊息處理速度慢，原因如下：
永久性和非永久性模式間效能的差異性可能會非常明顯。圖 11-2 比較了在兩種可靠傳送的情況下，永久性和非永久性訊息的流量：傳送 10K 大小的訊息到到佇列和包含長期訂閱的主題。這兩種情況皆會使用 AUTO_ACKNOWLEDGE 確認模式。
圖 11-2 傳送模式的效能影響
作業事件的使用
作業事件可確保所有異動階段作業中產生的訊息和使用的訊息，皆會作為一個單位來處理或不處理 (回轉) 。
Message Queue 支援本機作業事件和分散式作業事件。
異動階段作業中產生或確認訊息的速度會比在非異動階段作業中的速度慢，原因如下：
確認模式
確保 JMS 訊息可靠傳送的機制，是用戶端確認已使用 Message Queue 訊息伺服器傳送來的訊息。
如果在用戶端未確認訊息時關閉階段作業，或在處理確認前訊息伺服器發生故障，則代理程式會重新傳送訊息，並設定 JMSRedelivered 旗標。
對於非異動階段作業而言，用戶端可以從三種確認模式中選擇一種，每一種模式皆擁有各自的效能特徵：
(使用 CLIENT_ACKNOWLEDGE 模式與使用作業事件相似，但在處理期間提供者發生故障時，前者不確保會一起處理所有確認。)
確認模式影響效能的原因如下：
長期與非長期訂閱
主題目標的訂閱者分為兩個種類，長期或非長期訂閱。
長期訂閱可提高可靠性，但會降低流量，原因如下：
圖 11-3 比較包含長期與非長期訂閱兩種情況的主題目標流量：永久性與非永久性的 10K 大小訊息。這兩種情況皆會使用 AUTO_ACKNOWLEDGE 確認模式。
您可以從圖 11-3 發現只有在永久性訊息的情況下，使用長期訂閱才會對效能產生明顯影響；如同上述說明，在此情況下發生影響是因為只會持續儲存用於長期訂閱的永久性訊息。
圖 11-3 訂閱類型的效能影響
選擇器的使用 (訊息篩選)
應用程式開發者通常會將訊息組指向特定用戶。他們會藉由將每個訊息組指向唯一實體目標，或使用單一實體目標並為用戶註冊一個或多個選擇器，以達成此目的。
選擇器為一字串，請求僅將包含符合此字串之特性值的訊息傳送到特定用戶。例如，選擇器 NumberOfOrders >1 僅會傳送包含 NumberOfOrders 特性值 2 或更高值的訊息。
以選擇器註冊用戶會降低效能 (與使用多個實體目標相比較)，因為需要額外處理每個訊息。使用選擇器時必須剖析選擇器，如此一來，選擇器可與之後的訊息相符合。此外，在路由每個訊息時，必須擷取每個訊息的訊息特性並與選擇器進行比較。但是，使用選擇器可在訊息傳送應用程式中提供更多彈性。
訊息大小
訊息大小會影響效能，因為必須將更多資料從產生者用戶端傳送到代理程式，再從代理程式傳送到用戶用戶端，且必須儲存較大的永久性訊息。
但是，藉由將較小訊息批次到單一訊息，可以最小化個別訊息的路由和處理，以改善整體效能。在此情況下，會遺失個別訊息狀態的相關資訊。
圖 11-4 會比較兩種情況下，1K、10K 和 100K 大小訊息每秒的流量 (以千位元組為單位)：永久性與非永久性訊息。在所有情況下，皆會將訊息傳送到佇列目標，並使用 AUTO_ACKNOWLEDGE 確認模式。
圖 11-4 顯示在兩種情況下，傳送較大訊息的耗用時間會比傳送較小訊息的耗用時間短。您也可以發現在 1K 與 10K 大小的訊息中，非永久性訊息的效能比永久性訊息的效能高出將近 50%，但在 100K 大小訊息中並沒有這種情形，這可能是因為在此情況下，網路頻寬成為訊息流量的瓶頸。
圖 11-4 訊息大小的效能影響
訊息內文類型
JMS 支援五種訊息內文類型，依複雜性大致排列如下：
一般而言，依應用程式需求規定訊息類型時，更複雜的類型 (MapMessage 和 ObjectMessage) 會增加效能耗用，即串列化和取消串列化資料的效能。效能耗用取決於資料簡單或複雜的程度。
影響效能的訊息服務因素
訊息傳送應用程式的效能不只受到應用程式設計的影響，還受到執行訊息路由和傳送的訊息服務影響。
以下各節介紹可影響效能的這種訊息服務因素。瞭解這些因素的影響是調校訊息服務大小、及診斷和解決已部署應用程式中可能會出現之效能瓶頸的關鍵。
影響 Message Queue 服務中效能的最重要因素如下所述：
以下各節描述影響訊息傳送效能的各個因素。
硬體
對 Message Queue 訊息伺服器和用戶端應用程式而言，CPU 處理速度和可用記憶體，是決定訊息服務效能的主要因素。增加處理能力可以減少許多軟體限制，而增加記憶體可以同時增加處理速度和能力。然而，升級硬體以克服這些瓶頸通常需要一筆花費。
作業系統
因為不同作業系統的效率，效能會有所變化，即使是在同樣的硬體平台亦有差別。例如，作業系統部署的執行緒模型，對訊息伺服器可支援的運作連線數目會有極大影響。一般而言，在所有硬體皆同等的情況下，Solaris 系統通常會比 Linux 系統快，而 Linux 系統又比 Windows 系統快。
Java 虛擬機器 (JVM)
訊息伺服器為在主機 JVM 中執行且受其支援的 Java 程序。因此，JVM 處理是決定訊息伺服器路由和傳送訊息之速度和效率的重要因素。
要特別注意的是，JVM 的記憶體資源管理是非常重要的。必須在 JVM 配置足夠的記憶體，以適應增加的記憶體負載。除此之外，JVM 會定期收回未使用的記憶體，且記憶體收回會延遲訊息處理。JVM 記憶體堆疊的容量越多，記憶體收回過程中可能的延遲時間越長。
連線
用戶端和代理程式間的連線數目和速度，會影響訊息伺服器處理訊息的數目和傳送訊息的速度。
訊息伺服器連線限制
所有訊息伺服器的存取皆是透過連線進行的。對同時運作的連線數目有任何限制，皆會影響目前可同時使用訊息伺服器之產生者用戶端或用戶用戶端的數目。
與訊息伺服器的連線數目，通常會受到可用執行緒數目的限制。可配置 Message Queue 以支援專用的執行緒模型或共用的執行緒模型 (請參閱執行緒池管理)。
專用的執行緒模型執行速度非常快，因為每個連線均有專用執行緒；但是，連線數目受到可用執行緒數目的限制 (每個連線使用一個輸入執行緒和一個輸出執行緒)。共用執行緒模型在連線數目上沒有限制；但是，在連線數目超過共用執行緒時，會產生明顯的耗用時間和流量延遲，特別是在連線忙碌時。
傳輸協定
Message Queue 軟體可讓用戶端使用各種低層傳輸協定，與訊息伺服器進行通訊。Message Queue 支援連線服務中敘述的連線服務 (和對應的協定)。
協定的選擇是根據應用程式需求而異 (加密、透過防火牆的存取權)，而選擇會影響整體效能。
圖 11-5 傳輸協定速度
圖 11-5 會反映各種協定技術的效能特徵：
訊息伺服器架構
可以將 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 虛擬機器調校
依預設，代理程式會使用 192 MB 的 JVM 堆疊大小。此容量對大量的訊息負載通常過小，所以應增加其大小。
當代理程式將要耗盡 Java 物件使用的 JVM 堆疊儲存區空間時，會使用各種技術 (如流量控制和訊息交換) 來釋放記憶體。在極端情況下，它甚至會關閉用戶端連線以釋放記憶體，並降低訊息的傳入量。因此，最好將最大 JVM 堆疊儲存區空間設定得足夠大，以避免發生此類情況。
但是，如果將最大 Java 堆疊儲存區空間設定得過大 (相對於系統實體記憶體)，代理程式會持續增加 Java 堆疊儲存區空間，直至整個系統的記憶體用完。這會導致效能降低、不可預料的代理程式當機，和/或影響系統上執行的其他應用程式和服務的運作。一般而言，您需要允許足夠用於作業系統和機器上其他執行應用程式的實體記憶體。
一般而言，最好是先評估正常時和尖峰時的系統記憶體足跡，然後再配置 Java 堆疊儲存區容量，使其足以提供良好的效能，但又不會太大，而導致系統記憶體問題。
若要變更代理程式最小和最大的堆疊大小，請在啟動代理程式時使用 -vmargs 指令行選項。例如：
/usr/bin/imqbrokerd -vmargs "-Xms256m -Xmx1024m"
此指令會將啟動時的 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 章「指令行參照」中的「服務管理員公用程式」。
在任何情況下，請藉由檢查代理程式的記錄檔或使用 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 增加到超過此大小可能會稍微改善效能；但是，這可能會增加每個連線的所需記憶體。
圖 11-7 顯示在 1K 的封包上變更 inbufsz 的結果。
圖 11-7 在 1K (1,024 個位元組) 封包上變更 inbufsz 的效果
圖 11-8 顯示在 1K 的封包上變更 outbufsz 的結果。
圖 11-8 在 1K (1,024 個位元組) 封包上變更 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 資源。
調校檔案型永久存放區
如需調校檔案型永久存放區，請參閱永久性服務。
代理程式調校
以下各節描述您可對代理程式特性進行的調校，並藉以改善效能。
記憶體管理：增加代理程式負載的穩定性
可以在目標對目標層級或系統範圍層級 (用於整體的所有目標) 上配置記憶體管理。
使用實體目標限制
如需實體目標限制的資訊，請參閱第 6 章「管理實體目標」。
使用系統範圍限制
如果訊息產生者嘗試過度執行訊息用戶，可能會在代理程式中累積訊息。代理程式包含一個在記憶體不足情況下，降低產生者速度和將訊息移出使用中記憶體的機制，所以對代理程式可保留的訊息總數目 (和訊息位元組) 做出硬式限制是明智之舉。
藉由設定 imq.system.max_count 和 imq.system.max_size 代理程式特性可控制這些限制。
例如：
imq.system.max_count=5000
以上定義的值表示代理程式最多只會保留 5,000 個未傳送/未確認的訊息。如果傳送額外訊息，則會被代理程式拒絕。如果為永久性訊息，則產生者在嘗試傳送訊息時會發生異常。如果為非永久性訊息，代理程式會直接丟棄訊息。
當傳送訊息時傳回異常，用戶端應稍作暫停並試著再傳送一次。(請注意，因為代理程式無法接收訊息，所以異常將永遠不會到期；唯一會發生的異常就是由傳送端的用戶端偵測到的異常)。
多重用戶佇列效能
多重佇列用戶在佇列目標中處理訊息的效率，取決於下列可配置的佇列目標屬性：
若要達到最佳化訊息流量，必須有足夠的使用中用戶數目，以滿足佇列產生訊息的速率，並且必須路由佇列中的訊息，然後將其傳送到使用中用戶。此方法會最大化訊息使用率。「Sun Java System 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
建立用戶時，代理程式會不間斷地傳送包含 1,000 個訊息的初始批次 (假設訊息已存在) 給該用戶。傳送 1,000 個訊息後，代理程式會停止傳送，直到用戶端執行階段要求傳送其他訊息。應用程式處理這些訊息前，用戶端執行階段會保留這些訊息。接著，在要求代理程式傳送下一個批次前，用戶端執行階段會允許應用程式使用至少 50% (imqConsumerFlowThreshold) 的訊息緩衝容量 (例如 500 個訊息)。
在相同情況下，如果臨界值為 10% 時，在要求傳送下一個批次前，用戶端執行階段會等待應用程式至少使用 900 個訊息。
以下計算下一個批次的大小：
imqConsumerFlowLimit - (目前緩衝區中擱置的訊息數目)
如此一來，如果 imqConsumerFlowThreshold 為 50%，則下一個批次大小可介於 500 到 1,000 之間，其實際數量取決於應用程式處理訊息的速度。
如果 imqConsumerFlowThreshold 設得太高 (接近 100%)，則代理程式會嘗試傳送較小的批次，以降低訊息流量。如果值過低 (接近 0%)，則用戶端可能可以在代理程式傳送下一組批次前，完成處理其餘的緩衝訊息，這會再次造成訊息流量下降。一般來說，除非您有特定的效能或可靠性考量，否則您不需變更 imqConsumerFlowThreshold 屬性的預設值。
用戶型的流量控制 (特別是 imqConsumerFlowLimit) 為管理用戶端執行階段中記憶體的最佳方法。通常，根據用戶端應用程式，您會知道您在任何連線上需要支援的用戶數目、訊息大小和可用於用戶端執行階段的總記憶體容量。
連線流量限制
然而，在一些用戶端應用程式中，用戶數目可能是不確定的，它取決於一般用戶的選擇。在此情況下，您仍可以使用連線層級流量限制來管理記憶體。
連線層級流量控制可限制用於連線上所有用戶的總緩衝訊息數目。如果此數目超過 imqConnectionFlowLimit 的值，則會停止透過連線傳送訊息，直到總數目低於連線限制為止。(只有在您將 imqConnectionFlowLimitEnabled 設為 true 時，才會啟用 imqConnectionFlowLimit 屬性。)
階段作業中形成佇列的訊息數目為使用階段作業之用戶數目及用於每個用戶之訊息負載的函數。如果用戶端在產生和使用訊息中發生延遲，通常您可以藉由重新設定應用程式，以分散較大階段作業數目上的訊息產生者和用戶，或者分散較大連線數目上的階段作業，並因此改善效能。
