人人IT網

人人IT網

當前位置: 主頁 > 服務器軟件 > Websphere >

使用 WebSphere Application Server 執行性能測試和分析

時間:2012-10-26 12:06來源:Internet 作者:Internet 點擊:
簡介 您能將任何這些陳述聯系起來嗎: 目前我們還未做任何性能測試。我們想做,但不確定從何處入手。 我們的應用程序運行得很好,但在開發團隊發给我們一個更新版本用於部署後,我

簡介

您能將任何這些陳述聯系起來嗎:

  • 目前我們還未做任何性能測試。我們想做,但不確定從何處入手。
  • 我們的應用程序運行得很好,但在開發團隊發给我們一個更新版本用於部署後,我們在服務器上體驗到了高得多的 CPU 使用率。高 CPU 使用率緣何而來?
  • 我們將應用程序從 2.0 版遷移到了 3.0 版,現在響應時間是以前的 3 倍。是什麼導致了這些延遲?
  • 我們的應用程序需要在接下來的 3 個月支持超過 40% 的用戶。除了簡單地向集群添加更多機器,我們還能为此准備什麼?

這些陳述代表着非常常見的場景,所以如果聽到任何這些熟悉的聲音,那麼您並不孤單。本文的目標是解决這些類型的情景,提供一些有關執行測試的基本過程和可用的适用工具的一些最佳實踐建議。總體來講,這裏討論的主要主題將幫助您:

  • 編寫有用的性能測試案例。
  • 駕馭不同的負載量以降低和提高利用率。
  • 激勵關鍵性能和系統指標。
  • 與應用程序開發周期並行地執行性能測試。
  • 使用 IBM Health Center 等工具查找性能瓶頸。
  • 與開發團隊合作修复瓶頸並重新度量。

性能測試的重要作用

曾幾何時,性能測試被視为在部署到生產之前才做的事情。它常常只有非常少的工作量,沒有分配足夠的時間來識別和修复最終將在生產環境中出現的真實問題。要執行合适的性能測試,一種普遍推薦的方法是實現 性能生命周期,其中性能測試計劃为開發工作的一部分,集成了迭代式測試作为新功能。這能夠在將所有功能部署到生產環境之前,就能夠很早地識別出瓶頸,並解决這些問題。

合适的性能測試的另一個好處是有機會調節環境(操作系統、JVM、應用服務器、應用程序和數據庫等)以實現最大性能。只有通過合适的性能測試,才能調節所評估的参數以確定它們是否提供了任何價值。許多用戶基於開發人員建議來設置 JVM 堆大小,不會調節其他任何参數,因为這被認为沒有必要。您可能會很驚奇,只需執行一些簡單的調節步驟,即可將为調節的環境所需的硬件量減少一半。本文將證明這一點

使用一些簡單的調節過程,DayTrader 性能基准測試應用程序可處理兩倍於未調節環境的負載。這意味着相同數量的用戶可能只需使用一半的可用硬件資源即可支持。想想這能夠節省的成本。

除了在整個開發周期執行迭代測試和用於調節用途的測試優勢,廣泛性能測試的另一個主要優勢是,能夠對比不同應用程序和環境改變的結果。真實的性能測試會記錄關鍵指標,使管理員能夠洞察可能出現的問題(稍後將討論)。回到上面的一種常見評論,許多用戶在遷移到更新的應用程序版本時,都未准備好找出問題的根源,因为他們從未對以前的版本執行合适的性能測試或記錄關鍵系統指標。缺少此工作,具有更糟的應用程序版本的測試服務器可能需要設置为一個對比點。有了此類型的數據,就可以容易得多地分析性能降級來自何處。


合适的性能測試的最佳實踐

有兩條基本的合适性能測試最佳實踐,它們可總結如下:

  • 改變用戶(或客戶端負載)數量。一個生產環境通常在一天之內具有不同數量的活動用戶。質量測試可確保應用程序在小負載和峰值(例如黑色星期五)負載下良好地執行。這可能意味着請求之間的 “思考” 時間的更改和使用應用程序的活動用戶數量的更改。這麼做的一種最佳方式是對 1 位活動用戶、2 位用戶、4 位用戶、8 位用戶等執行測試。您稍後將看到此方法的實際應用。
  • 記錄關鍵系統和性能指標。應該为所有場景記錄一些重要的指標。對於每次性能運行,要記錄的最重要指標是:
    • 吞吐量(每秒請求數)
    • 響應時間
    • 應用服務器機器 CPU 利用率 %
    • 其他機器 CPU 利用率 %,如 Web 服務器、負載驅動程序和數據庫(如适用)

