此圖表描繪了一些與默認選擇不同的選項。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 提供了有關伺服器性能的豐富知識，包括以下信息：
1. 內存使用
2. 垃圾收集統計信息
3. 方法級探查
4. 鎖爭用分析。
• 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
4. 將顯示一個連接嚮導。單擊
Next。指定應用伺服器運行時使用的主機名或 IP 地址。在默認情況下，將使用埠 1972。如果有任何安全需求，可在這裡指定它們，否則單擊
Next。如果找到了主機名和埠，再次單擊
Next，否則查明為什麼連接無效。如果成功，Health Center 將類似於圖 11。
圖 11. Health Center 默認視圖
5. 最大化 Health Center 的屏幕並單擊它，以了解它的功能。現在，您已準備好開始一些詳細的性能分析了（接下來幾節將進行介紹）。繼續使用在您的飽和點上找到的用戶數量重新啟動 JMeter 負載。Health Center 將在新信息可用時動態地更新。讓 JMeter 負載在您的升溫階段持續運行，然後再繼續操作。
垃圾收集分析
任何 Java 應用程序性能分析中的第一步始終應為分析垃圾收集統計信息。保持 Health Center 正常運行，這很很容易做到。
單擊 Health Center 窗口中的
Garbage Collection
鏈接。將顯示一個類似圖 12 的視圖。
圖 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 視圖
方法探查分析
保持負載驅動程序運行，單擊
Profiling
鏈接。這將打開 Method Profiling 視圖，類似於圖 14。
圖 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 (%) | 在特定方法在堆棧頂部運行時採用的抽樣百分比。此值是一個方法對處理資源的使用量的一個不錯指標。 |
以下文章點擊率最高
Loading…