簡介

您能將任何這些陳述聯(lián)系起來嗎：

• 目前我們還未做任何性能測試。我們想做，但不確定從何處入手。
• 我們的應(yīng)用程序運(yùn)行得很好，但在開發(fā)團(tuán)隊(duì)發(fā)給我們一個(gè)更新版本用于部署后，我們在服務(wù)器上體驗(yàn)到了高得多的 CPU 使用率。高 CPU 使用率緣何而來？
• 我們將應(yīng)用程序從 2.0 版遷移到了 3.0 版，現(xiàn)在響應(yīng)時(shí)間是以前的 3 倍。是什么導(dǎo)致了這些延遲？
• 我們的應(yīng)用程序需要在接下來的 3 個(gè)月支持超過 40% 的用戶。除了簡單地向集群添加更多機(jī)器，我們還能為此準(zhǔn)備什么？

這些陳述代表著非常常見的場景，所以如果聽到任何這些熟悉的聲音，那么您并不孤單。本文的目標(biāo)是解決這些類型的情景，提供一些有關(guān)執(zhí)行測試的基本過程和可用的適用工具的一些最佳實(shí)踐建議?？傮w來講，這里討論的主要主題將幫助您：

• 編寫有用的性能測試案例。
• 駕馭不同的負(fù)載量以降低和提高利用率。
• 激勵(lì)關(guān)鍵性能和系統(tǒng)指標(biāo)。
• 與應(yīng)用程序開發(fā)周期并行地執(zhí)行性能測試。
• 使用 IBM Health Center 等工具查找性能瓶頸。
• 與開發(fā)團(tuán)隊(duì)合作修復(fù)瓶頸并重新度量。

回頁首

性能測試的重要作用

曾幾何時(shí)，性能測試被視為在部署到生產(chǎn)之前才做的事情。它常常只有非常少的工作量，沒有分配足夠的時(shí)間來識(shí)別和修復(fù)最終將在生產(chǎn)環(huán)境中出現(xiàn)的真實(shí)問題。要執(zhí)行合適的性能測試，一種普遍推薦的方法是實(shí)現(xiàn) 性能生命周期，其中性能測試計(jì)劃為開發(fā)工作的一部分，集成了迭代式測試作為新功能。這能夠在將所有功能部署到生產(chǎn)環(huán)境之前，就能夠很早地識(shí)別出瓶頸，并解決這些問題。

合適的性能測試的另一個(gè)好處是有機(jī)會(huì)調(diào)節(jié)環(huán)境（操作系統(tǒng)、JVM、應(yīng)用服務(wù)器、應(yīng)用程序和數(shù)據(jù)庫等）以實(shí)現(xiàn)最大性能。只有通過合適的性能測試，才能調(diào)節(jié)所評(píng)估的參數(shù)以確定它們是否提供了任何價(jià)值。許多用戶基于開發(fā)人員建議來設(shè)置 JVM 堆大小，不會(huì)調(diào)節(jié)其他任何參數(shù)，因?yàn)檫@被認(rèn)為沒有必要。您可能會(huì)很驚奇，只需執(zhí)行一些簡單的調(diào)節(jié)步驟，即可將為調(diào)節(jié)的環(huán)境所需的硬件量減少一半。本文將證明這一點(diǎn)。

使用一些簡單的調(diào)節(jié)過程，DayTrader 性能基準(zhǔn)測試應(yīng)用程序可處理兩倍于未調(diào)節(jié)環(huán)境的負(fù)載。這意味著相同數(shù)量的用戶可能只需使用一半的可用硬件資源即可支持。想想這能夠節(jié)省的成本。

除了在整個(gè)開發(fā)周期執(zhí)行迭代測試和用于調(diào)節(jié)用途的測試優(yōu)勢，廣泛性能測試的另一個(gè)主要優(yōu)勢是，能夠?qū)Ρ炔煌瑧?yīng)用程序和環(huán)境改變的結(jié)果。真實(shí)的性能測試會(huì)記錄關(guān)鍵指標(biāo)，使管理員能夠洞察可能出現(xiàn)的問題（稍后將討論）。回到上面的一種常見評(píng)論，許多用戶在遷移到更新的應(yīng)用程序版本時(shí)，都未準(zhǔn)備好找出問題的根源，因?yàn)樗麄儚奈磳?duì)以前的版本執(zhí)行合適的性能測試或記錄關(guān)鍵系統(tǒng)指標(biāo)。缺少此工作，具有更糟的應(yīng)用程序版本的測試服務(wù)器可能需要設(shè)置為一個(gè)對(duì)比點(diǎn)。有了此類型的數(shù)據(jù)，就可以容易得多地分析性能降級(jí)來自何處。

回頁首

合適的性能測試的最佳實(shí)踐

有兩條基本的合適性能測試最佳實(shí)踐，它們可總結(jié)如下：

