요청 매트릭스 사용 이유

요청 매트릭스는 기본 WebSphere® Application Server 컴포넌트의 각 처리 시간을 기록하는 개별 트랜잭션 추적을 사용할 수 있도록 하는 도구입니다.

시작하기 전에

요청 매트릭스에 의해 추적된 정보는 검색 및 분석용으로 로그 파일에 저장되거나 ARM(Application Response Measurement) 에이전트에 전송됩니다. 또는 둘 다 해당됩니다.
트랜잭션이 시스템을 따라 흐르기 때문에, 요청 매트릭스는 추가 정보를 포함하여 각 컴포넌트로부터 로그 기록을 상호 연관시키거나 완전한 트랜잭션의 기능으로 구성할 수 있습니다. 결과는 다음 예와 같이 표시됩니다.
HTTP request/trade/scenario ------------------------------> 172 ms
     Servlet/trade/scenario  -----------------------------> 130 ms
         EJB TradeEJB.getAccountData --------------------->  38 ms
              JDBC select -------------------------------->   7 ms 

트랜잭션 플로우

응답 시간과 연관된 이 트랜잭션 플로우는 대상 성능 문제점 영역에서 도움을 줄 수 있으며 자원 제한조건 문제점을 디버그할 수 있습니다. 예를 들어 플로우는 트랜잭션이 대부분의 시간을 웹 서버 플러그인, 웹 컨테이너, EJB(Enterprise JavaBeans) 컨테이너 또는 백엔드 데이터베이스에서 사용하는지를 결정하는 데 도움을 줄 수 있습니다. 각 레벨에서 수집된 응답 시간은 각 레벨에서 소비한 시간과 하위 레벨에서 소비한 시간을 포함합니다. 예를 들어 서블릿에 대한 응답 시간 130 밀리초는 엔터프라이즈 Bean과 Java™ Database Connectivity의 시간 38 밀리초도 포함합니다. 그러므로, 92밀리초가 서블릿 프로세스에 해당됩니다.

요청 매트릭스는 특정 트랜잭션에 대한 응답 시간을 추적합니다. 요청 매트릭스는 개별 트랜잭션을 추적하기 때문에 이를 사용하면 시스템에 일부 성능 관련 문제가 부과됩니다. 그러나 요청 필터링 기능을 이용하여 이 문제를 완화할 수 있습니다.

예를 들어 도구는 통합 트랜잭션을 삽입합니다. 요청 매트릭스는 해당 트랜잭션에 대해서 WebSphere Application Server 환경의 응답 시간을 추적할 수 있습니다. 통합 트랜잭션은 시스템의 성능을 사전 테스트하기 위해서 관리자에 의해 시스템으로 통합된 트랜잭션입니다. 이 정보는 관리자가 웹사이트의 성능을 조정하고 적절한 조치를 취하도록 해줍니다. 그러므로 요청 매트릭스에 의해서 제공된 정보는 특정한 요청 유형이 수용 가능한 임계값을 넘는 시기를 발견하는 경보 메커니즘에 사용됩니다. 요청 매트릭스 내의 필터링 메커니즘은 특정 통합 메커니즘에 중점을 두고 사용되며 이 시나리오에서 성능을 최적화하는 데 도움을 줍니다.

이 태스크 정보

분리된 문제점 영역이 있을 때 요청 매트릭스 필터링 메커니즘을 사용하여 이들 영역에 특별히 초점을 맞추십시오. 예를 들어 특정 서블릿이나 EJB 메소드에 분리된 문제점이 있을 때 URI(Uniform Resource Identifier) 알고리즘 또는 EJB 필터를 사용하여 서블릿이나 EJB 메소드에 대해서만 이를 사용 가능하게 하십시오. 이 필터링 메커니즘은 보다 집중된 성능 분석을 지원합니다.

5가지 종류의 필터가 지원됩니다.
  • 소스 IP 필터
  • URI 필터
  • EJB 메소드 이름 필터
  • JMS 매개변수 필터
  • 웹 서비스 매개변수 필터

필터링이 사용 가능한 경우, 필터와 일치하는 요청만 요청 매트릭스 데이터를 생성하고 로그 레코드를 작성하고 ARM 인터페이스를 호출합니다. 실행 중인 시스템에 작업을 삽입하여(특히 추적 정보를 생성하기 위해) 표준 로드 환경에서 특정 요청 유형의 성능을 평가하고 시스템에 도달하는 다른 소스의 요청을 무시할 수 있습니다.

참고: 필터는 요청이 처음으로 WebSphere Application Server에 진입하는 위치에만 적용할 수 있습니다.

프로시저

다음 예제를 통해 요청 매트릭스를 사용하는 방법을 학습합니다.

이 예제에서는 HitCount 서블릿과 Increment 엔터프라이즈 Bean이 서로 다른 두 개의 애플리케이션 서버 프로세스에서 배치됩니다. 다음 다이어그램과 같이 웹 컨테이너 티어와 EJB(Enterprise JavaBeans) 컨테이너 티어가 두 개의 다른 애플리케이션 서버에서 실행됩니다. 이러한 구성을 설정하려면 WebSphere Application Server, Network Deployment를 설치하십시오.

예제

웹 서버 및 웹 컨테이너 티어는 모두 192.168.0.1 시스템에서 실행되며 EJB(Enterprise JavaBeans) 컨테이너 티어가 두 번째 시스템 192.168.0.2에서 실행되는 것으로 가정하십시오. 클라이언트 요청은 다른 시스템(예: 192.168.0.3) 또는 또 다른 시스템에서 전송될 수 있습니다.

