案例研究: 調優 WebSphere Application Server V7 效能

為了便於您評估一些常見的 Java EE 永續性和事務管理模式，DayTrader 提供了三種不同的業務服務實現。這些實現（或執行時模式）如表 1 所示。

本文將討論這些執行時模式，以便演示各種調優更改對這三種常見 Java EE 永續性和事務實現風格的影響。

導航 WebSphere Application Server 可調引數

如前所述，在執行效能調優時，理解應用程式體系結構、伺服器元件以及所使用的資源是非常重要的。具備這些知識之後，您可以迅速過濾可調引數並專注於直接影響應用程式的核心可調引數。

效能調優通常從 Java Virtual Machine (JVM) 開始，它是應用伺服器的基礎。依照之前的觀點，調優主要是由應用程式所使用的應用伺服器元件所驅動。舉例來說，您可以使用體系結構圖（圖 1）來確定 DayTrader 應用程式的一些主要可調伺服器元件：

• Web 和 EJB 容器
• 相關執行緒池
• 資料庫連線池
• 預設訊息傳遞提供者

本文其餘部分將根據上面列出的元件來詳細討論一些會對 DayTrader 效能造成影響的調優選項。這些選項可以分為以下類別：

• 基本調優：包括一些最常調節和使用的應用伺服器元件，從 JVM 開始。這些設定通常佔據最大份量。
• 高階調優：第二種高階調優引數通常與特定的場景相關，且常用於發掘系統的最大效能。
• 非同步訊息傳遞調優：此處討論的選項特定於使用 WebSphere Application Server 的訊息傳遞元件實現非同步訊息傳遞的應用程式。

我們將詳細討論這類調優引數的適用性，它們的功能權衡以及最終對效能造成的影響（如果可能，針對各種永續性和事務管理模式）。我們還將介紹可以在調優過程中為特定引數提供協助的一些工具。各小節還將提供相關 WebSphere Application Server Information Center 文件或其他相關資源的連結，並最終將彙總在 參考資料 小節中。

基本調優

本節將討論：

1. JVM 堆大小
2. 執行緒工具大小
3. 連線池大小
4. 資料來源狀態快取大小
5. 通過引用傳遞的 ORB

a. JVM 堆大小

JVM 堆大小引數將直接影響垃圾收集行為。通過增加 JVM 堆大小，可以在出現分配故障並觸發垃圾收集之前建立更多物件。這通常可以讓應用程式增加各垃圾收集 (GC) 週期之間的間隔時間。遺憾的是，增加堆大小的一個缺點是查詢和處理需要垃圾收集的物件所需的時間也會隨之增加。因此，JVM 堆大小調優經常涉及確定垃圾收集之間的間隔時間與執行垃圾收集所需的暫停時間之間的平衡點。

要對 JVM 堆大小進行調優，需要啟用詳細模式的（verbose）GC。此操作可以在 WebSphere Application Server 管理控制檯中完成：依次選擇 Servers => Application servers => server_name => Process definition => Java Virtual Machine。通過啟用詳細模式的 GC，JVM 在每次垃圾收集時都會列印輸出有用的資訊，比如堆中的空閒和已使用位元組、垃圾收集之間的間隔以及暫停時間。這些資訊將記錄在 native_stderr.log 檔案中。隨後，各種工具可以使用該檔案來視覺化堆使用情況。

WebSphere Application Server 的預設堆設定如下：初始堆大小為 50 MB，最大堆大小為 256 MB。通常情況下，應該將最小和最大堆大小設定為相同值，以防止 JVM 動態調整堆設定。通過將重要引數固定為常量，這不僅有助於簡化 GC 分析，還可以避免與分配和取消分配更多記憶體相關的成本開銷。將最大和最小堆大小設定為相同值的缺點在於，初次啟動 JVM 時會比較慢，因為 JVM 必須分配更大的堆。

