Quest JProbe最佳實踐的示例分析

本篇文章為大家展示了Quest JProbe最佳實踐的示例分析，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

1. 介紹

在Java的廣泛應用中，一個關鍵驅動因素是由于使用標準類庫和應用框架從而提高了生產效率。通過減少必要的設計，實現和調試等軟件開發任務，Java在各種平臺之間極大地改善了集成性和互操作性；其它的開發環境都不能提供像Java那樣的強大功能。實際上，沒有一個環境像J2EE那樣具有明顯的基于框架開發的優點，J2EE能夠快速地構建可擴展，分布式的安全企業級應用。

雖然這些優點一直在促進J2EE的空前發展，但也經常出現一些麻煩，那就是人們經常對J2EE應用的性能感到失望。因此，我們需要一些工具和調查策略來幫助J2EE開發團隊解決這些性能問題。這就是Quest JProbe Profiler和Jprobe Memory Debugger所要解決的問題。

1.1 J2EE性能概攬

一般情況下，最終用戶對J2EE應用性能的體驗與下面層次是緊密相關的:

J2EE體系結構圖

• J2EE應用是指servlets，JSPs，EJBs和支持類，它們在J2EE應用服務器的上下文環境中構成了客戶的應用。

• J2EE應用服務器是指J2EE應用服務器基礎結構的設計，實現和配置，它們提供了客戶J2EE應用的上下文環境。

• JAVA運行環境是指JAVA虛擬機及其配置(堆的大小等等)的設計和實現。

• 平臺-底層硬件(如CPU的數目，內存的大小，I/O子系統等)和操作系統設計，實現和配置(線程和進程調度，子系統優化，整體負載等) 。

雖然毫無疑問，底部層次會影響整個性能，經驗也不斷地表明，性能下降的普遍原因是由組成J2EE應用的Servlets，JSPs和EJBs的設計問題和不佳的實現造成的。本文將集中討論在這個底層中如何識別出性能下降的原因。

1.2 概述

本文描述了在BEA WebLogic Server6.1上下文環境中，怎樣用Quest JProbe Memory Debugger和Profiler分析J2EE應用。包括三個主要部分:

• 設置-在介紹JProbe的體系結構之后，我們將描述怎樣把JProbe Memory Debugger和Profiler集成到WebLogic Server6.1環境中。

• 對象循環分析-在J2EE應用中，性能下降的普遍原因是創建過多的短期對象(也可稱為對象循環)。在這部分里，我們將展示怎樣使用JProbe Memory Debugger's Garbage Monitor識別大量創建短期對象的方法。這些是進一步分析減少創建過多對象的最佳方法。

• J2EE性能分析-最后，我們將使用JProbe Profiler向你介紹怎樣進行J2EE應用的性能分析，并且在語句級上快速地識別出一些耗時最多的方法。

2. 集成BEA weblogic 服務器和Quest JProbe

2.1 Quest JProbe

Quest JProbe產品線由一族工具組成，該族工具包括下面四個分析工具。

• JProbe Memory Debugger-檢查Java軟件的內存使用情況。

• JProbe Profiler-剖析Java軟件的性能。

• JProbe Threadalyzer-識別線程級的死鎖和錯誤的訪問沖突

• JProbe Coverage-通過提供的語句級執行信息驗證測試框架的完整性。 

雖然本文集中討論了JProbe Memory Debugger和Profiler，但所有四個工具都采用了相同的體系結構設計，并且與BEA WebLogic服務器的集成方法是相同的。

2.1.1 JProbe的體系結構

一個基于JProbe的調查會話由兩個程序組成:

圖2 JProbe體系結構

JProbe控制臺是一個基于Swing的Java應用，它提供了用戶圖形界面（GUI），用于建立調查會話，在程序運行時查看分析信息和深入分析Snapshot文件中的信息內容。

