IBM WebSphere Application Server Advanced Edition
調整指南
IBM WebSphere Application Server Advanced Edition調整指南 |
|
如果要從管理主控台中呼叫，請選取主控台 > 精靈 > 效能調整器。
請參閱 InfoCenter 的第 6.6.21 篇文章，以取得詳細資訊。
動態片段快取是快取動態 Servlet 和 JSP 檔輸出的功能，這是一項能夠大幅改進應用程式效能的技術。 當在應用程式伺服器 JVM 內運作時，這個快取會截取 Servlet service() 方法呼叫，檢查它能不能利用快取內容來服務這個呼叫，而不必重新執行 Servlet。 由於 J2EE 應用程式讀寫比例很高，且在小範圍內能夠接受資料不是全新的，因此，片段快取能夠為伺服器回應時間、通訊量和可調整性帶來明顯的效果。
在執行 Servlet（產生要快取的輸出）之後，會產生含有該輸出的快取項目。 另外，也會產生執行的副作用（即呼叫其他 Servlet 或 JSP 檔），以及項目的 Meta 資料，其中包括逾時和項目優先順序資訊。 唯一項目用 HttpServletRequest 物件為了每個 Servlet 呼叫而產生的 ID 字串來分辨。 結果就會根據 URI 用來呼叫 Servlet 或階段作業資訊的要求參數來快取 Servlet。 由於 WebSphere Application Server 會將 JSP 檔編譯成 Servlet，因此，會交互使用 JSP 和 Servlet（宣告 XML 檔內的元素時除外）。
如果要設定這個項目：
請參閱 InfoCenter 的 4.5: 動態片段快取一文，以取得詳細資訊。
| 症狀 | 其他資訊 |
| 通訊量和回應時間不良。 | 處理器速度 |
|
AIX：記憶體配置錯誤 Solaris：有太多開啟的檔案 | AIX 檔案描述子 (ulimit) 或 Solaris 檔案描述子 (ulimit) |
| Solaris：在尖峰時間伺服器停滯，回應需要很多時間、處理器使用率始終很高且所有活動都在系統程序中，netstat 顯示有許多開啟指向埠 80 的 Socket 都在 CLOSE_WAIT 或 FIN_WAIT_2 狀態中。 | Solaris tcp_close_wait_interval/tcp_time_wait_interval 和 Solaris tcp_fin_wait_2_flush_interval |
| Windows NT/2000：netstat 顯示有太多 Socket 在 TIME_WAIT 狀態中。 | Windows NT/2000 TcpTimedWaitDelay |
| HP-UX 11：通訊量不良，且沒有調整應用程式伺服器優先順序。 | 調整 WebSphere Application Server 程序的作業系統優先順序 |
| 在負載之下，從屬站要求因逾時或遭到拒絕而無法到達 Web 伺服器。 |
如果是 HP-UX 11，請參閱 HP-UX 11 tcp_conn_request_max。 如果是 IIS Windows NT/2000，請參閱 ListenBackLog 參數。 如果是 NT 中的 IBM HTTP Server，請參閱 ListenBackLog。 |
| Windows NT/2000：在安裝了其他供應商的應用程式伺服器之後，WebSphere Application Server 效能會降低。 | IIS 許可權內容 |
| 資源分析器的百分比最大度量指出 Web 儲存器執行緒儲存池太小。 | Web 儲存器 ThreadsMax 連線數目上限 |
| netstat 顯示埠 9080 有太多 TIME_WAIT 狀態的 Socket。 | 保持作用中 Web 儲存器傳輸上限 |
| 因分頁之故，發生太多磁碟輸入/輸出。 | 資料堆大小設定 |
| 資源分析器的資料來源連線儲存池的使用百分比度量指出儲存池太大。 | WebSphere 資料來源連線儲存池大小 |
| 資源分析器的備妥陳述式快取捨棄度量指出資料來源備妥陳述式快取記憶體太小。 | 備妥陳述式快取記憶體大小 |
| 因 DB2 寫入日誌記錄之故，發生太多磁碟輸入/輸出。 | DB2 MinCommit |
| 資源分析器的百分比最大度量指出 Object Request Broker 執行緒儲存池太小。 | 佇列和 Enterprise Bean |
| 當花太多時間在記憶體回收時，資源分析器的 Java 虛擬機器 Profiler 介面 (JVMPI) 指出過度使用物件。 | 偵測物件的過度使用 |
| 資源分析器使用記憶體度量顯示記憶體洩漏，Java 顯示異常狀況用盡的異常狀況。 | 偵測記憶體洩漏 |
| 通訊量、回應時間和可調整性不良。 | 如果應用程式允許的話，請利用動態片段快取。 |
在使用調整可用的程序時，您可以大幅度增進 WebSphere Application Server 的效能。
這份調整指南將提供一般的建議和特定調整方法的說明來告訴您如何進行調整。
它也將提供可增強效能調整作用的許多因素和變數的提示及要訣。
只要使用本調整指南，再加上其範例和資源，將可擴充您調整的經驗。調整是一項不斷進行的學習處理。您的結果可能會不同於這份指南所提供的內容。
為了您的方便，我們也說明了在其他產品中設定參數的一些程序。 由於這些產品可能會改變，因此，您只能將這些程序視為建議。
共有兩種類型的調整：應用程式調整及參數調整。
雖然應用程式調整有時會帶來最大的調整改進效果，但這份文件的焦點是在個別效能參數及其間的協同作用。
WebSphere Application Server Development Best Practices for Performance and Scalability 白皮書處理應用程式的調整問題， 它會說明含有 Servlet、Java Server Pages (JSP) 檔和 Java 資料庫連線功能 (JDBC) 的 Web 應用程式以及含有 Enterprise Bean 元件的企業應用程式的最佳開發方式。
下表列出各種可大幅增強效能的調整參數：
| 應用程式組合效能核對清單 |
| 調整 WebSphere Application Server 系統佇列 |
| 使用傳值和傳參照 (NoLocalCopies) |
| 調整 Solaris TCP 參數 |
| 調整 Java 記憶體 |
| 調整 MaxRequestsPerChild：在含 IBM HTTP Server 的 Linux 中 |
| 調整 WebSphere 資料來源連線儲存池大小 |
| 調整備妥陳述式快取記憶體大小 |
| Web 伺服器配置重新載入間隔 |
| 調整備妥陳述式快取記憶體大小 |
| 搭配持續性階段作業使用快取記憶體 |
下列參數可協助您防止功能上的問題：
| ListenBackLog 參數：適用在搭配 IIS 執行 Windows NT/2000 且從屬站負載很重之時 |
| 傳輸類型：在 Solaris 中使用 INET Socket（WebSphere Application Server 的預設值） |
| DB2 的連線數：如果您建立的連線數超出 DB2 的預設值 |
| 已選取容許執行緒配置超出上限，且系統因配置了太多執行緒而超載。 |
| 在 Linux 中使用 TCP Socket for DB2：適用於本端資料庫 |
| WebSphere 資料來源連線儲存池大小：請務必要有足夠的連線，才能處理使用 Entity EJB 來處理交易時所需的額外連線，以及避免發生死鎖的情況。 |
WebSphere Application Server 有一系列相互關聯的元件必須互相配合調整，才能支援點對點電子商業應用程式的自訂方法。 這些調整可協助系統達到通訊量的上限，而同時能維持系統的整體穩定性。
WebSphere Application Server 會建立一個佇列網路，這是交互連接的佇列所組成的網路，各佇列代表著處理應用程式之平台的各個元件。 這些佇列包括網路、Web 伺服器、Web 儲存器、EJB 儲存器、資料來源，也可能包括自訂的後端系統的連線管理程式。 在這些資源中，每個都代表等待使用該資源之要求的佇列。
WebSphere 佇列是一種相依於負載的資源。 要求的平均服務時間相依於並行從屬站的數目。
組成佇列網路的佇列大部份都是封閉的佇列。 封閉佇列和開放佇列不同，它會設定佇列作用中的要求數目上限。
封閉佇列可以嚴密地管理系統資源。 比方說，Web 儲存器的連線數目上限設定會控制 Web 儲存器佇列的大小。 如果在每個要求期間，Web 儲存器中執行的平均 Servlet 會建立 10MB 的物件，則其值為 100 的連線數目上限會將 Web 儲存器所耗用的記憶體限制在 1GB。
在封閉佇列中，要求有兩種可能的狀態：作用中或等待中。 作用中的要求可能在執行工作，也可能在等待下游佇列的回應。 比方說，在 Web 伺服器的作用中要求可能是在執行工作（如擷取靜態 HTML），也可能是在等待 Web 儲存器中的某個要求完成作業。 當狀態為等待中，要求是在等待成為作用中。 在有作用中的要求離開佇列之前，這個要求的狀態會一直維持在等待中。
WebSphere Application Server 支援的所有 Web 伺服器都是封閉佇列，如同 WebSphere Application Server 資料來源。 Web 儲存器可以配置成開放或封閉佇列。 一般而言，最好使它們成為封閉佇列。 EJB 儲存器是開放佇列；如果儲存池中沒有可用的執行緒，就會建立一個新執行緒供要求的持續期間使用。
如果是 Servlet 呼叫 Enterprise Bean，Web 儲存器會限制進入 EJB 儲存器的並行要求總數，因為 Web 儲存器也會有限制。 只有在利用 Servlet 執行緒呼叫 Enterprise Bean 時，這種情況才是如此。 如果您要建立執行緒，對 EJB 儲存器連續提出要求，沒有任何東西能阻止您。 這也正是最好不要利用 Servlet 來建立它本身的工作執行緒的原因之一。
以下概述各個佇列設定：
下節概述配置 WebSphere Application Server 佇列的方法。 您可以移動資源（如將資料庫伺服器移到另一部機器中）或提供更有力的資源（如更快的 CPU 組和更多的記憶體）來變更系統的動態，因而可以變更您的調整參數。 因此，請調整您的調整參數來配置生產環境的特定配置。
調整的第一個規則是將 WebSphere Application Server 佇列中的要求數目縮到最小。 一般而言，讓要求在網路中等待（在 Web 伺服器之前），比在 WebSphere 中等待好。 這項配置只會讓準備好要處理的要求進入佇列網路中。 如果要完成這個配置，請將最上游的佇列（最接近從屬站）指定成稍大些，將較下游的佇列（遠離從屬站）指定成逐漸變小。
在工作流程中，越往下游，這個佇列網路中的佇列會越小。 當 200 個從屬站到達 Web 伺服器時，會有 125 個要求保留在網路佇列中，因為 Web 伺服器已設定成要處理 75 個並行從屬站。 在 75 個要求從 Web 伺服器傳到 Web 儲存器時，25 個會保留在 Web 伺服器的佇列中，Web 儲存器會處理其餘 50 個。 這個程序透過資料來源進行，直到最後 25 個使用者到達最終目的地（資料庫伺服器）為止。 由於在上游的每一點中，都會有等待進入元件的工作，因此，這個系統中沒有任何元件需要等待工作的到達。 許多要求會在 WebSphere Application Server 之外，在網路中等待。 這會增加穩定性，因為沒有任何元件會超載。 像 IBM Network Dispatcher 這類遞送軟體可用來將等待的使用者導向 WebSphere Application Server 叢集中的其他伺服器。
請利用一個能夠充分表現生產應用程式精神的測試實例（比方說，它會處理到所有有意義的程式碼路徑），或利用生產應用程式本身，執行一組實驗來判斷系統性能到達上限的時機（飽和點）。 請在移除了應用程式中大部份的這類瓶頸之後，再進行這些測試。 這些測試的一般目標是要讓 CPU 發揮 100% 的使用率。
請利用大的佇列來啟動起始基線實驗。 這可以讓系統能夠處理同時進行的數目上限。 比方說，您可以在佇列網路中的每部伺服器上，以佇列大小 100 來開始第一個實驗，其中包括：Web 伺服器、Web 儲存器和資料來源。
之後，請開始一個實驗系列來繪製通訊量曲線，並在每個實驗之後增加並行使用者的負載。 比方說，請以 1 位使用者、2 位使用者、5 位、10 位、25 位、50 位、100 位、150 位和 200 位使用者來進行實驗。 在每次每個之後，都將通訊量（每秒的要求數）和回應時間（每要求的秒數）記錄下來。
基線實驗所產生的曲線應該類似於下列中的一般通訊量曲線：
WebSphere Application Server 的通訊量是存在系統整體中之並行要求數的函數。 A 區段輕負載區顯示隨著並行使用者要求數目的增加，通訊量也隨著要求數目而近乎呈直線增加。 這反映出在輕負載階段中，並行要求很少在 WebSphere Application Server 系統佇列內遇到阻塞。 到了某個點之後，就會開始出現阻塞，通訊量的增加速率會比較慢，直到出現代表 WebSphere Application Server 系統中某些瓶頸所決定的通訊量上限之飽和點為止。 WebSphere Application Server 機器的 CPU 飽和是最能夠管理的瓶頸類型。 這比較好，因為您很容易新增其他或更強的 CPU 來恢復 CPU 造成的瓶頸。
在重負載區或 B 區段中，當並行從屬站負載增加時，通訊量會維持相當固定。 不過，回應時間會隨著使用者負載而等比例地增加。 也就是說，如果重負載區內的使用者負載加倍，回應時間也會加倍。 在 C 區段（變形區）所代表的某些點上，會有耗盡某系統元件的情況。 這時通訊量會開始降低。 比方說，當 Web 伺服器的網路連線耗盡了網路配接卡的限制時，或超出檔案控點的作業系統限制時，系統便可能會進入變形區。
如果系統 CPU 使用趨近於 100% 而到達飽和點，請進入下一步驟。 如果 CPU 使用還沒有趨近 100%，表示可能有應用程式所造成的瓶頸。 比方說，應用程式可能建立了過多 Java 物件，因而造成了 Java 記憶體回收的瓶頸。
管理應用程式瓶頸的方式有兩種：移除瓶頸或複製瓶頸。 管理瓶頸的最佳方式是將它移除。 請利用 Java 型應用程式 Profiler 來檢查整體物件使用率。 您可以使用「效能追蹤資料視覺化程式 (PTDV)」、JProbe 和 Jinsight 這類 Profiler。
通訊量飽和點的並行使用者數目代表應用程式的並行使用數目上限。 比方說，如果應用程式會使 WebSphere Application Server 在 50 位使用者時進入飽和狀態，您可能會發現 48 位使用者是通訊量和回應時間的最佳組合。 這個值稱為「應用程式並行數目上限」。 「應用程式並行數目上限」是調整 WebSphere Application Server 系統佇列時所採用的基準值。 請記住，最好讓大部份使用者在網路中等候，因此，越往遠離從屬站的下游移動，佇列要越小。 比方說，如果「應用程式並行數目上限」值是 48，請以下列值來起始系統佇列：Web 伺服器 75、Web 儲存器 50、資料來源 45。 請執行另一組實驗，將這些值稍微調高和調低一些，以找出最佳設定。
您可以利用「資源分析器」，透過 Servlet 引擎執行緒儲存池「並行作用中執行緒」度量，來判斷並行使用者的數目。
在效能實驗中，當調整保持作用中的 Web 儲存器傳輸上限來符合 Web 儲存器執行緒數目的上限時，通訊量會增加 10-15%。
在許多情況下，只有少數通過佇列的要求會進入下游的下個佇列中。 在有許多靜態網頁的網站中，會在 Web 伺服器處理許多要求，而不會將這些要求傳遞給 Web 儲存器。 在這種情況下，Web 伺服器佇列可能會遠大於 Web 儲存器佇列。 在上一節裡，我們將 Web 伺服器佇列設為 75，而沒有將它設為趨近於「應用程式並行數目上限」值。 當不同的元件執行時間各不相同時，也需要進行類似的調整。
比方說，在複雜 Servlet 中要花去 90% 時間，但只用 10% 的時間來進行短的 JDBC 查詢的應用程式中，平均會有 10% 的 Servlet 隨時在使用資料庫連線， 因此，資料庫連線佇列會遠遠小於 Web 儲存器佇列。 相反地，如果 Servlet 的大部份執行時間都花在複雜的資料庫查詢上，請考慮增加 Web 儲存器和資料來源兩者的佇列值。 請務必監視 WebSphere Application Server 和資料庫伺服器兩者的 CPU 和記憶體使用率，以確保 CPU 或記憶體沒有進入飽和狀態。
只有當發出方法呼叫的從屬站是在遠端時，指向 Enterprise Bean 的方法呼叫才會放到佇列中。 比方說，當 EJB 從屬站是從 Enterprise Bean 而執行於個別的 Java 虛擬機器（另一個位址空間）時，就是如此。 相對地，如果 EJB 從屬站（Servlet 或另一個 Enterprise Bean）安裝在相同的 JVM 中，則 EJB 方法會執行於 EJB 從屬站的相同執行緒中，且不會進行佇列作業。
遠端 Enterprise Bean 是利用 RMI/IIOP 通信協定來通信的。 透過 RMI/IIOP 來起始的方法呼叫由伺服器端 ORB 來處理。 執行緒儲存池就作為送入要求的佇列。 不過，如果發出遠端方法要求，而執行緒儲存池中沒有其他可用的執行緒的話，便會建立一個新的執行緒。 在方法要求完成之後，便會將這個執行緒毀損。 因此，當利用 ORB 來處理遠端方法要求時，EJB 儲存器會是一個開放佇列，因為它在使用執行緒時，是在沒有連結的狀態下進行的。 下圖說明 Enterprise Bean 的兩個佇列選項。
當配置執行緒儲存池時，務必要瞭解 EJB 從屬站的呼叫型樣。 如果 Servlet 向遠端 Enterprise Bean 發出少量呼叫，且每個方法呼叫都相對較快，請考慮將 ORB 執行緒儲存池中的執行緒數目設成小於 Web 儲存器執行緒儲存池大小的值。
這時資源分析器會出現稱為最大百分比的度量，用來確定所有配置的執行緒都在使用中的時間量。 如果這個值固定是二位數，ORB 可能是瓶頸，應該增加執行緒的數目。
ORB 執行緒儲存池需要增加的程度是呼叫 Enterprise Bean 的並行 Servlet（即從屬站）的數目與每個方法呼叫的延續時間的函數。 如果方法呼叫比較長，請考慮使 ORB 執行緒儲存池大小等於 Web 儲存器大小，因為遠端方法呼叫的交錯會比較少。 如果 Servlet 只會發出指向 ORB 的短期或快速的呼叫，ORB 執行緒儲存池可以比較小。 許多 Servlet 也可能重複使用相同的 ORB 執行緒。 在這種情況下，可以採用小的 ORB 執行緒儲存池，甚至是 Web 儲存器的執行緒儲存池大小的一半。 如果應用程式會將許多時間花在 ORB 中，請在 Web 儲存器和 ORB 之間，配置較均等的關係。
在配置具有高調整性的生產環境中，複製應用程式伺服器的能力可能是一項非常有價值的資產。 當應用程式遇到瓶頸而無法充分利用對稱多重處理 (SMP) 伺服器的 CPU 時，尤其如此。 當調整叢集配置中的 WebSphere Application Server 系統佇列時，請記住，在新增伺服器至叢集時，伺服器下游的負載會有兩倍之多。
兩個 Web 儲存器複本位在 Web 伺服器和資料來源之間。 我們假設 Web 伺服器、Servlet 引擎和資料來源（不包括資料庫）都執行於單一 SMP 伺服器中。 在這些限制之下，可能需要有下列佇列考量：
當建立 SSL 連線時，會發生 SSL 交握。 在建立好連線之後，每次的讀寫作業，SSL 都會執行大量加密和解密。 SSL 交握的效能成本比大量加密和解密大得多。
如果要增強 SSL 效能，您必須減少個別 SSL 連線和交握的數目。
減少連線數目會增加 SSL 連線的安全通信效能以及簡式 TCP 連線的非安全通信。 減少個別 SSL 連線的方式之一，是使用支援 HTTP 1.1 的瀏覽器。 對某些使用者而言，如果無法升級至 HTTP 1.1 的話，就不可能減少個別 SSL 連線數目。
比較常用的方式是減少兩個 WebSphere Application Server 元件之間的連線數目（TCP 和 SSL）。 下列準則有助於確定已配置了應用程式伺服器的 HTTP 傳輸，使 Web 伺服器外掛程式不會重複重新開啟新的應用程式伺服器連線：
WebSphere Application Server 目前所支援的硬體加速器只會增加 SSL 交握的效能，不能增加大量加密/解密的效能。 加速器通常只會使 Web 伺服器得到好處，因為 Web 伺服器連線的存在期間比較短。 WebSphere Application Server 中的所有其他 SSL 連線存在期間都比較長；這些連線不會從只能使 SSL 交握加速的硬體裝置中受益。
密碼組合的效能會隨著軟硬體而不同。 由於密碼組合在軟體中的執行效能比較好，因此，這裡不表示它在硬體中能有較好的效能。 在硬體中，有些演算法的效能通常很差（如 DES 和 3DES），不過，專用的硬體可為這些相同的演算法提供足夠的實作。
大量加密和解密的效能會受到個別 SSL 連線所用密碼組合的影響。 計算資料的測試軟體會將 IBM JSSE 用在從屬站和伺服器軟體上，且不會使用任何密碼硬體支援。 測試不包括建立連線的時間，但包括透過已建立的連線來傳輸資料的時間。 因此，資料會顯示出各種密碼組合在長時間執行的連線上之相對 SSL 效能。
在建立連線之前，從屬站會啟用每個 Test Case 的單一密碼組合。 建立好連線之後，從屬站會計算將 Integer 寫入伺服器要花多少時間，以及伺服器將指定數目的位元組寫回從屬站要花多少時間。 改變資料量會在密碼組合的相對效能上帶來的影響可以忽略。 下圖顯示每個密碼組合的效能。
分析上述資料可以看出下列事實：
核對清單包括下列設定：
確定選項 A 會快取交易範圍外的資料庫資料來提供最大的 Enterprise Bean 效能。 一般而言，只有在 EJB 儲存器擁有給定的資料庫之獨佔性存取權時，才適合採用確定選項 A。 否則，資料完整性會受到影響。 確定選項 B 提供主動的 Entity EJB 物件實例快取作業，它的效能比確定選項 C 好，但記憶體用量較大。 確定選項 C 是 Entity EJB 最常用的工作環境配置。
啟動於和載入於內容的設定決定要使用哪種確定選項。
在效能中，隔離層次也扮演了很重要的角色。 隔離層次越高，列鎖定及資料庫的額外負荷都會增加，同時也會減少資料的並行存取，因而會降低效能。 在隔離設定上，各種資料庫都提供有不同的行為。 一般而言，DB2 資料庫所適用的設定是可重複的讀取。 已確定的讀取通常用於 Oracle。 Oracle 不支援可重複的讀取，它會將這個設定轉換成最高的隔離層次：可序列化。
隔離層次也可以在 Bean 或方法層次上指定。 因此，不同的方法可以配置不同的隔離設定。 這在部份方法需要較高的隔離層次時非常好用，它可用來達到效能上限，同時又能維護完整性的需求。 不過，在單一 Enterprise Bean 交易內，不能在方法呼叫之間變更隔離層次。 在這種情況下，會擲出執行時期異常狀況。
可重複的讀取
這個層次會禁止錯誤讀取和不可重複的讀取，但容許幻象讀取。
已確定的讀取
這個層次會禁止錯誤讀取，但容許不可重複的讀取和幻象讀取。
尚未確定的讀取
這個層次容許錯誤讀取、不可重複的讀取和幻象讀取。
儲存器會依照下列方式來使用交易隔離層次屬性：
如果從屬站在某交易環境定義之外呼叫某個 Bean 方法，儲存器的行為會如同設定了不支援交易屬性。 從屬站必須在沒有交易環境定義的情況下呼叫方法。
強制的
這個合法值會引導儲存器固定呼叫從屬站所關聯的交易環境定義之內的 Bean 方法。
如果從屬站試圖在沒有交易環境定義的情況下呼叫 Bean 方法，儲存器會擲出 javax.jts.TransactionRequiredException 異常狀況到從屬站。
交易環境定義會傳遞給 Enterprise Bean 方法所存取的任何 Enterprise Bean 物件或資源。
存取這些 Entity Bean 的 Enterprise Bean 從屬站必須在現有交易之內執行這些動作。 如果是其他 Enterprise Bean，Enterprise Bean 或 Bean 方法必須實作 Bean 管理值，或使用必要的值或需要新值。 如果是非 Enterpirse Bean EJB 從屬站，從屬站必須利用 javax.transaction.UserTransaction 介面來呼叫交易。
需要新值
不論從屬站是在交易環境定義之內或之外呼叫方法，這個合法值都會引導儲存器固定在新的交易環境定義內呼叫 Bean 方法。
交易環境定義會傳遞給這個 Bean 方法所用的任何 Enterprise Bean 物件或資源。
必要的
這個合法值會引導儲存器在交易環境定義內呼叫 Bean 方法。
如果從屬站在某交易環境定義之內呼叫某個 Bean 方法，儲存器會在從屬站交易環境定義內呼叫這個 Bean 方法。
如果從屬站在某交易環境定義之外呼叫某個 Bean 方法，儲存器會建立新的交易環境定義，並在這個環境內呼叫這個 Bean 方法。
交易環境定義會傳遞給這個 Bean 方法所用的任何 Enterprise Bean 物件或資源。
支援
如果從屬站是在交易之內呼叫 Bean 方法，這個合法值會引導儲存器在交易環境定義之內呼叫 Bean 方法。
如果從屬站在沒有交易環境定義的情況下呼叫 Bean 方法，儲存器也會在沒有交易環境定義的情況下呼叫 Bean 方法。交易環境定義會傳遞給這個 Bean 方法所用的任何 Enterprise Bean 物件或資源。
不支援
這個合法值會引導儲存器在沒有交易環境定義的情況下呼叫 Bean 方法。
如果從屬站在某交易環境定義之內呼叫某個 Bean 方法，在對 Enterprise Bean 實例呼叫這個方法之前，儲存器會暫停交易和現行執行緒之間的關聯。
之後，在方法呼叫傳回時，儲存器會回復暫停的關聯。暫停的交易環境定義不會傳遞到這個 Bean 方法所用的任何 Enterprise Bean 物件或資源。
Bean 管理
這個值會通知儲存器，說明 Bean 類別會直接處理交易區分。
這個內容只能指定給 Session Bean，不能指定給個別的 Bean 方法。
檢查 Java 記憶體回收可讓您瞭解應用程式的記憶體使用情形。 記憶體回收是 Java 的一項很強的功能。 在 Java 應用程式中，寫應用程式的人不必負責記憶體管理的工作，和其他不具記憶體回收功能的語言所撰寫的應用程式相比，Java 應用程式功能強大得多。 只要應用程式沒有濫用物件，這種功能強大的性質都非常好用。 記憶體回收作業的正常消耗是正常運作的應用程式總執行時間的 5% 至 20%。 如果沒有管理的話，記憶體回收有可能成為應用程式最大的瓶頸之一，在 SMP 伺服器機器中執行時尤其如此。
您可以利用記憶體回收來測量應用程式的效能情況。 藉著在固定工作負載的執行期間監視記憶體回收，使用者可以瞭解應用程式有沒有過度利用物件。 記憶體回收甚至可用來偵測記憶體有沒有洩漏。
您可以利用記憶體回收和資源分析器中的資料堆統計值來評估應用程式的效能情況。 藉由監視記憶體的回收，就可以偵測到記憶體洩漏和過度使用物件的情況。
在這類型的探究中，請將資料堆大小下限和上限設成相同。 請選擇一個具代表性的、重複的工作量，讓它儘可能符合生產用法（使用者錯誤和全部）。 讓應用程式執行幾分鐘，直到應用程式狀態穩定為止，也非常重要。
如果要確保統計資料能夠有意義，請執行固定工作負載夠長的時間，直到應用程式狀態穩定為止。 這通常需要幾分鐘才能完成。如果要瞭解應用程式有沒有過度使用物件，請查看資源分析器的 JVMPI Profiler 計數器。 記憶體回收呼叫之間的平均時間應該是單一記憶體回收平均持續期間的 5 至 6 倍。 如果不是，表示應用程式花了超出 15% 的時間進行記憶體回收。 另外，也請查看釋出、配置和移動物件的數目。
如果資訊表示有記憶體回收瓶頸，有兩個方法可清除瓶頸。 成本最低的方法是實作物件快取和儲存池來最佳化應用程式。 請利用 Java Profiler 來判斷目標要鎖定哪些物件。 如果應用程式無法最佳化，新增記憶體、處理器和複本可能會有幫助。 其他記憶體會讓每個複本維持合理的資料堆大小。 其他處理器可讓複本以並行方式來執行。
在 Java 中，記憶體洩漏是造成記憶體回收瓶頸的危險因素。 它們比記憶體的過度使用還糟糕，因為記憶體洩漏會使系統陷入不穩定的狀態。 在經過一段時間之後，記憶體回收的發生頻率會越來越高，最後會將資料堆耗盡，Java 也會因嚴重的用盡記憶體異常狀況而失敗。 當不需要的物件擁有永遠不會刪除的參照時，便會發生記憶體的洩漏。 這通常發生在集合類別之中，如 Hashtable，因為表格本身永遠會有指向物件的參照，即使所有真正的參照都已經刪除了也一樣。
經常有人抱怨，在生產環境中部署應用程式之後，應用程式會馬上當掉。 這通常是因為工作量太大。 對於會洩漏記憶體的應用程式而言，尤其如此，當工作量太高而加速了洩漏的擴大時，也就發生了記憶體配置失敗的情況。
記憶體洩漏的測試與數量的擴大有關。 記憶體洩漏是藉由無法回收的位元組或千位元組數來測量的。 這項敏銳的作業會從有用和無法使用的記憶體預期大小中，將這些數量找出來。 這項作業在數量擴大時更容易完成，它會使間隙加大，因而更容易找出不一致的情況。 以下列出記憶體洩漏的重要結論：
在系統層次或模組層次上，都可以使用重複的測試。 模組測試的好處是比較容易控制。 當模組的設計是要讓在模組內發生的所有情況都維持私密狀況，且不會產生包括記憶體用量在內的外部副作用，記憶體洩漏的測試就會簡單得多。 首先，會將執行模組之前的記憶體用量記錄下來，之後，會重複執行一組固定的 Test Case。 在測試執行結束時，如果有了大幅的改變時，就會重複先前所記錄和檢查的現行記憶體用量。 請記住，當記錄實際的記憶體用量時，必須強制執行記憶體回收作業。 如果要執行這個動作，請在要進行記憶體回收的模組中插入 System.gc()，或使用 Profiling 工具來強制產生這個事件。
當您選擇要使用哪些 Test Case 來進行記憶體洩漏的測試時，請考慮下面這幾點：
資源分析器有助於判斷有沒有發生記憶體洩漏。 為了要有最佳效果，請增加持續時間來重複實驗，如 1000、2000 和 4000 個頁面要求。 資源分析器的記憶體使用圖形應該會呈鋸齒形。 圖形中的每個落下之處都對應於一次記憶體回收。 如果出現下列情況之一，就表示有記憶體洩漏的情況：
如果資料堆的用量指出在工作量很重時可能有洩漏的情況（應用程式伺服器經常接近 100% 的 CPU 使用率）， 但後來工作量較輕乃至接近閒置之時，資料堆又似乎會復原，這就表示有資料堆碎塊的情形。 當 JVM 能夠釋出足夠的物件來滿足記憶體回收周期裡的記憶體配置要求，但沒有時間將資料堆內小塊的可用記憶體區壓縮到較大的連續空間內，這時就會出現資料堆碎塊。
另一個資料堆碎塊的形式是在釋出小型物件（小於 512 位元組）時發生的。 這時會釋出物件，但不會復原儲存體，因而造成記憶體的碎塊。
您可以在 JVM 進階設定指令行引數中開啟 -Xcompactgc 旗號來避免發生資料堆碎塊。 -Xcompactgc 可確保每個記憶體回收周期都會將碎塊消除，但效能會受到小幅影響。
Java 資料堆參數也會影響記憶體回收的行為。 增加資料堆大小可以建立更多物件。 由於大資料堆要較長的時間來填入，因而在記憶體回收之前，應用程式的執行時間會比較長。 不過，資料堆較大，精簡的時間也比較長。 記憶體回收的時間也比較長。
圖例表示三個 CPU 數據量表，每個都以不同的 Java 資料堆設定來執行固定的工作負載。 在中間的數據量表中，設定值是起始資料堆大小和資料堆大小上限或 128MB。 記憶體回收有四次。 記憶體回收的總時間量大約是總執行時間的 15%。 如同最上面的數據量表，當資料堆參數加倍為 256M 時，記憶體回收之間的工作時間長度增加了。 記憶體回收只有三次，但每次記憶體回收的長度也增加了。 在第三個數據量表中，資料堆大小減為 64MB，呈現出相反的結果。 當資料堆較小時，記憶體回收之間的時間和每次記憶體回收的時間都會比較短。 這三個配置的記憶體回收總時間量都大約是 15%。 這代表一個 Java 資料堆及它與物件利用之關係的重要概念。 在 Java 應用程式中，永遠要花費記憶體回收的成本。
您可以改變 Java 資料堆設定來執行一系列的測試實驗。 比方說，以 128MB、192MB、256MB 和 320MB 來實驗。 請在每個實驗期間，監視記憶體的總體使用率。 如果資料堆過度展開的話，可能會出現分頁的情況。 （請利用 vmstat 指令或 Windows NT/2000 效能監視器來進行分頁檢查。） 如果出現分頁的情況，請縮減資料堆大小，或新增其他記憶體到系統中。 當所有執行都完成之後，請比較下列統計資料：
如果資料堆釋出了 85% 或更多，請考慮減少資料堆大小上限，因為應用程式伺服器和應用程式在配置給資料堆的記憶體上使用率偏低。
Solaris tcp_close_wait_interval/tcp_time_wait_interval
Solaris tcp_fin_wait_2_flush_interval
Solaris tcp_keepalive_interval
還有許多其他 TCP 參數存在；變更它們可能會影響環境的效能。 如果需要調整 TCP/IP 堆疊的詳細資訊，請造訪下列網站：Tuning your TCP/IP Stack and More。
在變更前面三個 TCP 參數之前，伺服器會在特定尖峰時期陷入停滯。 netstat 會顯示有許多開啟指向埠 80 的 Socket 都在 CLOSE_WAIT 或 FIN_WAIT_2 狀態中。
這兩種拓蹼都會選取 Object Request Broker 傳參照作業，且後端資料庫都在本身專用的機器中。
另外，如果四部機器的處理器使用率都接近 100%，可以再增加第五部機器。 或者，如果 Web 伺服器沒有用盡所有容量，且 Web 儲存器的處理作業不很繁重，請嘗試移至 B 拓蹼來釋出四部機器中的處理器。
相同的關係也適用於連線的階段作業管理程式數目。
MaxAppls 設定至少必須和連線數目一樣高。
如果階段作業和資料來源使用相同的資料庫，MaxAppls 必須是階段作業管理程式和資料來源的連線數目設定值的總和。
MMaxAppls =（所設定的資料來源連線數目 + 階段作業管理程式中的連線數目）x 複本數
計算好 WAS 資料庫及每個應用程式資料庫的 MaxAppls 設定之後，請確定 DB2 的 MaxAgents 設定等於或大於所有 MaxAppls 的總和。
MaxAgents = 所有資料庫的 MaxAppls 總和
這一節要討論選取和配置執行應用程式伺服器之硬體的考量。
容許每個處理器至少 512MB 記憶體。
請參閱白皮書 WebSphere Application Server Admin Best Practices for Performance and Scalability， 以取得管理從屬站主電腦中之主電腦名稱解析作業的詳細資訊。
本節要討論在伺服器環境中調整作業系統的考量。
附註：當在 Windows NT/2000 作業系統中調整 WebSphere Application Server 時，應該同時使用這兩個參數。
ulimit -n 2000如果是含有複本的大型 SMP 機器，請發出下列指令：
ulimit -unlimited
請利用 ulimit -a 指令來顯示系統資源之所有限制的現行值。
ulimit -n 1024
請利用 ulimit -a 來顯示系統資源之所有限制的現行值。
在某些尖峰期間，伺服器可能會有停滯的現象。 如果發生這種情況，netstat 指令會顯示許多開啟指向埠 80 的 Socket 都在 CLOSE_WAIT 或 FIN_WAIT_2 狀態中。 可見的延遲最多可達四分鐘，在這期間，伺服器不會傳送任何回應，但 CPU 仍會有非常高的使用率，且所有活動都在系統程序中。
ndd -get /dev/tcp tcp_time_wait_interval ndd -set /dev/tcp tcp_time_wait_interval 60000
在尖峰期間，伺服器可能會有停滯的現象。 使用 netstat 指令會指出許多開啟指向埠 80 的 Socket 都在 CLOSE_WAIT 或 FIN_WAIT_2 狀態中。 可見的延遲會達四分鐘，在這期間，伺服器不會傳送任何回應，但 CPU 仍會有非常高的使用率，且所有活動都在系統程序中。
ndd -get /dev/tcp tcp_fin_wait_2_flush_interval
ndd -set /dev/tcp tcp_fin_wait_2_flush_interval 67500
ndd -get /dev/tcp tcp_keepalive_interval
ndd -set /dev/tcp tcp_keepalive_interval 300000
據客戶報告，已順利修改其他 Solaris TCP 參數，其中包括：
tcp_conn_req_max_q
tcp_comm_hash_size
tcp_xmit_hiwat
雖然在提高這些設定值之後，並未見到明顯的效能差異，但系統仍能夠從中受益。
請透過 /etc/system 項目來設定：
set semsys:seminfo_semume = 1024
請透過 /etc/system 項目來設定：
semsys:seminfo_semopm = 200
HP-UX 11 設定在修改之後，可明顯改進 WebSphere Application Server 效能。
chatr +pi64M +pd64M /opt/WebSphere/AppServer/java/bin/PA_RISC2.0/native_threads/java
指令輸出會提供執行程序的現行作業系統性質。
請參閱 Hewlett Packard 網頁，以取得這項變更的詳細資料。
connect requests dropped due to full queue
ndd -set /dev/tcp tcp_conn_request_max 1024
請參閱下列 Hewlett Packard 網頁，以取得這項變更的詳細資料：
| 核心參數 | WebSphere Application Server 調整 | DB2 調整 | Oracle 調整 |
| maxdsiz | 未調整 | 未調整 | 未調整 |
| maxdsiz_64b | 未調整 | 未調整 | 未調整 |
| maxuprc | 512 | ||
| maxfiles | 2,048 | ||
| maxfiles_lim | 2,048 | ||
| nkthreads | 10,000 | ||
| max_thread_proc | 2,048 | ||
| nproc | 1,028 | ||
| nflocks | 8,192 | ||
| ninode | 2,048 | ||
| nfile | 8,192 | ||
| msgseg | 32,767 | ||
| msgmnb | 65,535 | ||
| msgmax | 65,535 | ||
| msgtql | 1,024 | ||
| msgmap | 258 | ||
| msgmni | 256 | ||
| msgssz | 16 | ||
| semmni | 512 | 70 | |
| semmap | 514 | ||
| semmns | 1,024 | 200 | |
| semmnu | 1,024 | ||
| shmmax | 966,367,642 | 1 GB | |
| shmmseg | 16 | 10 | |
| shmmni | 300 | 100 |
請參閱下列 Hewlett Packard 網頁，以取得 HP-UX 核心參數的詳細資料。
WebSphere Application Server 產品提供多種 Web 伺服器品牌和版本的外掛程式。 每個 Web 伺服器作業系統組合都有會影響應用程式效能的特定調整參數。
本節要討論 Web 伺服器所關聯的效能調整設定。
IHS 是多程序、單執行緒的伺服器。 如果需要詳細資訊，請參閱調整 IBM HTTP Server 的相關網頁。
iPlanet Web Server Enterprise Edition 的預設配置提供單一程序的多重執行緒伺服器。
如果要知道 Web 伺服器有沒有出現阻窒的現象，請查看它的 perfdump 統計值。 請查看下列資料：
附註：您可能需要檢查 sePlugin 的許可權：
請利用 ListenBacklog 參數增加 IIS 佇列所保留的要求數來緩和這個狀況。
MaxPoolThreads、PoolThreadLimit
IBM HTTP Server 很容易配置。 預設值通常都可以接受。
如何查看執行緒使用率：有兩種方式可用來找出有多少執行緒的使用情況是低限負載：
請遵循下列步驟來使用 IBM HTTP Server：
每個 WebSphere Application Server 程序都有幾個參數會影響應用程式效能。 WebSphere Application Server 產品中的每個應用程式伺服器都含有一個 EJB 儲存器和一個 Web 儲存器。
您可以利用 WebSphere Application Server 管理主控台來配置和調整應用程式、Web 儲存器、EJB 儲存器、應用程式伺服器及管理網域內的節點。
如何查看參數使用率：在 UNIX 中，請利用 ps -efl 指令來查看現行程序優先順序。
如果要將 Web 伺服器的 Servlet 要求遞送給 Web 儲存器，產品會在 Web 伺服器外掛程式和每個 Web 儲存器之間，建立一個傳輸佇列。
這時資源分析器會出現稱為「最大百分比」的度量，它用來確定配置的執行緒所用的時間量。 如果這個值固定是二位數，Web 儲存器可能是瓶頸，應該增加執行緒的數目。
每個執行緒都會建立一個符合要求大小的快取記憶體。 執行緒的數目由 Web 儲存器執行緒數目大小上限設定來決定。
附註：較大的快取記憶體會用較多的 Java 資料堆，因此，您可能需要增加 Java 資料堆大小上限。 比方說，如果每個快取項目都需要 2KB，執行緒數目大小上限設為 25，且 URL 呼叫快取記憶體大小是 100；這時會需要 5MB 的 Java 資料堆。
請利用資源分析器來檢視 Bean 效能資訊。
Bean、許可權和憑證的相關安全資訊都在快取範圍內。 當快取記憶體逾時到期之後，所有快取資訊都會成為無效。 後續的資訊要求都會進入資料庫查閱。 有時候，必須呼叫輕裝備目錄存取通信協定 (LDAP) 連結或原生鑑別才能得到資訊，而這兩項作業的相對效能成本都比較高。
請根據網站的使用情況和安全需求，實驗找出應用程式的最佳調整策略。
下列系統內容決定了快取記憶體主要和次要雜湊表的起始大小，這會影響到雜湊演算法的重新雜湊和分散的頻率。 可用的雜湊值數目越大，越不會發生雜湊碰撞的情況，擷取速度也會越慢。 如果有若干項目組成快取記憶體雜湊表，在較大容量中建立表格可讓項目的插入比由自動重新雜湊來決定表格的增長有效。 重新雜湊每次進行時，都會移動每個項目。
安全關聯服務 (SAS) 特性只有在離開 JVM（進入另一 JVM）時，才會建立 SSL 連線。 因此，如果所有 Bean 都是共存在相同 JVM 內，則 SAS 所用的 SSL 應該不會防礙效能。
請利用服務標籤，再用預設伺服器或管理網域內所配置的任何其他應用程式伺服器之 Object Request Broker 的編輯內容來設定這些參數。
警告：傳參照可能很危險，可能會造成非預期的結果。 如果遠端方法修改了物件參照，呼叫端可能會見到變更。
如果應用程式伺服器預期 Enterprise Bean 要求的工作量會很大，這時 ORB 配置就非常重要。 請注意下列內容：
使用 JNIReaders 需要比較少的記憶體，因為它必須建立一組固定的執行緒。 它可以節省時間，因為執行緒只會在起始設定期間建立一次，之後，就永遠不會毀損。 JNIReader 是 C 原生實作，速度應該比預設讀取器執行緒快。
警告：請確定 JNIReader 的 JNI 程式庫實作是在 WebSphere Application Server bin 目錄中。 在 Intel 平台中，程式庫是 Selector.dll，在 UNIX 中，它是 libSelector.a 或 libSelector.so。 對 UNIX 而言，如果沒有遺漏 "lib" 字串的話，檔案就應該重新命名。
調整 JVM
JVM 提供了許多會影響到 WebSphere Application Server（它們主要是 Java 應用程式）及應用程式效能的調整參數。
大體上，增加 Java 資料堆大小會改進通訊量，直到資料堆不再能常駐於實體記憶體為止。 當資料堆開始交換到磁碟之後，Java 效能會變得很差。 因此，資料堆大小上限必須夠低，讓資料堆足以放在實體記憶體內。
實體記憶體的使用必須由 JVM 和其他應用程式來分享，比方說，資料庫。 為了保險起見，使用較小的資料堆（比方說，在記憶體較小的機器上使用 64MB）。
請嘗試在較小的機器（實體記憶體小於 1GB）上採用資料堆上限 128MB，在記憶體達 2GB 的系統上採用 256MB，在更大的系統上採用 512MB。 這個起點會隨著應用程式而不同。
如果正在進行效能作業，且需要具有高度重複性的結果，請將起始大小和大小上限設成相同的值。 這會在執行期間，消除任何資料堆的成長。 如果是 Java 應用程式工作集大小仍未確定的生產系統，開始時不妨將起始值設為上限值的四分之一。 之後，JVM 會試著調整資料堆大小來配合 Java 應用程式的工作集。
請利用預設伺服器或您在管理網域內配置的任何其他應用程式伺服器的指令行內容來設定 JVM 參數：
WebSphere Application Server 與您選擇的支援資料庫緊密地整合為一。 如果需要支援的資料庫產品的相關資訊，請造訪產品必備項目網站，網址如下：www.ibm.com/software/webservers/appserv/library.html。 WebSphere Application Server 會利用這個資料庫作為持續支持的管理儲存庫，且會用它來儲存應用程式的階段作業狀態和 Enterprise Bean 資料。
如果應用程式使用 WebSphere Application Server 階段作業狀態、JDBC 資料庫連線儲存池或 Enterprise Bean，請特別注意如何在管理網域內配置這些資源及其資料庫設定。 在 WebSphere Application Server 安裝期間，會建立一個名稱為 WASnn 的資料庫，其中 nn 為版次識別碼，不過您可以使用不同的名稱。 這份文件假設您使用 WAS40。
如果使用叢集作業的話，您可能會為了可調整性而將資料庫建立在個別機器中。 這會關聯到 WebSphere Application Server 資料庫、任何應用程式資料庫及 WebSphere Application Server 階段作業資料庫（如果您使用持續性階段作業的話）。
如果使用複本的話，每個複本都會有一個資料來源儲存池。 當配置資料庫伺服器連線數目上限時，這一點尤其重要。
請利用資源分析器來找出能夠將這些數目的值縮少的最佳儲存池連線數目。 如果「使用百分比」時常太低，請考慮減少儲存池中的連線數目。
在 UNIX 平台中，會建立每個連線的特定 DB2 程序。 如果系統的記憶體較少，很快就會受到影響，且可能會發生錯誤。
每個 Entity EJB 都需要一個額外的連線來通往專用來處理交易的資料庫。 當您計算資料來源連線的數目時，請務必考量到這一點。 如果應用程式每個執行緒需要多個並行連線且資料庫連線儲存池不夠執行緒數目使用，就可能出現死鎖的情況。 假設每個應用程式執行緒都需要兩個並行資料庫連線，且執行緒數目等於連線儲存池大小上限。 當同時符合下面這兩種情況時，就可能出現死鎖：
在這種情況下，如果要避免發生死鎖，資料庫連線儲存池的設定值至少要有一個值較高，使至少有一個等待中的執行緒能夠完成它的第二個資料庫連線，從而釋出資料庫連線。
如果要避免死鎖，請將應用程式寫成每個執行緒最多使用一個連線。 如果您將應用程式寫成每個執行緒都需要 C 個並行資料庫連線，這時連線儲存池必須支援至少下列連線儲存池數目，其中 T 是執行緒數目上限。
T * (C - 1) + 1
連線儲存池設定直接關聯於資料庫伺服器所配置支援的連線數目。 如果增加儲存池中的連線數目上限，但沒有增加資料庫中的對應設定，應用程式會失敗，且 stderr.log 檔中會出現 SQL 異常狀況錯誤。
附註：備妥陳述式已經過最佳化的過程，可用來處理因前置編譯而受益的參數化 SQL 陳述式。 如果資料來源所指定的 JDBC 驅動程式支援前置編譯，建立備妥陳述式會將陳述式送到資料庫來進行編譯。 有些驅動程式不支援前置編譯。 這時，在執行備妥陳述式之前，不會將陳述式傳送到資料庫中。
WebSphere Application Server 資料來源會管理資料庫連線儲存池及備妥陳述式物件所關聯的快取記憶體。 在快取備妥陳述式時，會採用能識別出執行它們的每個連線的標示。 在所用的 SQL 陳述式、備妥陳述式快取記憶體、資料來源和資料庫之間的關係，非常值得檢閱。 假設有一個應用程式使用 5 個 SQL 陳述式：2 個 select、1 個 delete、1 個 insert 及 1 個 update。
上述資料來源的配置，最多可有三個通往資料庫的並行連線。 這時已建立好若干連線，且也執行了許多 SQL 陳述式。 備妥陳述式快取記憶體已配置成保留 10 個陳述式。 連線 1 和 2 有三個快取的備妥陳述式。 連線 3 有四個快取的陳述式。 由於這些陳述式在使用時都已編譯成備妥陳述式，因此，備妥陳述式快取記憶體會反映應用程式的資料庫使用型樣。 備妥陳述式快取實作先進先出法 (FIFO) 佇列。 代表給定的 SQL 陳述式之備妥陳述式物件可在備妥陳述式快取記憶體中重複出現許多次。 尤其是在連線儲存池中，它可能會因每個連線而出現一次。 比方說，陳述式 1 和 2 會出現三次，每個連線各一次。 連線 3 不會出現陳述式 3，連線 3 只會出現陳述式 4 和 5。 因此，如果連線 1 和 2 出現陳述式 4 和 5，執行的時間可能會比較長，因為這些連線必須重新編譯它們。 這個範例比較好的替代方案是將備妥陳述式快取記憶體的大小設為 15（在三個連線中，每個連線各五個陳述式）。
資源分析器可協助您調整這個設定，以將快取記憶體捨棄的情況縮到最小。 請使用代表一般送入從屬站要求數目的標準工作量，使用固定的重複次數，以及一組標準的配置設定。
請遵循以下指示來使用資源分析器：
資料來源 > 連線儲存池 > 陳述式快取記憶體大小最恰當的值是用來取得「備妥陳述式快取記憶體捨棄」的零值或最低值的設定。 這表示一般工作量最有效的數目。
其他 JDBC 參數
除了設定備妥陳述式快取記憶體大小之外，您還可以設定 JDBC 驅動程式的其他特定內容。
比方說，您可以利用 Oracle 來增加下列陳述式取得結果集時所要提取的列數：
name="defaultRowPrefetch", value="25"
請在一般標籤中，輸入資料庫的這些自訂內容類型。
如果要將 BUFFPAGE 設為 n 值，請依照下列方式來發出 DB2 指令 update db cfg for x using BUFFPAGE n，且確定 NPAGES 是 -1：
db2 <-- 請進入 DB2 指令模式，否則，下列 "select" 無法依現狀來運作
connect to x <--（其中 x 為特定 DB2 資料庫名稱）
select * from syscat.bufferpools
（請記下預設值的名稱，或許是：IBMDEFAULTBP）
（如果 NPAGES 已經是 -1，表示您已準備好，不需要發出下列指令）
alter bufferpool IBMDEFAULTBP size -1
（請重新發出下述 "select" 陳述式，現在 NPAGES 應該是 -1）
最佳化層次 9 會使 DB2 將許多時間以及將所有可用的統計值都用來最佳化存取規劃。
如果需要詳細資訊，請參閱 DB2 文件及造訪 IBM DB2 網站。
如果要知道 runstats 有沒有完成，請在 DB2 CLP 上發出下列指令：
db2 -v "select tbname, nleaf, nlevels, stats_time from sysibm.sysindexes"
如果沒有進行任何 runstats 的話，nleaf 和 nlevels 都會填入 -1，stats_time 會有一個空的登錄 "-"。
如果已完成 runstats 的話，runstats 完成時的即時戳記也會出現在 stats_time 之下。 如果您認為所顯示先前的 runstats 的時間太舊，請重新執行 runstats。
新設定會立即生效。
以下是一些 DB2 MinCommit 相關度量：
如果需要設定階段作業管理參數的其他資訊，請參閱 InfoCenter 文章 4.4.1.1 階段作業程式設計模型和環境。
您可以啟用通信元件的追蹤來查看這個參數的使用率。
如果您要循序處理訊息，也就是只用一個訊息 Bean 實例來循序處理訊息，這個值應該設為 1。
20 的通訊量最好。超出這個值之後，通訊量並不會增加。您應該根據訊息類型和工作量及可用的資源來使用 10-20 之間的值，以達訊息通訊量的上限。
訊息通訊量的增加會隨著各種系統資源及接聽器配置這類因素而不同。 系統資源是指處理器的數目和功能。 接聽器配置是所用的階段作業數目及 JMS 交談數目。 在 JMS 交談作業中，包含基礎 MQ 伺服器管理程式資源的存取共用競爭。
請遵循下列步驟：
從開始功能表中，選擇程式集 > 管理工具 > 效能監視器