• 改變用戶（或客戶端負(fù)載）數(shù)量。一個(gè)生產(chǎn)環(huán)境通常在一天之內(nèi)具有不同數(shù)量的活動(dòng)用戶。質(zhì)量測試可確保應(yīng)用程序在小負(fù)載和峰值（例如黑色星期五）負(fù)載下良好地執(zhí)行。這可能意味著請求之間的 “思考” 時(shí)間的更改和使用應(yīng)用程序的活動(dòng)用戶數(shù)量的更改。這么做的一種最佳方式是對(duì) 1 位活動(dòng)用戶、2 位用戶、4 位用戶、8 位用戶等執(zhí)行測試。您稍后將看到此方法的實(shí)際應(yīng)用。
• 記錄關(guān)鍵系統(tǒng)和性能指標(biāo)。應(yīng)該為所有場景記錄一些重要的指標(biāo)。對(duì)于每次性能運(yùn)行，要記錄的最重要指標(biāo)是：
  • 吞吐量（每秒請求數(shù)）
  • 響應(yīng)時(shí)間
  • 應(yīng)用服務(wù)器機(jī)器 CPU 利用率 %
  • 其他機(jī)器 CPU 利用率 %，如 Web 服務(wù)器、負(fù)載驅(qū)動(dòng)程序和數(shù)據(jù)庫（如適用）

只要使用了負(fù)載驅(qū)動(dòng)工具，就可以看到吞吐量和響應(yīng)時(shí)間指標(biāo)。對(duì)于 CPU 利用率、內(nèi)存利用率、磁盤 I/O 和網(wǎng)絡(luò)流量指標(biāo)，可以使用 Linux? 或 AIX? 上的 vmstat 或 nmon 工具進(jìn)行查看，或者使用 Windows? 上的任務(wù)管理器進(jìn)行查看。除了上述指標(biāo)之外，記錄所有系統(tǒng)級(jí)信息也很重要。這包括操作系統(tǒng)級(jí)別、活動(dòng)核心數(shù)量、可用內(nèi)存 (RAM) 量、“Java? 版本” 輸出、WebSphere Application Server 版本信息，以及所有已應(yīng)用的調(diào)節(jié)。記錄所有這些指標(biāo)使您能夠迅速對(duì)比不同場景，即使對(duì)比的場景的測試時(shí)間已相隔兩年。

許多用戶沒有可用于再現(xiàn)與測試環(huán)境大小相同的生產(chǎn)環(huán)境的硬件。在這些情況下，推薦的方法是基于可用的資源來擴(kuò)展性能測試。例如，假設(shè)一個(gè)生產(chǎn)環(huán)境包含 10 個(gè)物理機(jī)器，每個(gè)機(jī)器運(yùn)行兩個(gè) WebSphere Application Server 實(shí)例。如果一個(gè)物理機(jī)器都可用于性能測試工作，那么此機(jī)器可設(shè)置為與生產(chǎn)機(jī)器盡可能相同，并且性能測試中使用的負(fù)載將大約為預(yù)期生產(chǎn)工作負(fù)載的 10%。最終，應(yīng)該擴(kuò)展性能測試，以再現(xiàn)完整的生產(chǎn)環(huán)境。這樣，其他流程（比如數(shù)據(jù)庫和 LDAP）的負(fù)載也會(huì)進(jìn)行測試。

回頁首

測試案例和負(fù)載驅(qū)動(dòng)程序

執(zhí)行性能測試和查找應(yīng)用程序瓶頸的第一步是編寫有用的測試案例。結(jié)果和分析取決于用于生成它們的測試案例，所以這一步不應(yīng)輕率地執(zhí)行。與對(duì)所有用戶都將使用的代碼路徑執(zhí)行壓力測試相比，對(duì)用戶僅花了不到 10% 的時(shí)間的應(yīng)用程序代碼路徑執(zhí)行壓力測試的效果差得多。首先專注于最流行的代碼路徑，然后為更少利用的代碼路徑構(gòu)建您自己的測試。在這里花一些時(shí)間真正創(chuàng)建一個(gè)模擬實(shí)際用戶流量的高質(zhì)量測試案例。這篇 developerWorks 文章 是幫助開始編寫性能測試案例的一個(gè)不錯(cuò)的資源。

定義了測試案例概念之后，您將需要通過一個(gè)性能負(fù)載驅(qū)動(dòng)工具將它應(yīng)用于實(shí)踐。有許多負(fù)載驅(qū)動(dòng)程序可供選擇，包括 IBM Rational Performance Tester 和 Apache 的開源 Jmeter。本文將使用后者。

回頁首

DayTrader 示例

如果您之前閱讀過 developerWorks 上的任何性能文章，那么您很可能已聽說過 “Trade” 或 “DayTrader” 基準(zhǔn)測試。Apache DayTrader Performance Benchmark Sample 應(yīng)用程序模擬了一個(gè)簡單的股票交易應(yīng)用程序，它讓用戶登錄/注銷、查看他們的投資組合，查找股票報(bào)價(jià)，購買和銷售股票，并管理帳戶信息。DayTrader 不僅可用作功能測試的出色應(yīng)用，還提供了一組標(biāo)準(zhǔn)的工作負(fù)載集來描繪和度量應(yīng)用服務(wù)器和組件級(jí)性能。

DayTrader 構(gòu)建于一組核心的 Java EE 技術(shù)之上，包括用于表示層的 Java servlet 和 JavaServer? Pages (JSP)，以及用于后端業(yè)務(wù)邏輯和持久性層的 Java 數(shù)據(jù)庫連接 (JDBC)、Java Message Service (JMS)、Enterprise JavaBeans (EJBs) 和消息驅(qū)動(dòng)的 bean (MDB)。圖 1 給出了該應(yīng)用程序架構(gòu)的總體概述。

IBM 發(fā)布了一個(gè)樣例 DayTrader 包 供下載，它包含 DayTrader 應(yīng)用程序和所需的部署描述符，可以將它們安裝在 WebSphere Application Server V7.0 或更高版本上。