在一些場景中，將最大和最小堆大小設定為不同值是更有利的。其中一個場景就是執行不同工作負載的多個應用伺服器例項託管在同一伺服器上。在此場景中，JVM 可以動態響應不斷變化的工作負載需求，並更加高效地使用系統記憶體。

測試

在啟動詳細模式 GC 的情況下，我們針對初始和最大堆大小分別設定為 256 MB、512 MB、1024 MB 和 2048 MB 執行了 4 次測試。您可以手動分析詳細模式 GC，但可以通過一些圖形工具，比如 IBM Monitoring and Diagnostic Tools for Java - Garbage Collection and Memory Visualizer 工具（隨可免費下載的 IBM Support Assistant 附帶），可以顯著簡化此過程。該工具用於在實驗測試中檢視詳細模式 GC 資料，以便在查詢 DayTrader 應用程式的適當堆大小時可以做出一些調整。

在詳細模式垃圾收集輸出中監視的第一批專案包括收集後的空閒堆。該指標常用於確定應用程式中是否出現的任何 Java 記憶體洩漏。如果此指標未達到穩定狀態值，並隨時間持續減小，則明確表示應用程式中出現了記憶體洩漏。收集後的空閒堆指標還可以與堆大小結合，共同計算伺服器和應用程式所使用的記憶體工作集（或 “記憶體佔用”）。只需要從總堆大小中減去空閒堆值就可以得到這個值。

需要注意，雖然詳細模式 GC 資料和圖 2 中的表可以幫助檢測 Java 堆中的記憶體洩漏，但無法檢測本機記憶體洩漏。發生本機記憶體洩漏的情況是本機元件（比如使用 C/C++ 編寫並通過 Java Native Interface API 呼叫的供應商本機庫）造成本機記憶體洩漏到 Java 堆外部。在這種情況下，需要使用平臺相關工具（如 Linux® 平臺上的 ps 和 top 命令、Windows® 平臺上的 Perfmon 命令等）來監控 Java 程式的本機記憶體使用。WebSphere Application Server Support 分頁 提供了關於診斷記憶體洩漏的詳細文件。

另外還需要考慮各收集任務的垃圾收集間隔時間和平均暫停時間。GC 間隔時間是垃圾收集週期之間的間隔時間。暫停時間是垃圾收集週期完成所需的時間。圖 3 展示了四種堆大小的垃圾收集間隔時間。它們最終的平均值是 0.6 秒 (256 MB)、1.5 秒 (512 MB)、3.2 秒 (1024 MB) 和 6.7 秒 (2048 MB)。

圖 4 顯示了四種堆大小的平均暫停時間。在實驗測試中，它們最終的平均值分別是 62 ms (256 MB)、69 ms (512 MB)、83 ms (1024 MB) 和 117 ms (2048 MB)。這明確展示了增加 Java 堆大小的標準權衡。當堆大小增加時，GC 之間的間隔將增加，這樣便可以在 JVM 暫停以執行垃圾收集例程之前完成更多工。但是，增加堆大小還意味著垃圾收集器必須處理更多物件，從而能增加 GC 暫停時間。

GC 間隔和暫停時間共同構成了垃圾收集所耗費的時間。垃圾收集所花費的時間百分比將顯示在 IBM Monitoring and Diagnostic Tools for Java - Garbage Collection and Memory Visualizer 工具中，並且可以使用以下公開計算得出：

各種情況下垃圾收集所佔用的時間以及形成的吞吐量（每秒請求數）如圖 5 所示。

建議將 DayTrader 應用程式的初始和最大堆大小設定為 1024 MB。至此，您的邊際收益將開始逐漸遞減，因為進一步增加堆大小將不會帶來成比例的效能改進。這在較長垃圾收集間隔時間與較短暫停時間之間達到了平衡，從而減少了垃圾收集所花費的時間。

JVM 調優的另一個重要方面是垃圾收集策略。三種主要的 GC 策略如下：