只要使用了負載驅動工具,就可以看到吞吐量和響應時間指標。對於 CPU 利用率、內存利用率、磁盤 I/O 和網络流量指標,可以使用 Linux® 或 AIX® 上的 vmstat 或 nmon 工具進行查看,或者使用 Windows® 上的任務管理器進行查看。除了上述指標之外,記錄所有系統級信息也很重要。這包括操作系統級別、活動核心數量、可用內存 (RAM) 量、“Java™ 版本” 輸出、WebSphere Application Server 版本信息,以及所有已應用的調節。記錄所有這些指標使您能夠迅速對比不同場景,即使對比的場景的測試時間已相隔兩年。

許多用戶沒有可用於再現與測試環境大小相同的生產環境的硬件。在這些情況下,推薦的方法是基於可用的資源來擴展性能測試。例如,假設一個生產環境包含 10 個物理機器,每個機器運行兩個 WebSphere Application Server 實例。如果一個物理機器都可用於性能測試工作,那麼此機器可設置为與生產機器盡可能相同,並且性能測試中使用的負載將大約为預期生產工作負載的 10%。最終,應該擴展性能測試,以再現完整的生產環境。這样,其他流程(比如數據庫和 LDAP)的負載也會進行測試。


測試案例和負載驅動程序

執行性能測試和查找應用程序瓶頸的第一步是編寫有用的測試案例。結果和分析取决於用於生成它們的測試案例,所以這一步不應輕率地執行。與對所有用戶都將使用的代碼路徑執行壓力測試相比,對用戶僅花了不到 10% 的時間的應用程序代碼路徑執行壓力測試的效果差得多。首先專注於最流行的代碼路徑,然後为更少利用的代碼路徑構建您自己的測試。在這裏花一些時間真正創建一個模擬實際用戶流量的高質量測試案例。這篇 developerWorks 文章 是幫助開始編寫性能測試案例的一個不錯的資源。

定義了測試案例概念之後,您將需要通過一個性能負載驅動工具將它應用於實踐。有許多負載驅動程序可供選擇,包括 IBM Rational Performance Tester 和 Apache 的開源 Jmeter。本文將使用後者。


DayTrader 示例

如果您之前閱讀過 developerWorks 上的任何性能文章,那麼您很可能已聽說過 “Trade” 或 “DayTrader” 基准測試。Apache DayTrader Performance Benchmark Sample 應用程序模擬了一個簡單的股票交易應用程序,它讓用戶登錄/注銷、查看他們的投資組合,查找股票報價,購買和銷售股票,並管理帳戶信息。DayTrader 不僅可用作功能測試的出色應用,還提供了一組標准的工作負載集來描繪和度量應用服務器和組件級性能。

DayTrader 構建於一組核心的 Java EE 技術之上,包括用於表示層的 Java servlet 和 JavaServer™ Pages (JSP),以及用於後端業務邏輯和持久性層的 Java 數據庫連接 (JDBC)、Java Message Service (JMS)、Enterprise JavaBeans (EJBs) 和消息驅動的 bean (MDB)。圖 1 给出了該應用程序架構的總體概述。


圖 1. DayTrader 應用程序概述
圖 1. DayTrader 應用程序概述

IBM 發布了一個样例 DayTrader 包 供下載,它包含 DayTrader 應用程序和所需的部署描述符,可以將它們安裝在 WebSphere Application Server V7.0 或更高版本上。

在此示例中,將 DayTrader 样例應用程序部署成了 WebSphere Application Server V8.5 的一個基本實例。一個簡便的 DayTrader 功能是 Configuration 選項卡下的 TradeScenarioServlet 鏈接。它會鏈接到模擬一群 Web 用戶的一個 servlet,为每個訪問該 servlet 的用戶隨機生成具體的 DayTrader 操作。(例如,一個用戶可查看他的投資組合、一個用戶可執行股票購買操作,一個用戶可查找一個股票報價等)。這可確保 DayTrader 中的每個主要操作都會在測試期間執行,因为它是隨機的,所以一段時間後每個操作都應執行大體相同的次數。有許多参考資料介紹了如何使用 JMeter 編寫非常复雜的性能測試,其中可为每個操作指定使用的准確次數和使用順序,但出於本文的用途,測試案例將會保持相對簡單並使用此 TradeScenarioServlet。