在此示例中，將 DayTrader 樣例應(yīng)用程序部署成了 WebSphere Application Server V8.5 的一個(gè)基本實(shí)例。一個(gè)簡便的 DayTrader 功能是 Configuration 選項(xiàng)卡下的 TradeScenarioServlet 鏈接。它會(huì)鏈接到模擬一群 Web 用戶的一個(gè) servlet，為每個(gè)訪問該 servlet 的用戶隨機(jī)生成具體的 DayTrader 操作。（例如，一個(gè)用戶可查看他的投資組合、一個(gè)用戶可執(zhí)行股票購買操作，一個(gè)用戶可查找一個(gè)股票報(bào)價(jià)等）。這可確保 DayTrader 中的每個(gè)主要操作都會(huì)在測試期間執(zhí)行，因?yàn)樗请S機(jī)的，所以一段時(shí)間后每個(gè)操作都應(yīng)執(zhí)行大體相同的次數(shù)。有許多參考資料介紹了如何使用 JMeter 編寫非常復(fù)雜的性能測試，其中可為每個(gè)操作指定使用的準(zhǔn)確次數(shù)和使用順序，但出于本文的用途，測試案例將會(huì)保持相對(duì)簡單并使用此 TradeScenarioServlet。

回頁首

使用 JMeter

設(shè)置 Jmeter 并運(yùn)行它來執(zhí)行性能測試：

1. 安裝 Jmeter。指向您的 java 目錄，使用 jmeter.sh 或 jmeter.bat 腳本從 <JMeter_Home>/bin/ 目錄啟動(dòng) JMeter。您應(yīng)看到一個(gè)類似圖 2 的面板。
   
   圖 2. JMeter 默認(rèn)試圖
   
   
   
   
   
2. 右鍵單擊 Test Plan 并轉(zhuǎn)到 Add > Thread Group。這是您定義要處理其負(fù)載的用戶數(shù)量的地方。對(duì)于初學(xué)者，使用以下值（參見圖 3）：
   • 線程（用戶）數(shù)量：1
   • 循環(huán)數(shù)量：Forever
   
   
   圖 3. JMeter Thread Group 視圖
   
   
   
   
   
3. 右鍵單擊您剛創(chuàng)建的線程組，轉(zhuǎn)到 Add > Sampler。一個(gè)抽樣器 (sampler) 定義您希望處理的負(fù)載類型。有針對(duì) HTTP 請求、JMS 請求、Web 服務(wù)消息等的抽樣器。JMeter 用戶手冊記錄每個(gè)可用的抽樣器。因?yàn)?DayTrader 支持基于 Web 的流量，所以此示例使用 HTTP Request。依據(jù)您的環(huán)境填寫主機(jī)名、端口和路徑的值（參見圖 4）。
   
   圖 4. HTTP 請求
   
   
   
   
   
4. 右鍵單擊您剛創(chuàng)建的 HTTP 請求并選擇 Add > Timer。計(jì)時(shí)器添加請求之間的 “思考時(shí)間”。這模擬一個(gè)用戶單擊一個(gè)頁面，然后暫停閱讀頁面上的一些信息，最后發(fā)出另一個(gè)請求。您可選擇許多預(yù)定義的計(jì)時(shí)器，具有從常量固定計(jì)時(shí)器到高斯或泊松分布式計(jì)時(shí)器的不同復(fù)雜度。JMeter 用戶手冊 記錄每個(gè)可用的計(jì)時(shí)器。對(duì)于這個(gè)簡單示例，僅使用 5 ms 的 Constant Timer。
5. 右鍵單擊該線程組并轉(zhuǎn)到 Add > Listener > Summary Report。這將顯示測試運(yùn)行時(shí)的響應(yīng)時(shí)間和吞吐量結(jié)果。
6. 將設(shè)置保存到一個(gè)文件，以便您可在以后再次加載它們。

回頁首

運(yùn)行測試

在啟動(dòng)負(fù)載驅(qū)動(dòng)工具之前，始終要確保應(yīng)用程序兼容一個(gè)瀏覽器。準(zhǔn)備好后，單擊綠色箭頭或單擊 Run > Start。JMeter 現(xiàn)在應(yīng)將一個(gè)客戶端連接到您指定的服務(wù)器路徑，在每個(gè)請求之間等待 5 ms。如果您單擊 Summary Report，可以看到測試運(yùn)行的結(jié)果。

您應(yīng)會(huì)注意到，吞吐量在不斷增長；這稱為 “升溫” 階段。JRE 需要一些升溫時(shí)間來加載所有類，讓 JIT 執(zhí)行一些優(yōu)化。吞吐量最終將穩(wěn)定，達(dá)到一個(gè)固定的數(shù)量（每秒發(fā)出或接受一些請求）。依賴于測試的復(fù)雜性，這個(gè)升溫階段可能持續(xù) 30 秒，也可能持續(xù) 30 分鐘。

在測試運(yùn)行時(shí)，打開一個(gè)終端（Linux 或 AIX）并運(yùn)行 vmstat 5 來每隔 5 秒顯示一次系統(tǒng)指標(biāo)（參見清單 1）。

				[root@spice3 bin]# vmstat 5 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st  0  0      0 8235164 104920 500956    0    0    13    11   44  154  8  5 86  0  0  0  0      0 8235164 104928 500956    0    0     0     3 8030 4987  6  1 93  0  0  1  0      0 8235040 104936 500956    0    0     0     3 7982 4944  5  1 94  0  0  0  0      0 8233116 104936 500960    0    0     0     6 8126 5020  7  1 92  0  0  0  0      0 8231068 104944 500960    0    0     0     6 7952 4939  6  1 93  0  0  0  0      0 8231316 104952 500960    0    0     0     3 7761 4819  5  1 94  0  0 Example vmstat output showing ~7% CPU utilization.