• optthruput：（預設）當應用程式暫停時，在垃圾收集過程中執行標記和清掃操作，以便最大限度提高應用程式吞吐量。
• optavgpause：在應用程式執行時併發執行標記和清掃操作，以便最大限度縮短暫停時間；這將提供最理想的應用程式響應時間。
• gencon：區別對待短期和長期物件，同時提供較短的暫停時間和較高的應用程式吞吐量。

DayTrader 應用程式並未使用許多長期物件，並且在使用預設的 GC 策略時效能最佳。但是，應用程式是各不相同時，因此您應該評估各 GC 策略，以便找到最適合您應用程式的策略。developerWorks 文章 垃圾收集策略 提供了關於 GC 策略的更多資訊。

圖 6 展示了通過在各種不同的 DayTrader 執行時模式下調優 JVM 堆大小所實現的效能提升。在該表中，藍柱用於表示基準吞吐量值，而紅柱表示調整所討論的調優引數後的吞吐量值。為了便於各種執行時模式之間的相對吞吐量差異，所有度量都將與 EJB 模式基準進行比較。

舉例來說，在調優之前，Session Direct 和 Direct 模式分別比 EJB 模式基準快 23% 和 86%。第二根軸上的線表示 各執行時模式下的總體效能改善。在本例中，JVM 調優為三種執行時模式帶來了不同程度的改善，因為它們分別採用所特有的物件分配模式。效能改善的範圍從 3%（JDBC 模式）到 9%（EJB 模式）不等。

這方面的資訊將在結束對各調優引數的討論時給出。根據上一節所提供的引數，調節各調優引數後實現的應用程式效能改善是可以累加的。本文結尾部分提供的表（圖 22）列出了可用的所有調優更改帶來的總體效能改善。

更多資訊：

• 調優 IBM 的 Java 虛擬機器
• Java 技術，IBM 風格：垃圾收集策略，第 1 部分
• IBM Support Assistant

b. 執行緒池大小

伺服器執行的各項任務執行於 WebSphere Application Server 的許多執行緒池中的某個執行緒之上。執行緒池允許伺服器的元件重用執行緒，從而避免了在執行時建立新執行緒來服務各個新請求。應用伺服器中最常用（和調優）的三個執行緒池如下：

• Web 容器：當請求通過 HTTP 傳入時使用。在 DayTrader 體系結構圖（圖 1）中，可以看到大多數流量都通過 Web Container 流入了 DayTrader。
• 預設：當針對訊息驅動 bean 的請求傳入時，或者沒有為特定傳輸鏈定義具體執行緒池時使用。
• ORB：當針對企業 bean 的請求從 EJB 應用程式客戶機、遠端 EJB 介面或另一臺應用伺服器通過 RMI/IIOP 傳入時使用。

與執行緒池相關的重要調優選項如表 2 所示。

假定機器包含一個應用伺服器例項，則一個良好的實踐是每個伺服器 CPU 核心為預設執行緒池使用 5 個執行緒，每個伺服器 CPU 為 ORB 和 Web 容器執行緒池使用 10 個執行緒。對於 CPU 多於 4 個的機器，預設設定通常可以滿足大多數應用程式的需求。如果機器有多個應用伺服器例項，則這些相應地減小這些值的大小。相反，有時也需要增加執行緒池大小來解決應對 I/O 較慢或後端連線需要長時間執行的問題。表 3 列出了最常調優的執行緒池的預設執行緒池大小和靜止超時。

要修改執行緒池設定，可以在管理控制檯中導航到 Servers => Application Servers => server_name => Thread Pool。您還可以使用 Performance Advisors 來獲得關於執行緒池大小和其他設定的建議。

IBM Tivoli® Performance Viewer 是嵌入在管理控制檯中的一款工具，它允許您檢視幾乎任何伺服器元件的效能監控基礎設施（Performance Monitoring Infrastructure，PMI）資料。檢視器將提供建議幫助使用者調優系統，並針對效率低下的設定提供一些可行的備選建議。訪問 WebSphere Application Server Information Center，瞭解如何使用 Tivoli Performance Viewer 來啟動和檢視 PMI 資料。