使用 JMeter

設置 Jmeter 並運行它來執行性能測試:

  1. 安裝 Jmeter。指向您的 java 目錄,使用 jmeter.shjmeter.bat 腳本從 <JMeter_Home>/bin/ 目錄启動 JMeter。您應看到一個類似圖 2 的面板。

    圖 2. JMeter 默認試圖
    圖 2. JMeter 默認試圖

  2. 右鍵單擊 Test Plan 並轉到 Add > Thread Group。這是您定義要處理其負載的用戶數量的地方。對於初學者,使用以下值(参見圖 3):
    • 線程(用戶)數量:1
    • 循環數量:Forever


    圖 3. JMeter Thread Group 視圖
    圖 3. JMeter Thread Group 視圖

  3. 右鍵單擊您剛創建的線程組,轉到 Add > Sampler。一個抽样器 (sampler) 定義您希望處理的負載類型。有針對 HTTP 請求、JMS 請求、Web 服務消息等的抽样器。JMeter 用戶手冊記錄每個可用的抽样器。因为 DayTrader 支持基於 Web 的流量,所以此示例使用 HTTP Request。依據您的環境填寫主機名、端口和路徑的值(参見圖 4)。

    圖 4. HTTP 請求
    圖 4. HTTP 請求

  4. 右鍵單擊您剛創建的 HTTP 請求並選擇 Add > Timer。計時器添加請求之間的 “思考時間”。這模擬一個用戶單擊一個頁面,然後暫停閱讀頁面上的一些信息,最後發出另一個請求。您可選擇許多預定義的計時器,具有從常量固定計時器到高斯或泊松分布式計時器的不同复雜度。JMeter 用戶手冊 記錄每個可用的計時器。對於這個簡單示例,僅使用 5 ms 的 Constant Timer
  5. 右鍵單擊該線程組並轉到 Add > Listener > Summary Report。這將顯示測試運行時的響應時間和吞吐量結果。
  6. 將設置保存到一個文件,以便您可在以後再次加載它們。

運行測試

在启動負載驅動工具之前,始終要確保應用程序兼容一個瀏覽器。准備好後,單擊綠色箭頭或單擊 Run > Start。JMeter 現在應將一個客戶端連接到您指定的服務器路徑,在每個請求之間等待 5 ms。如果您單擊 Summary Report,可以看到測試運行的結果。

您應會注意到,吞吐量在不斷增長;這稱为 “升溫” 階段。JRE 需要一些升溫時間來加載所有類,讓 JIT 執行一些優化。吞吐量最終將穩定,達到一個固定的數量(每秒發出或接受一些請求)。依賴於測試的复雜性,這個升溫階段可能持續 30 秒,也可能持續 30 分钟。

在測試運行時,打開一個終端(Linux 或 AIX)並運行 vmstat 5 來每隔 5 秒顯示一次系統指標(参見清單 1)。


清單 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,右鍵單擊任務欄並選擇任務管理器,然後選擇性能選項卡。當 JMeter 中的吞吐量達到一個穩定值後,記錄運行 WebSphere Application Server 的服務器和任何其他适用服務器上的 CPU 利用率,然後單擊紅色停止標志或 Run > Stop 停止 Jmeter 測試。JMeter Summary Results 視圖類似於圖 5。


圖 5. JMeter Summary Report 視圖
圖 5. JMeter Summary Report 視圖

在一個電子表格中,記錄吞吐量結果(93.9 個請求/秒)和平均響應時間結果 (4 ms)。如果您希望更詳細的信息,那麼 Min、Max 和 Std. Dev. 響應時間也很有用。

記錄所有結果後,選擇 Run > Clear 來清除 Summary Report 結果。這會介紹對單個用戶的測試。現在將用戶數量依次增加到 2、4、8 等,並重复上述步驟。每次添加更多用戶時您都應觀察到吞吐量增長。最終,您會觀察到吞吐量停止增長,甚至可能開始下降。達到平穩狀態(以及可能下降)時,測試即可停止。


分析結果