如果使用 Windows，右鍵單擊任務(wù)欄并選擇任務(wù)管理器，然后選擇性能選項(xiàng)卡。當(dāng) JMeter 中的吞吐量達(dá)到一個(gè)穩(wěn)定值后，記錄運(yùn)行 WebSphere Application Server 的服務(wù)器和任何其他適用服務(wù)器上的 CPU 利用率，然后單擊紅色停止標(biāo)志或 Run > Stop 停止 Jmeter 測試。JMeter Summary Results 視圖類似于圖 5。

在一個(gè)電子表格中，記錄吞吐量結(jié)果（93.9 個(gè)請求/秒）和平均響應(yīng)時(shí)間結(jié)果 (4 ms)。如果您希望更詳細(xì)的信息，那么 Min、Max 和 Std. Dev. 響應(yīng)時(shí)間也很有用。

記錄所有結(jié)果后，選擇 Run > Clear 來清除 Summary Report 結(jié)果。這會(huì)介紹對(duì)單個(gè)用戶的測試。現(xiàn)在將用戶數(shù)量依次增加到 2、4、8 等，并重復(fù)上述步驟。每次添加更多用戶時(shí)您都應(yīng)觀察到吞吐量增長。最終，您會(huì)觀察到吞吐量停止增長，甚至可能開始下降。達(dá)到平穩(wěn)狀態(tài)（以及可能下降）時(shí)，測試即可停止。

回頁首

分析結(jié)果

完成上述步驟后，您應(yīng)得到一個(gè)類似圖 6 的電子表格。（這些具體的結(jié)果高度依賴于 DayTrader 應(yīng)用程序和運(yùn)行此測試的環(huán)境。您的實(shí)際結(jié)果可能有很大不同。）

擁有這樣的表列格式的原始數(shù)據(jù)很有用，但以圖形格式查看結(jié)果也很有用?？梢暬Y(jié)果的一種最佳方式是使用 XY 散點(diǎn)圖。繪制一個(gè)圖表來描繪結(jié)果，會(huì)使趨勢的識(shí)別容易得多。圖 7 描繪了吞吐量和 WebSphere Application Server CPU % 與客戶端數(shù)量的關(guān)系。

上面的圖 7 顯示了一些有趣的特征。首先，可以看到吞吐量曲線和 CPU % 曲線非常接近。第二，可以看到應(yīng)用程序吞吐量從 1 個(gè)客戶端近線性地?cái)U(kuò)展到 500 個(gè)客戶端。這是想要的結(jié)果。但是，在 500 個(gè)客戶端到 1,000 個(gè)客戶端之間的某個(gè)點(diǎn)，吞吐量的增速開始放緩。（這時(shí)可使用 500 到 1,000 之間的用戶負(fù)載來執(zhí)行更多測試，以查找發(fā)生此增速放緩現(xiàn)象的準(zhǔn)確位置。）將客戶端負(fù)載增加到 1,000 個(gè)客戶端以上不會(huì)改進(jìn)總體應(yīng)用程序吞吐量。這就是所謂的飽和點(diǎn)。這是一個(gè)重要的值，必須在性能測試中找到。飽和點(diǎn)告訴您，您已達(dá)到此應(yīng)用程序、調(diào)節(jié)、配置和環(huán)境的最大容量。添加超過此點(diǎn)的更多用戶只會(huì)增加客戶端響應(yīng)時(shí)間，不會(huì)增加總體應(yīng)用程序吞吐量。要獲得超過此點(diǎn)的更高性能，必須執(zhí)行應(yīng)用程序代碼更改、調(diào)節(jié)更改或環(huán)境更改。

這種類型的測試和分析是大小調(diào)整和容量規(guī)劃討論中主要主題。只有通過識(shí)別飽和點(diǎn)，您才能準(zhǔn)確估算支持一個(gè)生產(chǎn)環(huán)境所需的總?cè)萘俊３３Ｓ腥藭?huì)說，“我需要在此環(huán)境中支持 10,000 個(gè)用戶”，然后對(duì)該客戶端負(fù)載運(yùn)行測試。通常，此方法會(huì)在一個(gè)或多個(gè)組件中引起各種各樣的超負(fù)荷情形，這些情形可能在 WebSphere Application Server 中，也可能在其他基礎(chǔ)設(shè)施組件（網(wǎng)絡(luò)、數(shù)據(jù)庫等）中。一種更高效的方法是確定使用單個(gè)應(yīng)用服務(wù)器可獲得何種客戶端負(fù)載和吞吐量，然后基于此信息繼續(xù)執(zhí)行運(yùn)行時(shí)和應(yīng)用程序調(diào)節(jié)。調(diào)節(jié)完成后，可將注意力轉(zhuǎn)向確定滿足可伸縮性需求需要多少應(yīng)用服務(wù)器流程和流程服務(wù)器。