圖 7 展示了當 DayTrader 應用程式啟動並在穩定、峰值負載下執行時 Web container 執行緒池的 PMI 資料。池大小（黃色）是池中執行緒數量的平均值，而活動計數（紅色）是當前活動執行緒的數量。從這個圖中可以看出，預設設定，即最多 50 個 Web 容器執行緒，最適合這種情況，因為所有 50 個執行緒都未被分配，並且併發工作負載平均使用大約 18 個執行緒。由於預設執行緒池大小已經足夠，因此不需要對執行緒池大小進行修改。

在 WebSphere Application Server V6.x 之前，併發客戶機連線與 Web 容器執行緒池中的執行緒之間存在一一對應的關係。換句話說，如果有 40 個客戶機在訪問應用程式，則有 40 個執行緒需要服務請求。在 WebSphere Application Server V6.0 和 6.1 中，由於引入了 Native IO (NIO) 和 Asynchronous IO (AIO)，因此能夠使用相對較少的執行緒來擴充套件數千客戶連線。這解釋了為何在圖 7 中平均只使用 18 個執行緒來服務來自 HTTP 負載驅動程式的 50 個併發客戶機連線。根據此資訊，可以減小執行緒池大小，以便降低管理大小超過需要的執行緒池的開源。但是，這會影響伺服器響應負載峰值（這時需要大量執行緒）的能力。應該通過仔細考慮來確定執行緒池的大小，包括預期的平均和峰值工作負載。

c. 連線池大小

每次當應用程式嘗試訪問後端庫時（比如資料庫），它都需要資源來建立、維持和釋放到該資料庫的連線。為了緩解此過程對總體應用程式資源的壓力，應用伺服器允許您建立一個後端連線池，用於在應用伺服器上共享應用程式。連線池將連線開銷分散分佈在若干使用者請求中，以便保留應用程式資源供未來請求使用。與連線池相關的重要調優選項如表 4 所示。

調優連線池的目標是確保各執行緒都有一個資料庫連線，並且請求不需要排隊以等待訪問資料庫。對於 DayTrader 應用程式來說，每個任務都需要對資料庫執行一次查詢。由於每個執行緒都需要執行一個任務，因此各併發執行緒都需要一個資料庫連線。通常，通過 HTTP 傳入的所有請求都將在 Web 容器執行緒上執行。因此，最大連線池大小至少應該達到 Web 容器執行緒池的最大大小。但是，有時請求會傳入到預設的執行緒池中，比如通過訊息傳遞 beans 的非同步模式。

總的來說，通用的最佳實踐是確定哪些執行緒池服務任務需要 DataSource 連線並相應調節池的大小。在本例中，最大連線池大小被設定為預設和 Web 容器執行緒池的最大大小 (70)。要修改連線池設定，可以在管理控制檯中導航到 Resources => JDBC => Data Sources => data_source => Connection pool properties。記住，從連線管理的角度來看，所有應用程式都不能具有 DayTrader 那麼優異的表現，因此可以為一個執行緒使用多個連線。

圖 8 顯示了 DayTrader 在穩定狀態峰值負載下使用預設連線池大小（1 最小/10 最大）執行時連線池的 PMI 資料。FreePoolSize（黃色）是池中空閒連線的數量，而 UseTime（綠色）是連線所使用的平均時間（毫秒）。從此圖中可以看出所有 10 個連線始終都在使用中。除了表格指標之外，該表還顯示其他一些重要指標：WaitingThreadCount 顯示 33 個執行緒等待資料庫連線的平均 WaitTime 為 8.25 ms，並且 PercentUsed 指標表明池的總體佔用率為 100%。

圖 9 顯示了將連線池大小調優為 10（最小）/70（最大）後的同一表。這表明有大量空閒連線可用，且沒有執行緒在等待連線，從而實現了更快的響應速度。

更多資訊：

