Sun Identity Manager 8.1 版本說明

概況

本節提供 Identity Manager 效能評測器的特性與功能簡介。相關資訊編排如下:

主要功能

您可以使用效能評測器公用程式執行以下作業:

效能評測器查找及管理來源的方式

本節說明效能評測器如何查找及管理下列 Identity Manager 物件的來源:


提示 –

在 [呼叫樹狀結構檢視] 或 [Hotspots 檢視] 中,您可以連按兩下對應 Java 方法、工作流程、表單、規則或 XPRESS 的任何節點,以檢視此節點的來源。


表單、規則、工作流程與 XPRESS 物件

當您使用效能評測器拍攝快照時,伺服器會計算所有效能評測資料並搜尋資料依賴的來源。伺服器接著會從儲存庫擷取所有這些來源,並將其納入快照中。因此,您可以確定快照中所顯示的 Identity Manager 物件,能確實反映擷取快照當時的狀況。

此程序會增加快照的大小,但來源大小實際上只佔總大小的一小部分。因此,您可以將快照傳送給 Sun 的客戶支援部門,而不用另外傳送原始碼檔案。

Java 來源

當您拍攝 Java 來源的快照時,用戶端會下載快照,然後搜尋快照以從專案擷取所有參照的 Java 來源。當您儲存快照時,用戶端會壓縮來源並將其附加在快照結尾。

然後,當您檢視快照並移至 Java 來源時,用戶端會先檢查快照內容。如果用戶端在此找不到內容,則會檢查專案的內容。此程序可讓您從自訂 Java 程式碼與 Identity Manager 程式碼傳送包含效能評測資料的快照。


備註 –

在 Java 來源快照中,請勿以為來源會隨伺服器更新或一直可以使用。


統計注意事項

以下各節包含計算效能評測器提供結果時所要考量的資訊:

Self Time 統計

若要計算根節點的 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()) 所耗用的時間看似很久,但請勿被此誤導。大部分的時間是耗用在等候事件時的暫停上。您必須研究這些追蹤才能知道處理事件實際耗用的時間。