將一個(gè)新測試保存在 JMeter 中，使用您找到的線程（用戶）數(shù)作為飽和點(diǎn)。這可用作一項(xiàng)快速測試，以對(duì)比您對(duì)應(yīng)用程序或環(huán)境執(zhí)行更改時(shí)的性能，而無需再次執(zhí)行完整的可伸縮性測試。這不是說您不應(yīng)再執(zhí)行可伸縮性測試，但對(duì)于在 CPU 未充分利用的更低負(fù)載上不會(huì)顯示出任何不同的更改，運(yùn)行飽和點(diǎn)上的負(fù)載是對(duì)比這些更改的一個(gè)不錯(cuò)地方。一種不錯(cuò)的做法是對(duì)次要應(yīng)用程序或調(diào)節(jié)更改運(yùn)行飽和點(diǎn)負(fù)載，對(duì)主要應(yīng)用程序或環(huán)境更改重復(fù)完整的可伸縮性測試。

回頁首

性能工具

以上各節(jié)是執(zhí)行任何真實(shí)分析工作的準(zhǔn)備條件。您必須首先理解如何生成可重復(fù)的性能結(jié)果，才能查找瓶頸和性能改進(jìn)?，F(xiàn)在您已準(zhǔn)備好查找改進(jìn)了，應(yīng)使用以下兩個(gè)性能工具來開始分析：

• IBM Tivoli? Performance Viewer

  Tivoli Performance Viewer（在管理控制臺(tái)中）是一個(gè)監(jiān)視 WebSphere Application Server 的非常有用的工具。這篇文章 重點(diǎn)介紹了使用 Tivoli Performance Viewer 最優(yōu)地調(diào)節(jié)環(huán)境的好處。采用相同的方式，Tivoli Performance Viewer 可用于快速檢查是否有任何可通過調(diào)節(jié)輕松刪除的瓶頸。

  以下是一些開始使用 Tivoli Performance Viewer 的簡單步驟：

  1. 使用比確定為飽和點(diǎn)的用戶數(shù)量重新啟動(dòng) JMeter 負(fù)載。
  2. 登錄到管理控制臺(tái)并選擇 Monitoring and Tuning > Performance Viewer > Current Activity。單擊您希望監(jiān)視的服務(wù)器，然后展開 Performance Modules。這將顯示一組可供查看的性能模塊。
  3. 您的應(yīng)用程序特征將確定其中哪些模塊最有必要查看。對(duì)于 DayTrader 示例或任何其他基于 Web 的流量，啟動(dòng) Thread Pools > WebContainer 模塊。勾選該復(fù)選框，單擊頂部的 View Module 按鈕。這將顯示一個(gè)類似于圖 8 的圖表，在 JMeter 測試?yán)^續(xù)運(yùn)行時(shí)，每隔 30 秒自動(dòng)填充更多數(shù)據(jù)。
     
     圖 8. WebContainer PMI 數(shù)據(jù)
     
     
     
     
     

     此示例顯示，WebContainer 線程池大小為 50 個(gè)線程，其中大約 32 個(gè)正在使用。這告訴您，WebContainer 線程池大小不是當(dāng)前工作負(fù)載下的瓶頸。如果活動(dòng)數(shù)量在 45-50 之間波動(dòng)，那么 WebContainer 線程池大小可能是一個(gè)瓶頸。在該情況下，可能最好增加 WebContainer 線程池大小，重復(fù)該測試以查看性能是否改進(jìn)。如果吞吐量確實(shí)增加了，您可能希望再次運(yùn)行灣鎮(zhèn)的可伸縮性測試，以重新建立基準(zhǔn)。

  4. 對(duì)其他適用于您的應(yīng)用程序的模塊繼續(xù)重復(fù)第 3 步。對(duì)于 DayTrader 這樣的事務(wù)應(yīng)用程序，應(yīng)查看的另一個(gè)模塊是 JDBC Connection Pool 信息。展開 JDBC Connection Pools > 您的 JDBC 驅(qū)動(dòng)程序），選擇您的數(shù)據(jù)源 JNDI 名稱。單擊 View Module 按鈕以顯示一個(gè)類似圖 9 的圖表。
     
     圖 9. DataSource PMI 數(shù)據(jù)
     
     
     
     
     

     此圖表描繪了一些與默認(rèn)選擇不同的選項(xiàng)。PoolSize、FreePoolSize 和 WaitingThreadCount 都是很有用的指標(biāo)，可查看它們來確保您的連接池不是爭用來源，WebContainer 線程沒有排隊(duì)等待連接數(shù)據(jù)庫。在上面的示例中，連接池大小固定為 50 個(gè)連接（這是一項(xiàng)調(diào)節(jié)設(shè)置）?？臻e池大小在 20 上下波動(dòng)，這意味著一次有大約 30 個(gè)連接是活動(dòng)的。從這些信息得到的是一個(gè) Waiting Thread Count 0，表明沒有 WebContainer 線程在等待連接數(shù)據(jù)庫。這可確認(rèn) JDBC 連接池大小不是瓶頸。如果空閑池大小為 0，并且等待的線程數(shù)量大于 0，那么您可能希望使用更高的連接池大小重復(fù)測試。

  對(duì)有助于監(jiān)視您的應(yīng)用程序的任何其他性能模塊繼續(xù)執(zhí)行此過程。WebSphere 反向投資者：應(yīng)對(duì)故障 提供一個(gè)全面的統(tǒng)計(jì)信息列表，這些信息可能具有很高的監(jiān)視價(jià)值。完成此練習(xí)后，您可轉(zhuǎn)而使用 IBM Health Center 執(zhí)行更詳細(xì)的分析。