完成上述步驟後,您應得到一個類似圖 6 的電子表格。(這些具體的結果高度依賴於 DayTrader 應用程序和運行此測試的環境。您的實際結果可能有很大不同。)


圖 6. Test Results – Table 視圖
圖 6. Test Results – Table 視圖

擁有這样的表列格式的原始數據很有用,但以圖形格式查看結果也很有用。可視化結果的一種最佳方式是使用 XY 散點圖。繪制一個圖表來描繪結果,會使趨勢的識別容易得多。圖 7 描繪了吞吐量和 WebSphere Application Server CPU % 與客戶端數量的關系。


圖 7. Test Results – Graph
圖 7. Test Results – Graph

上面的圖 7 顯示了一些有趣的特征。首先,可以看到吞吐量曲線和 CPU % 曲線非常接近。第二,可以看到應用程序吞吐量從 1 個客戶端近線性地擴展到 500 個客戶端。這是想要的結果。但是,在 500 個客戶端到 1,000 個客戶端之間的某個點,吞吐量的增速開始放緩。(這時可使用 500 到 1,000 之間的用戶負載來執行更多測試,以查找發生此增速放緩現象的准確位置。)將客戶端負載增加到 1,000 個客戶端以上不會改進總體應用程序吞吐量。這就是所謂的飽和點。這是一個重要的值,必須在性能測試中找到。飽和點告訴您,您已達到此應用程序、調節、配置和環境的最大容量。添加超過此點的更多用戶只會增加客戶端響應時間,不會增加總體應用程序吞吐量。要獲得超過此點的更高性能,必須執行應用程序代碼更改、調節更改或環境更改。

DayTrader 與您的應用程序對比

DayTrader 不能代表所有應用程序。您的應用程序可能更早達到飽和點。如果情況確實如此,這可能表示一個應用程序瓶頸,需要執行應用程序分析來修复它。

這種類型的測試和分析是大小調整和容量規劃討論中主要主題。只有通過識別飽和點,您才能准確估算支持一個生產環境所需的總容量。常常有人會說,“我需要在此環境中支持 10,000 個用戶”,然後對該客戶端負載運行測試。通常,此方法會在一個或多個組件中引起各種各样的超負荷情形,這些情形可能在 WebSphere Application Server 中,也可能在其他基礎設施組件(網络、數據庫等)中。一種更高效的方法是確定使用單個應用服務器可獲得何種客戶端負載和吞吐量,然後基於此信息繼續執行運行時和應用程序調節。調節完成後,可將注意力轉向確定滿足可伸縮性需求需要多少應用服務器流程和流程服務器。

將一個新測試保存在 JMeter 中,使用您找到的線程(用戶)數作为飽和點。這可用作一項快速測試,以對比您對應用程序或環境執行更改時的性能,而無需再次執行完整的可伸縮性測試。這不是說您不應再執行可伸縮性測試,但對於在 CPU 未充分利用的更低負載上不會顯示出任何不同的更改,運行飽和點上的負載是對比這些更改的一個不錯地方。一種不錯的做法是對次要應用程序或調節更改運行飽和點負載,對主要應用程序或環境更改重复完整的可伸縮性測試。


性能工具

