개요 (Sun Identity Manager 8.1 릴리스 노트)

Sun Identity Manager 8.1 릴리스 노트

개요

이 절에서는 Identity Manager 프로필러의 특징과 기능을 개략적으로 설명합니다. 이 정보는 다음과 같이 구성됩니다.

주요 기능

프로필러 유틸리티를 사용하여 다음을 수행할 수 있습니다.

프로필링 데이터의 "스냅샷"을 만들 수 있습니다.

스냅샷은 수집한 모든 프로필 결과를 마지막으로 재설정한 이후에 누적된 프로필링 결과입니다.
네 개의 서로 다른 데이터 보기에 스냅샷 결과를 표시할 수 있습니다.
- 호출 트리 보기는 시스템 전체의 호출 타이밍 및 호출 횟수를 보여 주는 트리 테이블을 제공합니다.
- 핫스폿 보기는 상위 체인에 상관없이 총 호출 타이밍을 보여 주는 일반 노드 목록을 제공합니다.
- 역 추적 보기는 해당 노드(루트 노드)를 호출한 모든 호출 체인을 보여 주는 역 호출 스택을 제공합니다.
- 호출 수신자 보기는 상위 체인에 상관없이 루트 노드의 총 호출 트리를 제공합니다.
스냅샷에 포함할 정보의 종류를 지정합니다.
- 양식, 작업 흐름 및 XPRESS의 모든 요소를 포함하거나 특정 요소 집합으로 컨텐트를 제한할 수 있습니다.
- 계측에 포함하거나 제외할 특정 Java 메소드 및 구성자를 선택할 수 있습니다. Identity Manager 클래스 및 사용자 정의 클래스의 계측이 지원됩니다.
프로젝트 스냅샷을 다음과 같이 관리할 수 있습니다.
- 프로젝트의 nbproject/private/idm-profiler 디렉토리 또는 프로젝트 외부의 임의의 위치에 스냅샷을 저장합니다.
  
  주 –
  IDM 프로필러 보기의 저장된 스냅샷 섹션에서 모든 저장된 스냅샷 목록을 볼 수 있습니다.
- 프로젝트에서 스냅샷을 열거나 프로젝트 외부의 임의의 위치에서 스냅샷을 로드합니다.
- 스냅샷을 삭제합니다.
이름별로 특정 노드를 검색합니다.

프로필러에서 소스를 찾아 관리하는 방법

이 절에서는 프로필러가 다음 Identity Manager 객체에 대한 소스를 조회하고 관리하는 방법을 설명합니다.

참고 –

호출 트리 보기 또는 핫스폿 보기에서 Java 메소드, 작업 흐름, 양식, 규칙 또는 XPRESS에 해당하는 노드를 두 번 눌러 해당 노드에 대한 소스를 볼 수 있습니다.

양식, 규칙, 작업 흐름 및 XPRESS 객체의 경우

프로필러를 사용하여 스냅샷을 찍으면 서버에서 모든 프로필링 데이터를 평가하고 해당 데이터가 종속되는 소스를 검색합니다. 그런 다음 서버는 저장소에서 이러한 모든 소스를 불러와서 스냅샷에 포함합니다. 따라서 스냅샷에 표시된 Identity Manager 객체가 스냅샷이 캡처된 지점을 정확하게 반영하는지 확인할 수 있습니다.

이 프로세스에서는 스냅샷의 크기가 추가되지만, 실제로 소스 크기는 총 크기에 비해 상대적으로 작습니다. 따라서 소스 파일을 개별적으로 보낼 필요 없이 스냅샷을 Sun 고객 지원 담당자에게 보낼 수 있습니다.

Java 소스의 경우

Java 소스의 스냅샷을 찍으면 클라이언트에서 해당 스냅샷을 다운로드한 다음 스냅샷을 통해 프로젝트에서 참조되는 모든 Java 소스를 캡처합니다. 스냅샷을 저장하면 클라이언트는 소스를 압축하여 스냅샷의 끝에 첨부합니다.

그런 다음 사용자가 스냅샷을 보고 Java 소스로 이동하면 클라이언트는 먼저 스냅샷의 컨텐트를 확인합니다. 클라이언트는 거기서 컨텐트를 찾을 수 없는 경우 프로젝트의 컨텐트를 확인합니다. 이 프로세스를 통해 사용자 정의 Java 코드와 Identity Manager 코드 모두의 프로필링 데이터를 포함하는 스냅샷을 보낼 수 있습니다.

주 –

Java 소스 스냅샷에서는 소스가 서버에서 최신 버전이거나 항상 사용 가능하다고 간주하지 마십시오.

통계 경고

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

자체 시간 통계

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

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

예를 들어, 메소드 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의 여러 데몬 스레드에 소요된 시간이 표면상 많은 것으로 나타나더라도 이를 잘못 판단하지 마십시오. 이중 대부분의 시간은 이벤트를 기다리는 동안 휴면 상태에서 소비된 시간입니다. 이러한 추적을 조사하여 이벤트를 처리할 때 실제로 소요된 시간을 확인해야 합니다.