測試型Java虛擬機-JProbe通過JVMPI(Java Virtual Machine Profiling Interface)提供的回調方法，使用標準的Java虛擬機運行Java應用并收集分析信息，該虛擬機是由廠商提供的。在剖析基于WLS的J2EE應用中，Java應用運行在Java虛擬機中，該虛擬機由WebLogic服務器的基本框架組成，就象J2EE應用部署到上面一樣。

這種結構具有非常靈活的啟動方式。你可以從用戶圖形界面本身啟動測試型Java虛擬機，也可以單獨啟動測試型Java虛擬機并且使它連接上JProbe控制臺。

2.2 使用JProbe Application Server Integration Tool

1. 啟動JProbe Application Server Integration。

2. 從左上角下拉列表中選擇你要集成的BEA Weblogic服務器版本。

圖3 JProbe Application Server Integration窗口

3. 點擊"Create"按鈕。編輯窗口右邊的內容，如圖3所示。

4. 編輯下面區域或使用默認值。

5. 點擊"Advanced>>"按鈕。

6. 填寫下面這區域。

Java Options: -classic -mx128m -ms64m 有選擇地給Java虛擬機輸入參數。

7. 點擊"Save"按鈕。

圖4． JProbe Application Server Intergation窗口

你已經成功創建和BEA Weblogic6.1的集成， 所有四個工具都可以使用這個集成過程。

8. 點擊"Close"按鈕。

3. 識別J2EE應用性能下降

JProbe Memory Debugger能幫助你追蹤到游離對象（loitering objects）和減少創建過多的對象，并且JProbe Profiler能幫助你發現性能瓶頸。根據具體情況，需要具體分析。在這里，我們簡單地概括用于解決對象循環和性能瓶頸這兩個常見問題的步驟。更多的信息和其它使用JProbe Memory Debugger和Jprobe Profiler的方法，可以參考在線幫助或者閱讀JProbe Memory Debugger Guide和JProbe Profiler Developer's Guide。

3.1 對象循環（Object Cycling）

Java應用性能下降的一個主要原因是創建過多的對象 (或稱為對象循環)。Java虛擬機分配了過多的內存，創建了不必要的對象并對這些對象的初始化，加大了垃圾回收活動，從而引起性能下降。

作為一個性能分析人員，你首先需要識別出創建大量短期對象的方法。這些方法是進一步做減少創建對象數量分析的理想入手點。JProbe Memory Debugger提供的一個垃圾監視功能可以把對象和分配它們的方法連接起來，并且當你的應用運行時，可以追蹤有多少對象已經被垃圾回收了。

3.1.1 啟動JProbe Memory Debugger的研究會話

1. 啟動JProbe Memory Debugger。當歡迎界面出現的時候，點擊"Run"開始啟動。

圖5．JProbe歡迎界面

2. 在JProbe LaunchPad窗口中:

a． 選擇"Using Application Server"
b． 從"Application Server"下拉的菜單中選擇BEA Weblogic6.1
c． 注意在"Integration ID"下拉的菜單中填寫JProbe Demo 1

3. 選擇"Filter"

a． 點擊"Please enter a package，or method to display data for"。輸入你要調查的包:profiler.com.quoteme.stockwatch
b． 在"Display"欄的下拉菜單里選擇"Display"

4. 選中"Monitor Garbage Collections from Program Start"復選框。

5. 選擇"Snapshot Directory:"為d:\temp。
6. 點擊"Run"按鈕。

圖6．JProbe LaunchPad Pad窗口

當WebLogic Server初始化時，Runtime Heap Graph將增高，這反映了對象創建和垃圾回收活動。一旦WebLogic Server已經被充分初始化后，你就可以開始著手分析了。

3.1.2 運行時交互

一旦WebLogic Server已經充分初始化，選擇你想要用于分析對象循環的應用用例。選擇Grabage Monitor標簽，按下面的步驟:

1. 首先運行一次Garbage Collection ，回收在Java堆中分配的，但不再使用的對象。Garbage Monitor表隨時更新反映這些被回收對象的情況。
2. 點擊"Clear Table"清空Garbage Monitor表。
3. 運行你的應用用例。當Java虛擬機開始垃圾回收時，Grabage Monitor表將隨之更新。