以上各節是執行任何真實分析工作的准備條件。您必須首先理解如何生成可重复的性能結果,才能查找瓶頸和性能改進。現在您已准備好查找改進了,應使用以下兩個性能工具來開始分析:

  • IBM Tivoli® Performance Viewer

    Tivoli Performance Viewer(在管理控制台中)是一個監視 WebSphere Application Server 的非常有用的工具。這篇文章 重點介紹了使用 Tivoli Performance Viewer 最優地調節環境的好處。采用相同的方式,Tivoli Performance Viewer 可用於快速檢查是否有任何可通過調節輕松刪除的瓶頸。

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

    1. 使用比確定为飽和點的用戶數量重新启動 JMeter 負載。
    2. 登錄到管理控制台並選擇 Monitoring and Tuning > Performance Viewer > Current Activity。單擊您希望監視的服務器,然後展開 Performance Modules。這將顯示一組可供查看的性能模塊。
    3. 您的應用程序特征將確定其中哪些模塊最有必要查看。對於 DayTrader 示例或任何其他基於 Web 的流量,启動 Thread Pools > WebContainer 模塊。勾選該复選框,單擊頂部的 View Module 按鈕。這將顯示一個類似於圖 8 的圖表,在 JMeter 測試繼續運行時,每隔 30 秒自動填充更多數據。

      圖 8. WebContainer PMI 數據
      圖 8. WebContainer PMI 數據

      此示例顯示,WebContainer 線程池大小为 50 個線程,其中大約 32 個正在使用。這告訴您,WebContainer 線程池大小不是當前工作負載下的瓶頸。如果活動數量在 45-50 之間波動,那麼 WebContainer 線程池大小可能是一個瓶頸。在該情況下,可能最好增加 WebContainer 線程池大小,重复該測試以查看性能是否改進。如果吞吐量確實增加了,您可能希望再次運行灣鎮的可伸縮性測試,以重新建立基准。

    4. 對其他适用於您的應用程序的模塊繼續重复第 3 步。對於 DayTrader 這样的事務應用程序,應查看的另一個模塊是 JDBC Connection Pool 信息。展開 JDBC Connection Pools > 您的 JDBC 驅動程序),選擇您的數據源 JNDI 名稱。單擊 View Module 按鈕以顯示一個類似圖 9 的圖表。

      圖 9. DataSource PMI 數據
      圖 9. DataSource PMI 數據

      此圖表描繪了一些與默認選擇不同的選項。PoolSize、FreePoolSize 和 WaitingThreadCount 都是很有用的指標,可查看它們來確保您的連接池不是爭用來源,WebContainer 線程沒有排隊等待連接數據庫。在上面的示例中,連接池大小固定为 50 個連接(這是一項調節設置)。空閑池大小在 20 上下波動,這意味着一次有大約 30 個連接是活動的。從這些信息得到的是一個 Waiting Thread Count 0,表明沒有 WebContainer 線程在等待連接數據庫。這可確認 JDBC 連接池大小不是瓶頸。如果空閑池大小为 0,並且等待的線程數量大於 0,那麼您可能希望使用更高的連接池大小重复測試。

    對有助於監視您的應用程序的任何其他性能模塊繼續執行此過程。WebSphere 反向投資者:應對故障 提供一個全面的統計信息列表,這些信息可能具有很高的監視價值。完成此練習後,您可轉而使用 IBM Health Center 執行更詳細的分析。
  • 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 進程上執行詳細的性能分析的推薦工具。Health Center 提供了有關服務器性能的豐富知識,包括以下信息:

    • 內存使用
    • 垃圾收集統計信息
    • 方法級探查
    • 锁爭用分析。

    Health Center 是 IBM Support Assistant (ISA) 中的一個工具,可免費下載。請確保將 ISA 安裝在一個不同於應用服務器機器的機器上,否則 Health Center 將占用應用服務器進程中的資源,您的結果也可能不太准確。Health Center 可在一種交互式模式下運行,也可在一種 “無頭” 模式(其中的信息保存在一個文件中供以後查看)中運行。對於此示例,您將使用交互式模式。

    启動 Health Center:

    1. 重新启動您希望使用一般 JVM 参數 -Xhealthcenter 獲得其詳細信息的 WebSphere Application Server 進程。
    2. 启動 ISA。當加載時,選擇 Analyze Problem。(如果以前已完成此過程,您將需要告訴 ISA,您對 WebSphere Application Server 的工具感興趣。)
    3. 選擇 IBM Monitoring and Diagnostic Tools for Java – Health Center 並單擊 Launch(参見圖 10)

      圖 10. 從 ISA 启動 Health Center
      圖 10. 從 ISA 启動 Health Center

    4. 將顯示一個連接向導。單擊 Next。指定應用服務器運行時使用的主機名或 IP 地址。在默認情況下,將使用端口 1972。如果有任何安全需求,可在這裏指定它們,否則單擊 Next。如果找到了主機名和端口,再次單擊 Next,否則查明为什麼連接無效。如果成功,Health Center 將類似於圖 11。

      圖 11. Health Center 默認視圖
      圖 11. Health Center 默認視圖

    5. 最大化 Health Center 的屏幕並單擊它,以了解它的功能。現在,您已准備好開始一些詳細的性能分析了(接下來幾節將進行介紹)。繼續使用在您的飽和點上找到的用戶數量重新启動 JMeter 負載。Health Center 將在新信息可用時動態地更新。讓 JMeter 負載在您的升溫階段持續運行,然後再繼續操作。