• 調優應用伺服器
• 資料訪問調優引數
• 為何希望效能審查程式

d. 資料來源語句快取大小

資料來源語句快取大小指定每次連線可以快取的經過準備的 JDBC 語句的數量。WebSphere Application Server 資料來源將優化經過準備的語句和可呼叫的語句，它可以快取未在活動連線中使用的語句。如果您的應用程式像 DayTrader 那樣使用許多語句，則增加此引數有時可以改善應用程式效能。要配置語句快取大小，可以導航到 Resources => JDBC => Data sources => data_source => WebSphere Application Server data source properties。

可以使用一些不同的方法來調優資料庫語句快取大小。其中一個技巧就是審查所有獨特的、經過準備的語句的應用程式程式碼（或從資料庫或資料庫驅動程式收集到的 SQL 跟蹤），並確保快取大小大於該值。其一種方法是迭代式的增加快取大小並在峰值穩定狀態負載下執行應用程式，直到 PMI 指標不再報告任何快取丟棄操作。圖 11 展示了連線池的相同 PMI 表，這次資料庫語句快取大小從預設值 （即 10）增加到了 60。PrepStmtCacheDiscardCount 指標（紅色）表示由於快取已滿而被丟棄的語句的數量。回過頭來看圖 9 中的表，在調優資料來源語句快取大小之前，被丟棄的語句的數量超過 170 萬條。而圖 11 顯示，調優快取大小後再也沒有出現丟棄語句的情況。

更多資訊：

• 資料訪問調優引數

e. ORB 通過引用傳遞

Object Request Broker (ORB) 通過引用傳遞選項確定，在處理 EJB 請求中涉及的引數物件時應該使用通過引用傳遞還是通過值傳遞語義。要找到此選項，在管理控制檯中導航到 Servers => Application Servers =>server_name => Object Request Broker (ORB)。預設情況下，此選項是禁用的，並且將各引數物件的副本傳遞給呼叫的 EJB 方法。與向已有引數物件傳遞簡單的引用相比，這種方式的開銷要高很多。

總的來說，ORB 通過引用傳遞選項基本上將呼叫的 EJB 方法作為本地呼叫對待（甚至對於帶遠端介面的 EJB），並避免必需的物件複製操作。如果遠端介面不是絕對必需的，則一種稍微簡單的、不需要調優的替代方案就是使用帶本地介面的 EJB。但是，使用本地而不是遠端介面，您會損失與遠端介面、分散式環境中的位置透明性以及工作負載管理功能相關的一些收益。

僅當 EJB 客戶機（即 servlet）和所呼叫的 EJB 模組位於相同的類載入器中時，ORB 通過引用傳遞選項才能夠帶來收益。這一需求意味著 EJB 客戶機和 EJB 模組必須部署在相同的 EAR 檔案中，並在相同的應用伺服器例項中執行。如果 EJB 客戶機和 EJB 模組被對映到不同的應用伺服器例項（通常表示為 split-tier），則必須使用通過值傳遞的語義來遠端呼叫 EJB 模組。

由於 DayTrader 應用程式在相同的 EAR 中包含 WEB 和 EJB 模組，並且兩者都將被部署到相同的應用伺服器例項中，因此 ORB 通過引用傳遞選項可用於實現效能提升。從圖 13 中的度量可以看出，此選項讓 DayTrader 從中顯著受益，來自 servlet 的所有請求都將通過遠端介面傳遞給無狀態會話 bean。但直接模式除外，這時 EJB 容器會繞道採用直接 JDBC 和手動事務。

更多資訊：

• Object Request Broker 調優指導方針

回頁首

高階調優

討論要點：

1. Servlet 快取
2. HTTP 傳輸永續性連線
3. 大分頁支援
4. 禁用未使用的服務
5. Web 伺服器位置

a. Servlet 快取