提示:在Heap Usage Chart中尋找負載峰值。急劇升降的負載峰值意味著一些對象在被垃圾回收之前只存活了很短的時間。連在一起的一些急劇升降的負載峰值是一個明確的信號，意味著是一個對象循環問題。

4. 在完成你應用用例后，再次運行Garbage Collection ，回收最后分配但不再使用的對象。

3.1.3 分析結果

當會話結束時，Garbage Monitor中包含了已回收最多實例的前十個類。通常，這些類不是你自己應用的類，準確地說，它們是被你的一些方法(直接地或間接地)分配的第三方的類。最后一列是分配這些已回收對象的方法名。

提示:如果被不同方法分配的實例屬于同一個類，并且都是前十個類的話，你將見到兩行相同的類。

1. 使用Filter Allocating Methods，只顯示你包中的一些方法，屏蔽掉其它包中的方法。在我們的例子中，客戶J2EE應用定義在 profiler.com.quoteme.stockwatch包里面，所以我們把過濾規范profiler.com.quoteme.stockwatch.*.*輸入到Filter Allocating Methods文本輸入控制中。

2. 在GC'ed列中，你能看到你的方法分配了多少實例。作為比較，查看Alive列就能看到還有多少實例仍在堆中。Java開發者通常會對創建和移走了多少對象而感到驚奇。

3. 現在你已經識別到你有問題的方法。想想你可能怎樣修改這些分配對象的方法，從而減少或排除對象循環？例如，你可以嘗試重用某個對象或者創建一個可重用的對象池。

4. WebLogic Server6.1編譯JSP后，自動產生了一個servlet類名，并賦予一個包名和類名。例如，如果有一個名為TestJSP.jsp的JSP文件，將被編譯成名為jsp_servlet.__testjsp的類(JSP名跟著兩個下劃線，并且都是小寫字母)。

用Filtering Classes為jsp_servlet.*限制Garbage Monitor中的內容，可以看到已經被垃圾回收到Garbage Monitor中的JSP。在Filtering Allocating Methods設置jsp_servlet.*.*或jsp_servlet._<你的JSP名>.* 限制Garbage Monitor中的內容，可以從分配的角度在指定的JSP中查看垃圾回收對象。

更深入的研究

如果你分配的方法沒有一個出現在Garbage Monitor中，或者在修改明顯的問題后，仍然有對象循環的問題；你需要進行堆棧跟蹤，檢查哪個方法的調用導致了創建實例并分配了空間。需要使用 heap snapshot查看堆棧跟蹤。要了解更多的信息，請看在線幫助里的Garbage Collection Tutorial或者JProbe Memory Debugger Developer's Guide。

3.2 性能分析

解決對象循環問題有助于性能的改進，但你可能仍然面臨著性能瓶頸。進行一次性能分析可幫助你在J2EE應用中識別低效率的算法。JProbe Profiler提供了應用的方法級和源代碼行級度量值。

3.2.1 啟動JProbe Profiler調查會話。

1. 啟動JProbe Profiler。當歡迎界面出現時，點擊"Run"開始。

圖8 JProbe歡迎窗口

2. 在JProbe LaunchPad窗口中:

a. 選擇"Using Application Server"
b. 從Application Server下拉菜單中選擇BEA Weblogic6.1
c. 注意在Integration ID下拉菜單中填JProbe Demo 1

3. 選擇Filter

a. 點擊Please enter a package，class，or method to display data for。輸入你要調查的包profiler.com.quoteme.stockwatch
b. 從Detail Level列的下拉菜單中選擇Line Lever

這個元素定義了我們想要把所有運行在環境中的Java軟件看作基礎結構。因為我們不想詳細了解它們的性能信息 (我們只是想知道在代碼上的影響，我們不想更細地分析)