垃圾收集分析

任何 Java 應用程序性能分析中的第一步始終應为分析垃圾收集統計信息。保持 Health Center 正常運行,這很很容易做到。

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


圖 12. Health Center – Garbage Collection 視圖
圖 12. Health Center – Garbage Collection 視圖

對於入門級分析,首先應檢查兩件事:

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

其他一些能夠幫助您查找您最感興趣數據的技巧包括:

  • 圖 12 中的圖表中的 X 軸顯示自服務器启動以運行的時間。您可更改此值以繪制一天的圖表。這可能對關聯在一天某些時刻發生的活動有所幫助。X 軸可通過選擇上下文菜單 > Change Units > X-Axis > Time 來更改。
  • 您可剪切數據來消除預熱期,以獲得在正常活動條件下所發生事情的更准確視圖。为此,選擇 Data > Crop Data(以剪掉開始和完成時間)或者選擇 Data > Reset Data 來清除截至此時刻的任何數據。
  • 對於更詳細的分析,單擊 Samples by object 選項卡。這使您能夠看到分配對象的故障、为每種類型分配的對象數量,以及的對象總大小的統計分析。甚至可以選擇按包或對象名來搜索。圖 13 顯示了一個示例。基於這些結果,檢查應用程序代碼以查看是否可減少的 BigDecimal 和 BigInteger 的使用,這可能是一個不錯的想法。

圖 13. Health Center – Samples By Object 視圖
圖 13. Health Center – Samples By Object 視圖

方法探查分析

保持負載驅動程序運行,單擊 Profiling 鏈接。這將打開 Method Profiling 視圖,類似於圖 14。


圖 14. Health Center – Method Profiling 視圖
圖 14. Health Center – Method Profiling 視圖

Method Profile 表顯示了哪些方法正在使用大部分處理資源。這是整個 JVM 的視圖,而不是您的具體應用程序的視圖,所以這將包含數據庫驅動程序、WebSphere Application Server 容器等的方法信息。查看此視圖來從更大範圍內了解服務器中所發生的事情,這很有幫助。與前面的垃圾收集分析一節中一样,一個最佳的起點的是 Analysis and Recommendations 部分。此面板將突出已發現使用了比其他方法多得多的 CPU 周期的任何方法。在上面的示例中,技巧表明沒有明顯的優化方法,因为所有周期都是均勻拆分的。如果這裏顯示了一個或兩個方法,那麼應檢查該方法的代碼,以查看是否可執行任何優化,或者調用次數是否可以減少。

为了更深入研究,您需要理解如何解釋表中的數據。要獲取幫助,請参閱 Health Center 文檔,方法是選擇 Help > Help Contents,然後向下滾動並展開 Tool: IBM Monitoring and Diagnostic Tools for Java - Health Center 圖書。該文檔表明:

具有更高的 Self (%) 值的方法描述为 “熱的”,是優化的不錯候選者。對這些方法的效率的細微改進可能對性能具有巨大影響。您可通過減少方法做的工作量或減少調用它們的次數來優化它們。接近表末尾的方法不太适合優化。甚至對它們效率的巨大改進也不可能會影響性能,因为它們使用的處理資源很少。

以下是對表中每列的描述:


表 1. 方法配置文件表
描述
Self (%)在特定方法在堆棧頂部運行時采用的抽样百分比。此值是一個方法對處理資源的使用量的一個不錯指標。
SelfA graphical representation of the Self (%) 列的一個圖形表示。更寬、更紅的條塊表示更熱的方法。
Tree (%)特定方法在調用堆棧中任何地方時采用的抽样百分比。此值表示處理此方法和它調用方法(子孫)的時間百分比。此值很好地指出了您應用程序中花費了最多處理時間的區域。
TreeTree (%) 列的一個圖形表示。更寬、更紅的條塊表示更熱的方法堆棧。
Samples在堆棧頂部運行特定方法時采用的抽样數量。
Method該方法的完全限定的表示,包括了包名稱、類名稱、方法名稱、参數和返回類型。