소스 IP 필터링 사용을 설명하기 위해 하나의 소스 IP 필터(192.168.0.3)가 정의되고 활성화되었습니다. http://192.168.0.1/hitcount?selection=EJB&lookup=GBL&trans=CMT를 통해 시스템 192.168.0.3에서 발생한 요청을 추적할 수 있습니다. 그러나 소스 IP 주소가 필터 목록에 없기 때문에 임의의 다른 시스템에서 보낸 요청은 추적하지 않았습니다.

소스 IP 필터를 작성한 경우에만 소스 IP 주소에서 발생한 요청이 효과적으로 추적됩니다. 이 도구는 로드에 따른 시스템의 성능 문제점을 찾는 데 효과적입니다. 정상 로드가 다른 IP 주소에서 시작된 경우, 요청은 추적되지 않습니다. 정의된 소스 IP 주소를 사용하여 요청을 생성함으로써 로드된 시스템의 추적 레코드를 로드되지 않은 실행의 추적 레코드와 비교하여 여러 홉에서 성능 장애를 확인할 수 있습니다. 이러한 능력을 통해 복잡한 배치 환경에서 올바른 노드 및 프로세스에 대한 성능 조정에 집중할 수 있습니다.

관리 콘솔을 사용하여 요청 매트릭스가 활성화되도록 하십시오. 또한 추적 레벨이 최소한 hops로 설정되었는지 확인하십시오(프로세스 경계에서 요청 추적 작성). 앞에 나열된 구성을 사용하여 시스템 192.168.0.3에서 HitCount 서블릿을 통해 요청 http://192.168.0.1/hitcount?selection=EJB&lookup=GBL&trans=CMT를 전송하십시오.

이 예제에서 적어도 세 개의 추적 레코드가 생성됩니다.
  • 웹 서버 플러그인의 추적 레코드는 192.168.0.1 시스템에서 플러그인 로그 파일(기본 위치는 plugins_root/logs/web_server_name/http_plugin.log 임)에 표시됩니다.
  • [AIX Solaris HP-UX Linux Windows][z/OS]서블릿의 추적 레코드는 192.168.0.1 시스템에서 애플리케이션 서버 로그 파일(기본 위치는 profile_root/logs/appserver/SystemOut.log임)에 표시됩니다.
  • [IBM i]서블릿의 추적 레코드는 192.168.0.1 시스템에서 애플리케이션 서버 로그 파일(기본 위치는 profile_root/logs/appserver/SystemOut.log임)에 표시됩니다.
  • [AIX Solaris HP-UX Linux Windows][z/OS]증분 Bean 메소드 호출의 추적 레코드는 192.168.0.2 시스템에서 애플리케이션 서버 로그 파일(기본 위치는 profile_root/logs/appserver/SystemOut.log임)에 표시됩니다.
  • [IBM i]증분 Bean 메소드 호출의 추적 레코드는 192.168.0.2 시스템에서 애플리케이션 서버 로그 파일(기본 위치는 profile_root/logs/appserver/SystemOut.log임)에 표시됩니다.
참고: 이 주제는 하나 이상의 애플리케이션 서버 로그 파일을 참조합니다. 권장되는 대안은 분배 및 IBM® i 시스템에서 SystemOut.log, SystemErr.log, trace.logactivity.log 파일을 사용하는 대신 HPEL(High Performance Extensible Logging) 로그를 사용하고 인프라를 추적하도록 서버를 구성하는 것입니다. 원시 z/OS® 로깅 기능과 연계하여 HPEL을 사용할 수도 있습니다. HPEL을 사용하는 경우 서버 프로파일 바이너리 디렉토리의 LogViewer 명령행 도구를 사용하여 모든 로그에 액세스하고 정보를 추적할 수 있습니다. HPEL 사용에 대한 자세한 정보는 HPEL을 사용한 애플리케이션 문제점 해결 정보를 참조하십시오.
192.168.0.1 시스템에 표시되는 두 개이 추적 레코드는 다음과 유사합니다.
PLUGIN:
parent:ver=1,ip=192.168.0.1,time=1016556185102,pid=796,reqid=40,event=0
- current:ver=1,ip=192.168.0.1,time=1016556185102,pid=796,reqid=40,event=1 
type=HTTP detail=/hitcount elapsed=90 bytesIn=0 bytesOut=2252

애플리케이션 서버 (web container tier)
PMRM0003I: parent:ver=1,ip=192.168.0.1,time=1016556185102,pid=796,reqid=40,event=0
- current:ver=1,ip=192.168.0.1,time=1016556186102,pid=884,reqid=40,event=1 
type=URI detail=/hitcount elapsed=60 
시스템 192.168.0.2에서 표시되는 추적 레코드는 다음의 예와 유사합니다.
PMRM0003I: 
parent:ver=1,ip=192.168.0.1,time=1016556186102,pid=884,reqid=40,event=1 
- 
current:ver=1,ip=192.168.0.2,time=1016556190505,pid=9321,reqid=40,event=1              
type=EJB 
detail=com.ibm.defaultapplication.Increment.increment elapsed=40

주제 유형을 표시하는 아이콘 태스크 주제



시간소인 아이콘 마지막 업데이트 날짜: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tprf_requestmetrics
파일 이름:tprf_requestmetrics.html