• IBM Monitoring and Diagnostic Tools for Java - Health Center

  IBM Monitoring and Diagnostic Tools for Java - Health Center（以下簡稱 Health Center，它包含在 IBM Support Assistant 中）工具是在 WebSphere Application Server 進(jìn)程上執(zhí)行詳細(xì)的性能分析的推薦工具。Health Center 提供了有關(guān)服務(wù)器性能的豐富知識(shí)，包括以下信息：

  • 內(nèi)存使用
  • 垃圾收集統(tǒng)計(jì)信息
  • 方法級(jí)探查
  • 鎖爭用分析。

  Health Center 是 IBM Support Assistant (ISA) 中的一個(gè)工具，可免費(fèi)下載。請確保將 ISA 安裝在一個(gè)不同于應(yīng)用服務(wù)器機(jī)器的機(jī)器上，否則 Health Center 將占用應(yīng)用服務(wù)器進(jìn)程中的資源，您的結(jié)果也可能不太準(zhǔn)確。Health Center 可在一種交互式模式下運(yùn)行，也可在一種 “無頭” 模式（其中的信息保存在一個(gè)文件中供以后查看）中運(yùn)行。對(duì)于此示例，您將使用交互式模式。

  啟動(dòng) Health Center：

  1. 重新啟動(dòng)您希望使用一般 JVM 參數(shù) -Xhealthcenter 獲得其詳細(xì)信息的 WebSphere Application Server 進(jìn)程。
  2. 啟動(dòng) ISA。當(dāng)加載時(shí)，選擇 Analyze Problem。（如果以前已完成此過程，您將需要告訴 ISA，您對(duì) WebSphere Application Server 的工具感興趣。）
  3. 選擇 IBM Monitoring and Diagnostic Tools for Java – Health Center 并單擊 Launch（參見圖 10）
     
     圖 10. 從 ISA 啟動(dòng) Health Center
     
     
     
     
     
  4. 將顯示一個(gè)連接向?qū)А螕?Next。指定應(yīng)用服務(wù)器運(yùn)行時(shí)使用的主機(jī)名或 IP 地址。在默認(rèn)情況下，將使用端口 1972。如果有任何安全需求，可在這里指定它們，否則單擊 Next。如果找到了主機(jī)名和端口，再次單擊 Next，否則查明為什么連接無效。如果成功，Health Center 將類似于圖 11。
     
     圖 11. Health Center 默認(rèn)視圖
     
     
     
     
     
  5. 最大化 Health Center 的屏幕并單擊它，以了解它的功能?，F(xiàn)在，您已準(zhǔn)備好開始一些詳細(xì)的性能分析了（接下來幾節(jié)將進(jìn)行介紹）。繼續(xù)使用在您的飽和點(diǎn)上找到的用戶數(shù)量重新啟動(dòng) JMeter 負(fù)載。Health Center 將在新信息可用時(shí)動(dòng)態(tài)地更新。讓 JMeter 負(fù)載在您的升溫階段持續(xù)運(yùn)行，然后再繼續(xù)操作。

回頁首

垃圾收集分析

任何 Java 應(yīng)用程序性能分析中的第一步始終應(yīng)為分析垃圾收集統(tǒng)計(jì)信息。保持 Health Center 正常運(yùn)行，這很很容易做到。

單擊 Health Center 窗口中的 Garbage Collection 鏈接。將顯示一個(gè)類似圖 12 的視圖。

對(duì)于入門級(jí)分析，首先應(yīng)檢查兩件事：

• 左下角的 Analysis and Recommendations 部分提供了基于 Health Center 中內(nèi)置智能構(gòu)建的有用技巧和信息。這些技巧可能表示垃圾收集策略和堆大小建議，以及有關(guān)內(nèi)存泄漏或 System.gc() 調(diào)用的觀察值，等等。在圖 12 中，該部分告訴您，gencon 是 DayTrader 的一個(gè)最優(yōu)的 GC 策略，該應(yīng)用程序似乎不會(huì)泄漏內(nèi)存。這始終是一個(gè)不錯(cuò)的起點(diǎn)。
• 窗口底部的 Summary 面板包含您應(yīng)關(guān)注的最重要的統(tǒng)計(jì)數(shù)據(jù)，從 “Proportion of time spent in Garbage Collection pauses” 開始。這項(xiàng)統(tǒng)計(jì)信息告訴您，您的應(yīng)用程序由于發(fā)生垃圾收集而停止的時(shí)間比例。這個(gè)數(shù)字應(yīng)盡可能低，理想情況下低于 2-3%。如果此數(shù)字為 10%，那么通過調(diào)節(jié) JVM 堆大小和垃圾收集策略，可實(shí)現(xiàn)高達(dá) 10% 的吞吐量提升。如前所述，這個(gè)案例分析是一篇可幫助指導(dǎo)您執(zhí)行調(diào)節(jié)過程的優(yōu)秀文章。

其他一些能夠幫助您查找您最感興趣數(shù)據(jù)的技巧包括：