單擊列標題,按升序或降序對所有這些列排序。理解這一點後,您可深入分析工作負載的性能特征。導航此表的一些有用技巧包括:

  • 單擊表中的一行將顯示底部面板中顯示執行該方法的完整調用路徑。
  • 在探查有效期間執行該方法時,將顯示 Timeline 選項卡。這可能很有用,您無需關注配置文件中在之前(或許在升溫期間)執行的某項功能,然後離開。
  • Filter methods 文本框對搜索特定類和過滤配置文件的剩餘部分很有用。這僅應用於下鑽您應用程序的詳細信息,以刪除所有其他非應用程序類。作为一個示例,圖 15 顯示了按 “daytrader” 過滤的配置文件,因为所有 DayTrader 應用程序類的包名稱中都包含 “daytrader”。這使您能夠集中精力查找應用程序中使用資源最多的方法。

圖 15. DayTrader 過滤的 Method Profile 視圖
圖 15. DayTrader 過滤的 Method Profile 視圖

如果應用程序有一個特定的方法使用了大量 CPU 周期,然後 Health Center 將它標記为 Analysis and Recommendations 面板中一個不錯的優化候選者。一個示例如圖 16 所示。


圖 16. 優化候選者示例
圖 16. 優化候選者示例

可花幾天時間分析 Method Profiling 視圖,以查找一個應用程序的性能改進。因为輸出可保存到一個文件中,所以對比應用程序更改非常簡單。應用程序開發人員可執行一項通過 Health Center 掛鉤來部署和執行負載測試的更改,並且您可對比以前的配置文件信息,查看開發人員更改的方法增加還是降低了處理需求。


锁定分析

多線程應用程序需要同步(或锁定)共享資源,以使資源的狀態保持一致。這種一致性可確保在一個線程讀取另一個線程時,該線程的狀態不會更改。

當在具有大量處理器的系統上部署的高負載應用程序中使用锁時,锁定操作可預防應用程序使用所有可用的處理資源。想象一下一個在 8 核機器上運行的應用程序,它的主要應用程序代碼路徑高度同步,所以一次只能執行一個線程。這可能使其他 7 個線程處於等待狀態。

當在大型的多核(4 個以上)機器上運行時,锁分析對確保應用程序可擴展並利用所有可用的硬件資源至關重要。(如果應用程序在單核機器上運行,這裏的分析可能沒有太大價值。)Locking 透視圖分析锁的使用,幫助識別應用程序或 Java 運行中阻止應用程序擴展的爭用點。單擊 Locking 鏈接後,應會顯示一個類似於圖 17 的面板。


圖 17. Health Center – Locking 視圖
圖 17. Health Center – Locking 視圖

初看起來,Moniors 視圖可能很難使用和理解。但是,Health Center 文檔詳細描述了這個面板,以幫助您理解這些指標。表 2 描述了該表中的列的內容。


表 2. 監視器
描述
% miss總 Get 或獲取次數的一個百分比,對於這部分 Get 或獲取,嘗試在同步的代碼上獲取該锁的線程在獲取锁之前必須阻塞。
Gets:在充實期間,獲取該锁的總次數。
Slow:由於一個锁已被另一個線程擁有,請求線程必須为其等待锁的非遞歸锁獲取的總次數。
Recursive:遞歸獲取的總次數。當請求線程已擁有監視器時,就會發生遞歸獲取。
% util:持有該锁的時間量除以接管輸出的時間量。
Average hold time:一個線程持有或擁有該锁的平均時間量。例如,同步的锁中花費的時間量(以處理器時钟單位計算)。
Name:監視器名稱。如果不知道名稱,則此列为空。

該表列出了被充實的每個 Java 監視器。% miss 列是最初的關注點。高 % miss 表明受锁保護的同步化資源上發生了頻繁的爭用。這種爭用可能阻止 Java 應用程序進一步擴展。

如果一個锁具有一個較高的 % miss 值,請查看 Average hold time 和 % util。一些技巧如下:

  • 如果 % util 和 Average hold time 都很高,您可能需要減少在持有锁期間執行的工作量。
  • 如果 % util 很高,但 Average hold time 很低,您可能需要使受锁保護的資源更加細粒度地將該锁分離为多個锁。

結束語

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

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


頂一下
(0)
0%
踩一下
(0)
0%
------分隔線----------------------------
發表評論
請自覺遵守互聯網相關的政策法規,嚴禁發布色情、暴力、反動的言論。
評價:
表情:
驗證碼:點擊我更換圖片
欄目列表
推薦內容