Sun Identity Manager 8.1 릴리스 노트

통계 경고

다음 절에서는 프로필러가 제공하는 결과를 평가할 때 고려할 정보에 대해 설명합니다.

자체 시간 통계

루트 노드의 자체 시간 통계를 계산하기 위해 프로필러에서는 루트 노드의 총 시간에서 모든 하위 노드의 시간을 뺍니다.

따라서 계측되지 않은 하위 노드 시간은 루트 노드의 자체 시간에 반영됩니다. 루트 노드에 상당한 자체 시간이 있을 경우 그 이유를 확실하게 조사해야 합니다. 적절한 메소드가 계측되지 않았을 수도 있습니다. 그럴 경우 자체 시간이 발생한 이유를 잘못 파악하게 됩니다.

예를 들어, 메소드 A가 메소드 B를 호출한다고 가정해 봅시다.

메소드 A를 호출하는 데 총 10초(총 시간에 B 호출 시간 포함)가 걸리고 B를 호출하는 데 총 10초가 걸립니다.

A와 B 모두 계측된 경우 호출 스택은 해당 정보를 반영합니다. A는 자체 시간이 0초로 표시되고 B는 자체 시간이 10초(실제로 B에서 10초가 소요됨)로 표시됩니다. 그러나 B가 계측되지 않은 경우에는 A를 호출하는 데 10초가 걸리고 A의 자체 시간이 10초로 표시됩니다. 따라서 B가 아니라 A에 직접적인 문제가 있다고 가정할 수 있습니다.

특히 초기 컴파일 중에 JSP에서 큰 자체 시간을 확인할 수 있습니다. 수집된 결과를 재설정한 다음 페이지를 다시 표시하면 자체 시간 값이 훨씬 작아집니다.

구성자 호출

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)

데몬 스레드

ReconTask.WorkerThread.run() 또는 TaskThread.WorkerThread.run()과 같은 &Product_IDMgr의 여러 데몬 스레드에 소요된 시간이 표면상 많은 것으로 나타나더라도 이를 잘못 판단하지 마십시오. 이중 대부분의 시간은 이벤트를 기다리는 동안 휴면 상태에서 소비된 시간입니다. 이러한 추적을 조사하여 이벤트를 처리할 때 실제로 소요된 시간을 확인해야 합니다.