test

Sun Java System Message Queue 3.7 UR1 管理指南

調校配置以改善效能

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

系統調校

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

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

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

Java 虛擬機器調整

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

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

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

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

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

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

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

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

調校傳輸協定

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

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

對於 TCP 和 SSL 協定，這些特性會影響用戶端和代理程式之間訊息傳送的速度。對於 HTTP 和 HTTPS 協定，這些特性會影響 Message Queue 通道 Servlet (在 Web 伺服器上執行) 和代理程式之間訊息傳送的速度。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 會設定輸出串流上的緩衝區大小，輸出串流由代理程式用來將資料寫入通訊端。

一般而言，兩個參數值皆應稍微大於接收或傳送的平均封包容量。根據經驗，請將這些特性值設定為比平均資料封包容量多 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 個未傳送/未確認的訊息。如果傳送額外訊息，則會被代理程式拒絕。如果為永久性訊息，那麼產生器在嘗試傳送訊息時會發生異常。如果為非永久性訊息，代理程式會直接丟棄訊息。

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

多重用戶佇列效能

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

若要達到最佳的訊息流量，必須有充足的使用中用戶數目以滿足佇列產生訊息的速率，並且將佇列中的訊息路由並傳送到使用中用戶時，必須能讓使用的速率達到最快。「Sun Java SystemTM 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 屬性。)

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