本節提供 Identity Manager 效能評測器的特性與功能簡介。相關資訊編排如下:
您可以使用效能評測器公用程式執行以下作業:
建立效能評測資料的「快照」。
快照是自從上次重設所有收集的效能評測結果以來,所累計的效能評測結果。
使用四種不同的資料檢視顯示快照結果:
[呼叫樹狀結構檢視] 提供樹狀結構表格,顯示整個系統的呼叫計時及呼叫計數。
[Hotspots 檢視] 提供直列式節點清單,顯示所有父系節點的集合呼叫計時。
[Back Traces 檢視] 提供顛倒的呼叫堆疊,顯示呼叫此節點 (稱為根節點) 的所有來源呼叫鏈。
[被呼叫端檢視] 提供根節點的彙總呼叫樹狀結構,而不考慮其父鏈為何。
指定快照中要包含的資訊種類:
您可以包含表單、工作流程與 XPRESS 的每個元素,或將內容限制在特定的一組元素。
您可以挑選特定的 Java 方法及建構子,以納入方法或從方法排除。支援 Identity Manager 類別與自訂類別的方法。
使用下列方式管理專案快照。
在專案的 nbproject/private/idm-profiler 目錄或專案外部的任意位置儲存快照。
您可以在 IDM 效能評測器檢視的 [已儲存的快照] 區段中,檢視所有儲存的快照清單。
從專案開啟快照,或從專案外部的任意位置載入快照。
刪除快照。
依名稱搜尋特定節點。
本節說明效能評測器如何查找及管理下列 Identity Manager 物件的來源:
在 [呼叫樹狀結構檢視] 或 [Hotspots 檢視] 中,您可以連按兩下對應 Java 方法、工作流程、表單、規則或 XPRESS 的任何節點,以檢視此節點的來源。
當您使用效能評測器拍攝快照時,伺服器會計算所有效能評測資料並搜尋資料依賴的來源。伺服器接著會從儲存庫擷取所有這些來源,並將其納入快照中。因此,您可以確定快照中所顯示的 Identity Manager 物件,能確實反映擷取快照當時的狀況。
此程序會增加快照的大小,但來源大小實際上只佔總大小的一小部分。因此,您可以將快照傳送給 Sun 的客戶支援部門,而不用另外傳送原始碼檔案。
當您拍攝 Java 來源的快照時,用戶端會下載快照,然後搜尋快照以從專案擷取所有參照的 Java 來源。當您儲存快照時,用戶端會壓縮來源並將其附加在快照結尾。
然後,當您檢視快照並移至 Java 來源時,用戶端會先檢查快照內容。如果用戶端在此找不到內容,則會檢查專案的內容。此程序可讓您從自訂 Java 程式碼與 Identity Manager 程式碼傳送包含效能評測資料的快照。
在 Java 來源快照中,請勿以為來源會隨伺服器更新或一直可以使用。
以下各節包含計算效能評測器提供結果時所要考量的資訊:
若要計算根節點的 Self Time 統計,效能評測器會從根節點的總計時間扣除所有子節點的時間。
因此,未執行的子節點時間會反映在根節點的 Self Time 中。如果根節點有很長的 Self Time,則必須找出原因。您可能尚未執行適當的方法,因此檢查的地方有誤。
例如,假設方法 A 呼叫方法 B。
方法 A 總計需要 10 秒 (其中總計時間包含呼叫 B),而呼叫 B 總計需要 10 秒。
如果 A 與 B 皆已執行,則呼叫堆疊會反映此資訊。您會看到 A 的 Self Time 為 0 秒,而 B 的 Self Time 為 10 秒 (其中 10 秒是實際用在 B 中的時間)。但是,如果未執行 B,您僅會看到呼叫 A 需要 10 秒,因此 A 的 Self Time 為 10 秒。因此,您可能會以為問題是在 A,而不是在 B。
您尤其會在 JSP 初始編譯期間注意到 JSP 有很長的 Self Time。如果重設收集的結果,然後重新顯示頁面,則 Self Time 值會少得多。
由於 Java 方法策略的限制,對 this() 或 super() 的初始呼叫會顯示為建構子呼叫的同層呼叫,而非子項呼叫。請參閱下列範例:
class A { public A() { this(0); } public A(int i) { } } and: class B { public static void test() { new A(); } } The call tree will look like this: B.test() -A.<init>(int) -A.<init>() Rather than this: B.test() -A.<init>() -A.<init>(int) |
多數 Identity Manager 的常駐程式執行緒 (例如 ReconTask.WorkerThread.run() 或 TaskThread.WorkerThread.run()) 所耗用的時間看似很久,但請勿被此誤導。大部分的時間是耗用在等候事件時的暫停上。您必須研究這些追蹤才能知道處理事件實際耗用的時間。