• 圖 12 中的圖表中的 X 軸顯示自服務(wù)器啟動(dòng)以運(yùn)行的時(shí)間。您可更改此值以繪制一天的圖表。這可能對(duì)關(guān)聯(lián)在一天某些時(shí)刻發(fā)生的活動(dòng)有所幫助。X 軸可通過選擇上下文菜單 > Change Units > X-Axis > Time 來更改。
• 您可剪切數(shù)據(jù)來消除預(yù)熱期，以獲得在正常活動(dòng)條件下所發(fā)生事情的更準(zhǔn)確視圖。為此，選擇 Data > Crop Data（以剪掉開始和完成時(shí)間）或者選擇 Data > Reset Data 來清除截至此時(shí)刻的任何數(shù)據(jù)。
• 對(duì)于更詳細(xì)的分析，單擊 Samples by object 選項(xiàng)卡。這使您能夠看到分配對(duì)象的故障、為每種類型分配的對(duì)象數(shù)量，以及的對(duì)象總大小的統(tǒng)計(jì)分析。甚至可以選擇按包或?qū)ο竺麃硭阉?。圖 13 顯示了一個(gè)示例?；谶@些結(jié)果，檢查應(yīng)用程序代碼以查看是否可減少的 BigDecimal 和 BigInteger 的使用，這可能是一個(gè)不錯(cuò)的想法。

回頁首

方法探查分析

保持負(fù)載驅(qū)動(dòng)程序運(yùn)行，單擊 Profiling 鏈接。這將打開 Method Profiling 視圖，類似于圖 14。

Method Profile 表顯示了哪些方法正在使用大部分處理資源。這是整個(gè) JVM 的視圖，而不是您的具體應(yīng)用程序的視圖，所以這將包含數(shù)據(jù)庫驅(qū)動(dòng)程序、WebSphere Application Server 容器等的方法信息。查看此視圖來從更大范圍內(nèi)了解服務(wù)器中所發(fā)生的事情，這很有幫助。與前面的垃圾收集分析一節(jié)中一樣，一個(gè)最佳的起點(diǎn)的是 Analysis and Recommendations 部分。此面板將突出已發(fā)現(xiàn)使用了比其他方法多得多的 CPU 周期的任何方法。在上面的示例中，技巧表明沒有明顯的優(yōu)化方法，因?yàn)樗兄芷诙际蔷鶆虿鸱值?。如果這里顯示了一個(gè)或兩個(gè)方法，那么應(yīng)檢查該方法的代碼，以查看是否可執(zhí)行任何優(yōu)化，或者調(diào)用次數(shù)是否可以減少。

為了更深入研究，您需要理解如何解釋表中的數(shù)據(jù)。要獲取幫助，請參閱 Health Center 文檔，方法是選擇 Help > Help Contents，然后向下滾動(dòng)并展開 Tool: IBM Monitoring and Diagnostic Tools for Java - Health Center 圖書。該文檔表明：

具有更高的 Self (%) 值的方法描述為 “熱的”，是優(yōu)化的不錯(cuò)候選者。對(duì)這些方法的效率的細(xì)微改進(jìn)可能對(duì)性能具有巨大影響。您可通過減少方法做的工作量或減少調(diào)用它們的次數(shù)來優(yōu)化它們。接近表末尾的方法不太適合優(yōu)化。甚至對(duì)它們效率的巨大改進(jìn)也不可能會(huì)影響性能，因?yàn)樗鼈兪褂玫奶幚碣Y源很少。

以下是對(duì)表中每列的描述：

單擊列標(biāo)題，按升序或降序?qū)λ羞@些列排序。理解這一點(diǎn)后，您可深入分析工作負(fù)載的性能特征。導(dǎo)航此表的一些有用技巧包括：

• 單擊表中的一行將顯示底部面板中顯示執(zhí)行該方法的完整調(diào)用路徑。
• 在探查有效期間執(zhí)行該方法時(shí)，將顯示 Timeline 選項(xiàng)卡。這可能很有用，您無需關(guān)注配置文件中在之前（或許在升溫期間）執(zhí)行的某項(xiàng)功能，然后離開。
• Filter methods 文本框?qū)λ阉魈囟惡瓦^濾配置文件的剩余部分很有用。這僅應(yīng)用于下鉆您應(yīng)用程序的詳細(xì)信息，以刪除所有其他非應(yīng)用程序類。作為一個(gè)示例，圖 15 顯示了按 “daytrader” 過濾的配置文件，因?yàn)樗?DayTrader 應(yīng)用程序類的包名稱中都包含 “daytrader”。這使您能夠集中精力查找應(yīng)用程序中使用資源最多的方法。

如果應(yīng)用程序有一個(gè)特定的方法使用了大量 CPU 周期，然后 Health Center 將它標(biāo)記為 Analysis and Recommendations 面板中一個(gè)不錯(cuò)的優(yōu)化候選者。一個(gè)示例如圖 16 所示。

可花幾天時(shí)間分析 Method Profiling 視圖，以查找一個(gè)應(yīng)用程序的性能改進(jìn)。因?yàn)檩敵隹杀４娴揭粋€(gè)文件中，所以對(duì)比應(yīng)用程序更改非常簡單。應(yīng)用程序開發(fā)人員可執(zhí)行一項(xiàng)通過 Health Center 掛鉤來部署和執(zhí)行負(fù)載測試的更改，并且您可對(duì)比以前的配置文件信息，查看開發(fā)人員更改的方法增加還是降低了處理需求。

回頁首

鎖定分析

多線程應(yīng)用程序需要同步（或鎖定）共享資源，以使資源的狀態(tài)保持一致。這種一致性可確保在一個(gè)線程讀取另一個(gè)線程時(shí)，該線程的狀態(tài)不會(huì)更改。