WebSphere Application Server 的 DynaCache 為伺服器所生成的物件和分頁分段提供了一個通用的記憶體快取服務。DistributedMap 和 DistributedObjectCache 介面可以在應用程式中用於快取和共享 Java 物件，其方法是將引用儲存到快取中的這些物件中以便隨後使用。另一方面，Servlet 快取使 servlet 和 JSP 響應分段能由一組可定製的快取規則來儲存和管理。

在 DayTrader 應用程式中，每次訪問使用者的主頁時都會顯示一個 Market Summary。該摘要資訊包含股票漲跌榜的前 5 名和後 5 名，以及當前的股票索引和交易量。此活動需要執行一些資料庫查詢操作，因此會造成載入使用者主頁出現顯著延時。藉助 servlet 快取，marketSummary.jsp 可以儲存在快取中，這可以從基本上避免這些開銷大的資料庫查詢操作，從而改善使用者主頁的響應速度。可以配置快取物件的重新整理間隔，清單 1 中的示例將該值設定為了 60 秒。Dynacache 還可以用於快取 DayTrader 中的其他 servlet/JSP 分段和資料。本例將演示通過快取來避免複雜的伺服器操作可以實現哪些改善。

要啟用 Servlet 快取，在管理控制檯中導航到 Servers => Application servers => server_name => Web container settings => Web container。必須在 cachespec.xml 檔案定義到要快取的 servlet 或 JSP 的 URI 路徑，該檔案位於 Web 模擬的 WEB-INF 目錄中。對於 DayTrader 中的 marketSummary.jsp 來說，cachespec.xml 的內容與清單 1 相似。

更多資訊：

• 任務概述：使用動態快取服務改善效能
• 通過 cachespec.xml 檔案配置可快取的物件

b. HTTP 傳輸持久連線

持久連線指定傳出的 HTTP 響應應該使用持久（保持活動狀態）連線，而不是在請求或響應交換後關閉的連線。在許多情況下，可以通過單一 HTTP 連線許可的持久請求的最大數量來實現效能提升。通過讓每個連線可支援的持久請求不受限制，SSL 連線可以顯著的效能改進，因為 SSL 連線會導致通過交換鍵和協調協議來完成 SSL 握手過程，從而增加開銷。通過最大限度地增加每個連線可處理的請求數量，可以最大限度地減小此開銷的影響。另外，通過保持連線為開啟狀態，而不是針對各請求開啟或關閉連線，響應速度快的高吞吐量的應用程式也可以實現效能提升。當此屬性設定為 0（零）時，連線將在應用伺服器執行過程中一直保持為開啟狀態。但是，如果涉及到安全性問題，則應該仔細考慮這項設定，因為當客戶機嘗試建立始終活動的連線時，此引數可以幫助防止拒絕訪問攻擊。

可以在管理控制檯中設定 HTTP 傳輸持久連線，方法是導航到 Servers => Application servers => server_name => Ports。然後，單擊與要更改的 HTTP 傳輸渠道設定相關的埠的 View associated transports。

在 DayTrader 測試的過程中，每個連線的最大持久請求數量（Maximum persistent requests per connection）的值從 100（預設）更改為不受限制。圖 15 中的表顯示了通過 HTTP（非 SSL）和 HTTPS（SSL）訪問簡單的 “Hello World” servlet 的吞吐量結果（在將每個連線的最大持久請求數量設定為不受限制之前和之後）。

更多資訊：

• HTTP 傳輸渠道設定

c. 大分頁支援

一些平臺支援建立一大塊相鄰的記憶體區，以便能夠使用比預設記憶體分頁大小更大的記憶體分頁。根據所使用的平臺，大記憶體分頁大小可以從 4 MB (Windows) 到 16 MB (AIX) 不等，而預設分頁大小隻有 4 KB。許多應用程式（包括基於 Java 的應用程式）經常能大分頁中受益，因為要管理的大分頁減少有助於降低 CPU 開銷。

要使用大記憶體分頁，首先需要在作業系統中定義並啟用它們

轉自：http://netcome.iteye.com/blog/627254