以下各節包含計算效能評測器提供結果時所要考量的資訊:
若要計算根節點的 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()) 所耗用的時間看似很久,但請勿被此誤導。大部分的時間是耗用在等候事件時的暫停上。您必須研究這些追蹤才能知道處理事件實際耗用的時間。