提示:在WLS6.1中的JSP Profiling當JSP被WebLogic Server6.1編譯時，產生的servlet被給予一個產生的包和類名。例如，如果有一個名為TestJSP.jsp的JSP文件，它被編譯后，生成名為jsp_servlet._testjsp的類(兩個底線被JSP名跟著，都是小寫字母)。 如果你想跟蹤你的JSP里的方法在執行中花了多少時間，你必須指定正確的過濾策略，用于捕獲數據。

4. 選擇"CPU Time"

5. 選擇"Record Performance at Program Start"復選框

6. 選擇"a Snapshot Directory:"為d:\temp

7. 點擊"Run"按鈕

圖9 JProbe Profiler LaunchPad窗口

3.2.2 運行時交互

在性能分析中，Heap Usage Chart就象一個執行進度的監視器，與上節介紹的Garbage Monitor不同，這里不提供類似的運行時性能信息。使WebLogic Server自己初始化到完全啟動。

作為對象循環分析，我們推薦使用應用級的，以用例為中心的方法進行性能分析，具體如下:

1. 清空累積的性能數據 。

2. 運行你的應用用例。

3. 執行一次性能快照 ，保存性能信息。

性能快照包括時間和在用例運行期間對象創建等度量數據(這個運行期間從重新設置性能信息開始-第一步，一直到執行快照結束，第三步)。

3.2.3 解釋結果

JProbe Profiler提供兩個工具，以不同的格式顯示收集到的數據；可根據具體情況選擇:

• Method List是指以表的形式顯示與方法有關的數據信息。使用Method List可以按照名稱或度量值排序，或顯示只顯示其中部分方法。
   

• Call Graph--是指以有向圖的形式顯示方法。可以使用Call Graph查看并跟蹤程序中方法間的調用關系。從Method List或Call Graph中，你能使用下面這些工具深入到更多的細節數據。
   

• Method Detail View是指對于所選的方法，顯示它們是被哪些方法(也稱父方法)調用了或它們調用了哪些方法(也稱子方法)。
   

• Source Window顯示所選方法的語句級性能信息。

3.2.3.1 Time and Object Creation Metrics

JProbe Profiler在方法方面收集了三個基本度量值:

• Number of Calls是指在會話期間該方法被調用的次數
   

• Method Time是指執行該方法所花費的總時間
   

• Method Objects是指該方法創建的對象總數

在這些基本的度量值基礎上，JProbe Profiler計算出兩種度量值表示方法調用樹:

• Cumulative Time是指執行這些方法的時間，和執行它們直接或間接調用的方法所花費時間的總和。
   

• Cumulative Objects是指這些方法創建的對象，和這些方法直接或間接調用其它方法創建的對象的總合

基于Number of Calls用四種平均度量值:

• Avg.Method Time是指調用方法的時間除以調用次數
   

• Avg.Method Objects是指方法對象除以調用次數（方法對象指方法執行期間創建的對象數，不包括派生對象創建的數）
   

• Avg.Cumulative Time是指累積時間除以調用次數
   

• Avg.Cumulative Objects是指累積對象除以調用次數

在默認情況下，Call Graph顯示的數據是在性能快照中的數據。我們建議你關閉Call Graph一會再打開Method List窗口。

3.2.3.2 Method List

Method List窗口(見圖10)以表的形式顯示性能數據。

圖10 JProbe Profiler Method List窗口

每一行顯示了方法的時間和方法創建對象的度量值。使用Method List能很快識別你最耗時的方法。通常你會發現你的性能瓶頸和這些方法有關。

如果你是第一次調查，跟著下面這些步驟將使你能更有效地使用Method List。

1. 選中你的snapshot，打開"Method List"。

2. "Filter"區域只用于顯示在你包中或在你感興趣的類中的方法。

3. 點擊"Method Time"列名，把你最消耗時間的方法排在最前面。仔細查看前十個。是不是有一些度量值令你驚訝?你能改進你方法中的算法嗎?