當(dāng)在具有大量處理器的系統(tǒng)上部署的高負(fù)載應(yīng)用程序中使用鎖時(shí)，鎖定操作可預(yù)防應(yīng)用程序使用所有可用的處理資源。想象一下一個(gè)在 8 核機(jī)器上運(yùn)行的應(yīng)用程序，它的主要應(yīng)用程序代碼路徑高度同步，所以一次只能執(zhí)行一個(gè)線程。這可能使其他 7 個(gè)線程處于等待狀態(tài)。

當(dāng)在大型的多核（4 個(gè)以上）機(jī)器上運(yùn)行時(shí)，鎖分析對(duì)確保應(yīng)用程序可擴(kuò)展并利用所有可用的硬件資源至關(guān)重要。（如果應(yīng)用程序在單核機(jī)器上運(yùn)行，這里的分析可能沒有太大價(jià)值。）Locking 透視圖分析鎖的使用，幫助識(shí)別應(yīng)用程序或 Java 運(yùn)行中阻止應(yīng)用程序擴(kuò)展的爭用點(diǎn)。單擊 Locking 鏈接后，應(yīng)會(huì)顯示一個(gè)類似于圖 17 的面板。

初看起來，Moniors 視圖可能很難使用和理解。但是，Health Center 文檔詳細(xì)描述了這個(gè)面板，以幫助您理解這些指標(biāo)。表 2 描述了該表中的列的內(nèi)容。

該表列出了被充實(shí)的每個(gè) Java 監(jiān)視器。% miss 列是最初的關(guān)注點(diǎn)。高 % miss 表明受鎖保護(hù)的同步化資源上發(fā)生了頻繁的爭用。這種爭用可能阻止 Java 應(yīng)用程序進(jìn)一步擴(kuò)展。

如果一個(gè)鎖具有一個(gè)較高的 % miss 值，請查看 Average hold time 和 % util。一些技巧如下：

• 如果 % util 和 Average hold time 都很高，您可能需要減少在持有鎖期間執(zhí)行的工作量。
• 如果 % util 很高，但 Average hold time 很低，您可能需要使受鎖保護(hù)的資源更加細(xì)粒度地將該鎖分離為多個(gè)鎖。

回頁首

結(jié)束語

沒有正確的工具和知識(shí)，開始執(zhí)行性能測試和分析最初可能會(huì)很難。但是，本文表明，用戶可以執(zhí)行一些較簡單的步驟來確保執(zhí)行正確的性能測試，并確保應(yīng)用程序瓶頸已消除，從而盡可能高效地執(zhí)行應(yīng)用程序。

即使 DayTrader 可能與您的應(yīng)用程序不同，但本文中描述的測試性能和識(shí)別瓶頸的方法所發(fā)揮的作用是相同的。對(duì)較慢時(shí)期的小用戶負(fù)載一直到峰值使用時(shí)期的高用戶負(fù)載執(zhí)行測試，這對(duì)理解您應(yīng)用程序的特征至關(guān)重要。記錄一些關(guān)鍵指標(biāo)，用它們來對(duì)比應(yīng)用程序或環(huán)境更改，這對(duì)理解性能降級(jí)的可能根源至關(guān)重要。最后，IBM Health Center 工具通過垃圾收集、方法探查和鎖探查視圖簡化了性能分析，幫助您確保盡可能高效地執(zhí)行應(yīng)用程序。

參考資料

學(xué)習(xí)

• WebSphere Application Server 性能
  
  
• IBM Monitoring and Diagnostic Tools for Java - Health Center Version 2.0
  
  
• 教程：Hello World：Rational Performance Tester 教程
  
  
• 圖書：Java 網(wǎng)站性能分析
  
  
• 傳統(tǒng)性能測試如何有效應(yīng)用于 SOA 解決方案？
  
  
• WebSphere 反向投資者：應(yīng)對(duì)故障
  
  
• 案例研究：調(diào)優(yōu) WebSphere Application Server V7 和 V8 的性能
  
  
• WebSphere 反向投資者: 調(diào)節(jié) WebSphere 應(yīng)用服務(wù)器時(shí)應(yīng)適可而止
  
  
• IBM developerWorks 中國 WebSphere 專區(qū)：為使用 WebSphere 產(chǎn)品的開發(fā)人員準(zhǔn)備的技術(shù)信息和資料。這里提供產(chǎn)品下載、how-to 信息、支持資源以及免費(fèi)技術(shù)庫，包含 2000 多份技術(shù)文章、教程、最佳實(shí)踐、IBM Redbook 和在線產(chǎn)品手冊。
  
  

獲得產(chǎn)品和技術(shù)

• 最受歡迎的 WebSphere 試用軟件下載：下載關(guān)鍵 WebSphere 產(chǎn)品的免費(fèi)試用版。
  
  
• IBM developerWorks 軟件下載資源中心：IBM deveperWorks 最新的軟件下載。
  
  
• IBM developerWorks 工具包：下載關(guān)鍵 WebSphere 最新的產(chǎn)品工具包。
  
  

討論

• 加入 developerWorks 中文社區(qū)，developerWorks 社區(qū)是一個(gè)面向全球 IT 專業(yè)人員，可以提供博客、書簽、wiki、群組、聯(lián)系、共享和協(xié)作等社區(qū)功能的專業(yè)社交網(wǎng)絡(luò)社區(qū)。
  
  
• 加入 IBM 軟件下載與技術(shù)交流群組，參與在線交流。
  
  

關(guān)于作者