4. 點擊"Cumulative Time"列名，把最消耗時間的調用樹排在最前面。比較一下"Method Time"和"Cumulative Time"。雖然方法本身可能效率很高，但也可能調用了低效率的方法，這些低效率的方法可能在你的代碼中，或者在第三方的包或應用框架中。

5. 點擊”Number of Calls”列名，查看一下你哪個方法被調用最多。如果一個或多個度量值同時反映這些方法是低效率的，需要考慮減少調用這些方法，或調用那些效率稍好的方法。

3.2.3.3. Call Graph

Call Graph(見圖11)提供一個非常有力的方法調用關系視圖。它把J2EE應用放到WebLogic Server上下文環境中，所以你能看到WebLogic啟動的所有線程，包括調用J2EE應用的線程。為了方便查找，Call Graph下面有"Method List"。

當分析性能時，在定位J2EE應用的入口點和排除與WebLogic線程有關的數據方面， Call Method是最有效的。在分離出應用的數據基礎上，可快速畫出執行流程，并用圖形清晰地顯示出來。

下面是使用Call Method的有效技巧:

1. 選中你的snapshot，打開"Call Graph" 。

2. 點擊"Find"并且定位你的J2EE應用的入口位置。 通常是servlet中的doGet()或doPost()方法。

3. 選擇方法并分離出數據形成圖形 。

4. 顯示方法的一個子集作為開始，這些方法按照"Cumulative Time"排序是最耗時的方法。當你分析一個方法，在方法的調用樹上將增加額外的節點。

5. 在"Method List"中，根據你發現的瓶頸位置，在"Color By"的下拉列表中選擇相同度量值。根據你選擇的度量值，現在最耗時的方法都以鮮艷的顏色突出顯示出來。

6. 選擇最耗時的方法。展開父方法樹(通過點擊節點部分或節點左邊部分的空箭頭記號)，就能看到哪個方法調用它了。你可以調用不同的，耗時比較少的方法嗎?你需要經常調用這些方法嗎?

7. 展開子方法樹(指向節點的右邊)，可以看到調用了哪個耗時的方法。還有哪些子方法也是耗時的呢?你意識到第三方的方法實際的耗時情況嗎?你能調用一個實現了更有效率算法的不同方法嗎?

 
圖11 JProbe Profiler Call Graph窗口

3.2.3.4 Method Detail View

從Method List或Call Graph中，你都能深入地分析，在一個視圖中很方便地看到耗時的方法的度量值，還有它們子方法和父方法的度量值。選擇方法并打開"Method Detail View" 。

"Method Detail View"(見圖12)在窗口的中心顯示了選擇方法，它的父方法在上面，它的子方法在下面。我們對列的頭部已經熟悉了，它們和你在其它工具中看到的度量值相同。一個重要的區別是：用于顯示父方法和子方法度量值表示對所選方法的貢獻值，不是對它們自己的度量值。所以，如果一個方法被調用了12次，這些調用它的方法，和12次調用分別顯示在父方法的圖中。如果你想繼續分析父方法或子方法，雙擊該方法，使該方法在"Method Detail View"的中心顯示。

圖12 JProbe Profiler Method Detail窗口

3.2.3.5 Source Window

要查看你方法中的代碼，選擇方法并且打開Source Window。你需要指出你的源代碼具體位置。

如果你是按行收集數據，你能在Source Window(見圖12)中看到這些數據。在左列中，顯示了每條語句的數據度量值。行級度量值是方法級度量值的細化，包括調用次數，執行該行的時間，執行該行時創建的對象數量，累積時間和累計對象數量。

提示:如果需要編輯你的代碼，并且已經把集成開發環境IDE和 JProbe Profiler集成在一起了，你可以通過選擇Edit>Edit Source打開你的集成開發環境。當然，需要運行你重寫的代碼，并建立新的JProbe Profiler分析會話時，你做的改變才反映在JProbe Profiler上。

圖13 Jprobe Profiler Source Window

上述內容就是Quest JProbe最佳實踐的示例分析，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。