KR20110124732A - 특정된 트랜젝션 콘텍스트에서의 소프트웨어의 조건부의 동적 인스트루먼테이션 - Google Patents

Abstract

소프트웨어의 런타임 동안 언인스트루먼트 컴포넌트들이 디스커버될 수 있고, 조건적으로 인스트루먼트되는 소프트웨어를 분석하는 기법이 개시된다. 먼저, 어플리케이션등의 소프트웨어가 메소드들과 같은 그러한 인스트루먼트 컴포넌트들의 베이스라인 세트로 구성될 수 있다. 이 어플리케이션이 실행될 때, 인스트루먼테이션으로부터 수집된 수행 데이터가 일부 메소드들의 수행이 기대치 이하에 있음을 표시한다. 이를 분석하기 위해, 문제의 메소드로부터 콜가능한 메소드들이 JAVA 가상 머신(JVM)으로 로드된 클래스들의 바이트 코드를 검사하는 것 등에 의해 디스커버된다. 진단을 제한 및 포커싱하기위해, 디스커버된 컴포넌트들에 추가되는 인스트루먼테이션은 이 인스트루먼테이션이 특정 콘텍스트에서만 실행되도록 조건적일 수 있다. 이 콘텍스트는 예컨대 디스커버드 컴포넌트가 콜되는 컴포넌트들의 특정 시퀀스 및/또는 디스커버드 컴포넌트가 콜되는 트랜젝션 데이터와 관계한다.

Description

특정된 트랜젝션 콘텍스트에서의 소프트웨어의 조건부의 동적 인스트루먼테이션{CONDITIONAL DYNAMIC INSTRUMENTATION OF SOFTWARE IN A SPECIFIED TRANSACTION CONTEXT}

본 발명은 컴퓨팅 환경에서 소프트웨어를 모니터링하는 기술에 관한 것이다.

인터넷뿐만 아니라 인트라넷 및 익스트라넷(extranet)과 같은 다른 컴퓨터 네트워크들이 점차 확대됨에 따라, 전자 상거래(e-commerce), 교육, 및 다른 분야에서 수많은 새로운 어플리케이션들이 등장하게 되었다. 조직체(organization)들은 그들의 사업들 혹은 다른 목적들을 수행하기 위하여 이러한 어플리케이션들에 점점 더 의지하고 있으며 이러한 어플리케이션들이 기대한 대로 실행되고 있는지를 식별하기 위해서 상당한 자원을 할당하고 있다. 이러한 목적을 위해서, 다양한 어플리케이션 관리 기법들이 개발되었다.

하나의 접근법은 어플리케이션에서 인보크(invoke)되는 개별 소프트웨어 컴포넌트들에 관한 어플리케이션 런타임 데이터를 수집함으로써 어플리케이션의 인프라스트럭쳐를 모니터링하는 것을 포함한다. 이러한 접근법은 모니터링되는 시스템에 본질적으로 상주하는 에이젼트들을 이용할 수 있다. 예컨대, 소프트웨어의 인스트루먼테이션을 이용하여, 스레드 또는 프로세스는 인보크되는 각 컴포넌트들을 ㅌ트레이스(trace)함은 물론 각 컴포넌트의 실행시간과 같은 그러한 런타임을 얻기 위하여 트레이싱된다. 트레이싱이란 컴퓨터 프로그램이 실행하는 단계들의 세부 기록, 즉 트레이스를 얻는 것을 지칭한다. 트레이스의 한 유형은 스택 트레이스이다. 트레이스들은 디버깅에 있어서 보조책으로서 이용될 수 있다. 그러나, 어떤 컴포넌트들을 인스트루먼트할지를 결정하는 것은 문제가 될 수 있다. 오버 인크루시브 접근법(over inclusive approach)은 오버헤드 코스트를 과도하게 함은 물론 어플리케이션의 동작에 손상을 줄 수도 있는 결과를 초래하는 반면, 언더 인크루시브 접근법(under inclusive approach)은 중요한 수행 데이터를 누락시키는 결과를 초래한다. 결과적으로, 소프트웨어의 분석 및 진단이 문제가 있을 수 있다.

본 발명은 상기 및 기타 문제점들을 해소하기 위한 소프트웨어를 모니터링하는 기술을 제공하는 것이다.

일 실시예에서, 어플리케이션을 인스트루먼트하는 컴퓨터에 의해 실시되는 메소드는 컴퓨터에 의해 실시되는 복수의 단계를 포함한다. 이 단계들에는 어플리케이션에서 인스트루먼트 메소드로부터 수행 데이터를 얻는 것을 포함된다. 예컨대, 이는 각 메소드의 시작 및 중지 시간을 포함한다. 이 방법은 또한 상기 수행 데이터에 근거하여, 보다 세부적인 분석을 위해 상기 인스트루먼트 메소드들중 적어도 하나의 메소드을 선택하는 것과 그리고 상기 선택에 근거하여 상기 적어도 하나의 메소드에 의해 콜될 수 있고 그리고 비인스트루먼트되는 적어도 하나의 콜가능 메소드을 결정하는 것을 포함한다. 이 방법은 또한 상기 결정에 응답하여, 상기 적어도 하나의 콜가능 메소드에 대한 조건부의 인스트로먼테이션을 제공하는 것을 포함하며, 상기 조건부의 인스트루먼테이션은 상기 적어도 하나의 콜가능 메소드가 콜될 수 있는 콘택스트를 특정한다.

다른 실시예에서, 어플리케이션을 인스트루먼트하는 컴퓨터에 의해 실시되는 방법은 상기 어플리케이션의 적어도 하나의 선택된 메소드의 인스트루먼테이션으로부터 상기 적어도 하나의 선택된 메소드가 실행을 시작함을 표시하는 정보를 수신하는 것과, 그리고 상기 수신에 근거하여 상기 적어도 하나의 선택된 메소드가 수행을 행한다는 표시를 메모리 자원에 저장하는 것을 포함한다. 예컨대, 상기 메모리 자원은 스레드-로컬 캐쉬(thread-local cache)로 될 수 있다. 본 방법은 또한 상기 적어도 하나의 콜된 메소드는 상기 적어도 하나의 선택된 메소드에 의해 콜될 때 상기 어플리케이션의 적어도 하나의 콜된 메소드의 조건부의 인스트루먼테이션으로부터 요청을 수신하는 것을 포함한다. 이 요청은 상기 메모리 자원으로부터, 상기 적어도 하나의 메소드가 실행되고 있다는 표시를 액세스한다. 더욱이, 상기 조건부의 인스트루먼테이션은 적어도 부분적으로 상기 액세스된 표시에 근거하여 상기 적어도 하나의 콜된 메소드의 실행에 관해 보고를 행한다.

또 다른 실시예는 어플리케이션을 인스트루먼트하는 방법을 수행하도록 적어도 하나의 프로세서를 프로그래밍하는 컴퓨터 판독가능 소프트웨어가 수록된 컴퓨터 판독가능 저장 매체를 제공한다. 수행되는 이 방법은 어플리케이션에서 인스트루먼트 메소드들로부터 수행 데이터를 얻는 단계와, 보다 세부적인 분석을 위해 상기 인스트루먼트 메소드들 중 적어도 하나의 메소드를 식별하는 단계와, 상기 적어도 하나의 선택된 메소드에 의해 콜되고 비인스트루먼트되는 적어도 하나의 콜가능메소드를 식별하는 단계와, 그리고 상기 적어도 하나의 메소드가 후속적으로 ㅋ코콜가능 조건이 충족되는지 여부를 판단하는 상기 적어도 하나의 콜가능 메소드에 대한 조건부의 인스트루먼테이션을 제공하는 단계를 포함한다. 상기 조건부의 인스트루먼테이션은 상기 조건이 충족된다는 판단에 근거하여 상기 적어도 하나의 콜가능 메소드의 실행에 관한 수행 데이터를 제공하는 것을 실행하고, 그리고 상기 조건부의 인스트루먼테이션은 상기 조건이 충족되지 않는다는 판단에 근거하여 상기 적어도 하나의 콜가능 메소드의 실행에 관한 수행 데이터를 제공하는 것을 실행한다.

대응하는 방법들, 시스템들 및 실행시 여기에 제시된 방법들을 수행하는 명령들이 수록된 저장매체를 포함하는 컴퓨터 판독가능 또는 프로세서 판독가능 저장 장치들이 제공될 수도 있다.

도 1은 관리 어플리케이션을 포함하는 시스템도이다.
도 2는 도 1의 네트워크의 컴퓨터 시스템도이다.
도 3a는 인스트루먼트 컴포넌트들의 잠재적인 콜링 시퀀스들의 예를 보인 도면이다.
도 3b는 도 3a의 인스트루먼트 컴포넌트들에 의해 콜가능한 디스커버드 컴포넌트들의 예를 보인 도면이다.
도 3c는 도 3b의 디스커버드 컴포넌트들 중 하나에 의해 콜가능한 디스커버드 컴포넌트들의 예를 보인 도면이다.
도 3d는 트랜젝션 데이터의 콘텍스트에서 컴포넌트들이 콜되는 도 3b의 디스커버드 컴포넌트들을 도시한 도면이다.
도 4a는 인스트루먼트 컴포넌트들 및 디스커버드 컴포넌트의 콜링 시퀀스를 포함하는, 전자 상거래 웹사이트에서 제품을 구매하는 트랜젝션의 예를 도시한 것이다.
도 4b는 도 4a의 콜링 시퀀스에 근거한 콜 스택 위치 대 시간 그래프를 도시한 것으로서, 여기서 상기 디스커버드 컴포넌트에 조건부의 인스트루먼테이션이 적용되고 상기 조건부의 인스트루먼테이션의 조건이 콜링 시퀀스에서 하나의 컴포넌트에 의해 충족된다.
도 4c는 도 4a의 콜링 시퀀스에 근거한 콜 스택 위치 대 시간 그래프를 도시한 것으로서, 여기서 상기 디스커버드 컴포넌트에 조건부의 인스트루먼테이션이 적용되고 상기 조건부의 인스트루먼테이션의 조건은 상기 콜링 시퀀스에 의해 충족되지 않는다.
도 4d는 도 4a의 콜링 시퀀스에 근거한 콜 스택 위치 대 시간 그래프를 도시한 것으로서, 여기서 상기 디스커버드 컴포넌트에 조건부의 인스트루먼테이션이 적용되고 상기 조건부의 인스트루먼테이션의 조건은 상기 콜링 시퀀스에 있는 하나의 컴포넌트와 상기 트랜젝션 데이터의 조합에 의해 충족된다.
도 4e는 도 4a의 콜링 시퀀스에 근거한 콜 스택 위치 대 시간 그래프를 도시한 것으로서, 여기서 상기 디스커버드 컴포넌트에 조건부의 인스트루먼테이션이 적용되고 상기 조건부의 인스트루먼테이션의 조건은 상기 콜링 시퀀스에 있는 하나의 컴포넌트에 의해서는 충족되나 상기 트랜젝션 데이터에 의해서는 충족되지 않는다.
도 5a는 인스트루먼티드 컴포넌트들 및 디스커버드 컴포넌트의 콜링 시퀀스를 포함하는, 전자 상거래 웹사이트에서 물건을 구매하는 트랜젝션의 다른 예를 도시한 것이다.
도 5b는 도 5a의 콜링 시퀀스에 근거한 콜 스택 위치 대 타임 그래프를 도시한 것으로서, 여기서 상기 디스커버드 컴포넌트에 조건부의 인스트루먼테이션이 적용되고 상기 조건부의 인스트루먼테이션의 조건이 상기 콜링 시퀀스에서의 3개의 컴포넌트들에 의해 충족된다.
도 5c는 도 5a의 콜링 시퀀스에 근거한 콜 스택 위치 대 시간 그래프를 도시한 것으로서, 여기서 상기 디스커버드 컴포넌트에 조건부의 인스트루먼테이션이 적용되고 상기 조건부의 인스트루먼테이션의 조건은 상기 콜링 시퀀스에 의해 충족되지 않는다.
도 5d는 컴포넌트들과 대응하는 수행 데이터들 간의 계층적 관계를 나타내는 유저 인터페이스 디스플레이를 도시한 것으로서, 이에 의해 유저는 조건적으로 인스트루먼티드되거나 아니면, 조건부의 인스트루먼테이션을 제거하고, 조건부의 인스트루먼테이션의 시퀀스 길이를 특정하고 그리고 트랜젝션 데이터에 근거하여 수행 데이터를 필터링할 컴포넌트를 수동으로 식별할 수 있다.
도 6은 JAVA 런타임 환경을 도시한 것이다.
도 7a는 스태틱 인스트루먼테이션을 위한 JAVA-기반의 예시적인 프로세스 흐름을 보인 것이다.
도 7b는 스태틱 인스트루먼테이션을 위한 .NET-기반의 예시적인 프로세스 흐름을 보인 것이다.
도 8a는 콜가능 메소드들을 식별하고 조건부의 인스트루먼테이션을 적용함으로써 소프트웨어를 분석하는 메소드을 도시한 것이다.
도 8b는 도 8a의 단계 800을 보다 세부적으로 보인 도면이다.
도 8c는 도 8a의 단계 802를 보다 세부적으로 보인 도면이다.
도 8d는 도 8a의 단계 804를 보다 세부적으로 보인 도면이다.
도 8e는 도 8a의 단계 806을 보다 세부적으로 보인 도면이다.
도 8f는 도 8a의 단계 808을 보다 세부적으로 보인 도면이다.
도 8g는 도 8a의 단계 810을 보다 세부적으로 보인 도면이다.
도 8h는 도 8a의 단계 810의 다른 실시예를 보다 세부적으로 보인 도면이다.
도 8i는 도 8a의 단계 812를 보다 세부적으로 보인 도면이다.
도 8j는 도 5b 및 도8i와 관계하여, 스레드-로컬 캐쉬를 수반하는 동작들을 도시한 것이다.
도 9는 도 8a의 메소드와 관련하여 사용될 수 있는 소프트웨어 및 하드웨어를 도시한 도면이다.
도 10은 소프트웨어를 인스트루먼팅하는 예시적인 프로세스 흐름을 보인 도면이다.

본 바렴은 소프트웨어를 분석하는 기법을 제공하는 것으로서, 이에 의해 소프트웨어의 런타임 동안 비인스트루먼트 컴포넌트들이 디스커버드 및 조건부로 인스트루먼트될 수 있다. 먼저, 어플리케이션과 같은 그러한 소프트웨어는 메소드들과 같은 그러한 인스트루먼티드 컴포넌트들의 베이스라인 세트로 구성될 수 있다. 이 어플리케이션이 실행될 때, 수행 데이터가 상기 인스트루먼테이션으로부터 수집되며, 어떤 메소드들의 수행이 기대에 못 미치거나 아니면 문제가 되는지를 알 수가 있다. 문제를 분석하기 위해, 문제의 메소드로부터 콜가능 메소드들을 디스커버하는 기법이 이용될 수 있다. 특별한 실시예에서, 상기 콜가능 메소드들은 JAVA 가상 머신(JVA)으로 로드된 클래스들의 바이트 코드를 검사함으로써 디스커버될 수 있다. 그후, 디스커버된 메소드들을 인스트루먼트 및/또는 보고하기위 한 판단이 이루어진다. 인스트루먼테이션을 선택적으로 추가함으로써, 초기에 오버-인크루시브 인스트루먼테이션을 요함이 없이 수행 문제에 대한 정밀 진단을 가능하게 하는 추가적인 수행 데이터가 상기 디스커버된 컴포넌트들로부터 얻어질 수 있다. 더욱이, 상기 디스커버된 컴포넌트들에 추가되는 인스트루먼테이션은 조건적일 수 있어서 이 인스트루먼테이션은 단지 특정 콘텍스트에서만 실행된다. 이 콘텍스트는 예컨대 디스커버된 컴포너트가 콜되는 컴포넌트들의 특정 시퀀스 및/또는 디스커버된 컴포넌트가 콜되는 트랜젝션의 데이터를 수반할 수 있다. 따라서, 효율적이며 경량(lightweight)의 인스트루먼테이션의 목표들이 필요 시 정밀 분석을 위한 성능으로 달성될 수 있다.

도 1은 여러 개의 컴퓨터 시스템들이 관리자에 데이터를 제공할 수 있는 네트워크를 도시한 것이다. 예시적인 컴퓨터 시스템들은 어플리케이션 서버(106), 또는 원하는 기능을 달성하기 위한 코드를 실행하는 프로세서를 갖는 어떤 다른 타입의 컴퓨터 시스템을 포함한다. 이 어플리케이션 서버들은 서로 다른 어플리케이션들 혹은 동일 어플리케이션의 개별 인스턴스들을 실행할 수 있다. 이 어플리케이션 서버들은 서로 원격으로 위치하거나 혹은 함께 위치될 수 있다. 본 실시예에서, 어플리케이션 서버들(106, 110)은 로컬 관리자 컴퓨터(120)와 통신한다. 로컬 관리자 컴퓨터(120)는 대안적으로 상기 어플리케이션 서버들(106, 110)과 원격으로 위치될 수 있으며, 이 경우에, 이들 간의 통신은 네트워크 클라우드(104)를 통해 발생한다.

예컨대, 웹-기반의 전자 상거래 어플리케이션과 같은 그러한 엔터프라이즈 어플리케이션을 실행하는 기업은 로드 밸런싱(load balancing)을 위해 한 위치에서 다수의 어플리케이션 서버들을 활용할 수 있다. 유저들(예컨대, 유저의 예시적인 웹브라우저(102))로부터의 요청들이 네트워크 클라우드(104)(예컨대, 인터넷)을 통해 수신되어, 어플리케이션 서버들(106, 110)중 어느 것에 라우팅될 수 있다. 웹 브라우저(102)는 전형적으로, 인터넷 서비스 프로바이더(미도시)를 통해 네트워크에 클라우드(104)에 액세스한다. 어플리케이션 서버들(106, 110)상에서 실행되는 에이전트 소프트웨어 (각각 에이전트 A1(108)과 에이전트A2(112)로 표시됨)은 하나의 가능한 접근법으로서, 각각의 어플리케이션 서버(106, 110)에서 실행되는 어플리케이션, 미들웨어 혹은 다른 소프트웨어로부터 정보를 수집한다. 예컨대, 그러한 정보는 인스트루먼테이션을 이용하여 얻어질 수 있으며, 일 예로서, 바이트 코드 인스트루먼테이션일 수 있다. 그러나, 상기 수집 데이터는 다른 방식으로도 또한 얻어질 수 있다. 상기 에이전트들은 본질적으로 모니터링되는 컴퓨터내에 상주하며, 데이터 취득 포인트(data acquisition point)를 제공한다. 에이전트들은 관리자(120)에 통신되는 데이터를 편성 및 최적화한다.

소프트웨어의 실행을 모니터링하기위해 이 소프트웨어를 인스트루먼트하는 다양한 접근법들이 알려져 있다. 예컨대, 서두에 언급한 바와같이, 트레이싱은 소프트웨어의 실행을 추적하는데 이용된다. 트레이싱의 일 예가 발명 명칭이 "Transaction Tracer"인 미국 특허출원 공개번호 2004/0078691에 제시되어 있는 바, 이 공개 문헌의 개시 내용은 본 명세서에 참고로서 포함된다. 이 공개 문헌에 개시된 하나의 접근법에서, 모니터링될 어플리케이션의 객체 코드 또는 바이트 코드가 프로브들로 인스트루먼트(예컨대 수정)된다. 이 프로브들은 어플리케이션의 비지니스 혹은 기타 로직을 변경함이 없이 이 어플리케이션에 관한 특정 정보를 측정한다. 일단 프로브들이 어플리케이션의 바이트 코드에 인스톨되었으면, 이는 관리 어플리케이션으로 칭해진다. 에이전트 소프트웨어는 프로브들로부터 수행 데이터와 같은 그러한 정보를 수신하고 예컨대 관리자(120)에서 다른 프로세스에 이 정보를 통신할 수 있으며, 예컨대 상기 정보가 비정상적인 조건을 표시하는지를 판단하기위해 상기 정보를 국부적으로 처리한다. 예컨대, 프로브들로부터의 정보는 트랜젝션 또는 기타 실행 흐름의 시작 및 정지 시간 즉, 트랜젝션/실행 흐름내에서의 개별 컴포넌트들의 시작 및 정지시간과 같은 그러한 수행 데이터를 표시한다. 이 정보는 이것이 바운드들 내에 있는지를 판단하기 위하여 사전 설정된 기준과 비교될 수 있다. 만일 이 정보가 바운드들 내에 있지 않으면, 상기 에이전트는 적절한 문제 해결이 강구될 수 있도록 이 사실을 관리자에게 통보한다. 에이전트(198, 112 및 116)는 각각, 전형적으로 그들과 관계하는 로컬 어플리케이션 서버(106, 116)에서의 상기 소프트웨어 실행을 인지한다.

관리자(120)는 상기 에이전트들로부터 수신된 데이터에 근거하여 정보를 디스플레이하기 위해 모니터 등의 유저 인터페이스(122)와 통신하는 워크스테이션등의 개별 컴퓨터 시스템에 제공될 수 있다. 도 4b-e 및 도 5b-e의 예시적인 디스플레이를 참 조바란다. 관리자는 또한 상기 에이전트들로부터 수신된 데이터를 저장하기 위해 데이터베이스(118)를 엑세스할 수 있다. 제시된 예에서, 어플리케이션 서버는 네트워크 클라우드(104)에 엑세스함이 없이 관리자(120)와 통신할 수 있다. 예컨대, 상기 통신은 LAN(local area network)을 통해 발생할 수 있다. 다른 설계들에서, 관리자(120)는 네트워크 클라우드(104)를 통해 다수의 어플리케이션의 에이전트들로부터 데이터를 수신할 수 있다, 예컨대, 일부 큰 조직체들은 중앙 네트워크 오퍼레이션 센터를 활용하며, 이 센터들에서 아나 이상의 관리자들이 서로 다른 지리적 위치들에 있는 다수의 분산 에이전트들로부터 데이터를 얻는다. 예시를 위해, 웹-기반 전자 상거래 엔터프라이즈는 고객 주문들을 수신하는 서로 다른 여러 지리적 위치들에 있는 서버들 (예컨대, 페이먼트를 처리하는 서버들, 재고를 추적하여 주문들을 운반하는 웨어하우스들 내의 서버들 및 기타)로부터 에이전트 데이터를 얻는다. 관리자(120) 및 유저 인터페이스 디스플레이(122)는 기업의 본부 위치에 제공될 수도 있다. 반드시 웹-기반일 필요는 없거나 혹은 리테일 또는 다른 세일즈를 포함하는 수반하는 기타 어플리케이션들도 마찬가지로 그들의 시스템을 관리하기 위한 에이전트들 및 관리자들을 활용할 수 있다. 예컨대, 은행은 체크 및 크레디트 어카운트들을 처리하기 위한 어플리케이션을 활용할 수 있다. 더욱이, 전술한 다중-컴퓨터 시스템 구성들에 부가적으로, 하나 이상의 에이전트를 갖는 단일 컴퓨터 시스템이 모니터링될 수 있다.

도 2는 도 1의 네트워크의 컴퓨터 시스템을 도시한 것이다. 컴퓨터 시스템(200)은 도 1과 관련하여 설명된 웹 브라우져(102), 호스트(예컨대, 어플리케이션 서버(106, 110)), 중앙 관리자(120) 및/또는 유저 인터페이스(122)로서 사용될 수 있는 시스템을 개략적으로 나타낸 것이다. 컴퓨터 시스템(200)은 하드 디스크 또는 휴대형 매체등과 같은 그러한 저장 디바이스(210), 다른 컴퓨터 시스템들과 통신하는 네트워크 인터페이스(220), 소프트웨어 명령들을 실행하는 프로세서(230), 예컨대 상기 저장 디바이스(210)로부터 로드된 후 상기 소프트웨어 어플리케이션을 저장하기 위한 RAM과 같은 그러한 작업 메모리(240) 및 유저 인터페이스 디스플레이(250)을 포함한다. 저장 디바이스(210)는 여기서 설명하는 기능들을 제공하는 방법들을 수행하도록 프로세서(230)를 프로그래밍하기 위한 프로세서 판독가능 코드가 수록된 프로세서 판독가능 저장 디바이스인 것으로 고려될 수 있다. 유저 인터페이스 디스플레이(250)는 하나 이상의 에이전트로부터 수신된 데이터에 근거하여 인간 오퍼레이터에 정보를 제공할 수 있다. 유저 인터페이스 디스플레이(250)는 그래픽으로 나타내건, 표로 나타내건 간에 관계없이 모든 알려진 디스플레이 방식을 이용할 수 있다. 온-스크린 디스플레이에 부가적으로, 예컨대, 프린터로부터 등의 하드 카피등의 출력이 제공될 수 있다.

더욱이, 여기에 기술한 기능은 하드웨어, 소프트웨어, 또는 이들의 조합을 이요하여 구현될 수 있다. 소프트웨어의 경우, 하나 이상의 프로세서를 프로그래밍하기위한 프로세서 판독가능 코드가 수록된 하나 이상의 프로세서 판독가능 저장 디바이스들이 사용될 수 있다. 프로세서 판독가능 저장 디바이스들은 휘발성 및 비휘발성 매체, 제거가능 및 제거불가 매체 등의 컴퓨터 판독가능 매체를 포함할 수 있다. 예컨대, 컴퓨터 판독가능 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터 등의 정보를 저장하기 위한 어떤 메소드 또는 기술에서 실시되는 휘발성 및 비휘발성 매체, 제거가능 및 제거 불가 매체를 포함할 수 있다. 컴퓨터 판독가능 매체의 예로서, RAM, ROM, EEPROM, 플래시 메모리 또는 기타 메모리 기술; CD_ROM, DVD 또는 기타 광 디스크 저장 디바이스, 자기 카세트 디바이스, 자기 테이프, 자기 디스크 저장 디바이스, 또는 기타 광 디스크 저장 디바이스; 혹은 원하는 정보를 저장하는데 이용될 있으며 컴퓨터에 의해 엑세스될 수있는 기타 매체들이 있다. 대안적인 실시예들에서, 일부 또는 모든 소프트웨어는 커스텀 집적회로들, 게이트 어레이들, FPGA들, PLD들 및 특수 목적의 프로세서들을 포함하는 전용 프로세서들로 대체될 수 있다. 일 실시예에서, 하나 이상의 실시예들을 구현하는 (저장 디바이스에 저장되는) 소프트웨어가 하나 이상의 프로세서들을 프로그래밍하는데 사용될 수 있다. 이들 하나 이상의 프로세서들은 하나 이상의 컴퓨터 판독가능 매체/저장 디바이스들, 주변기기 및/또는 통신 인터페이스들과 통신할 수 있다.

도 3a는 인스트루먼티드 컴포넌트들의 콜링 시퀀스들의 예를 도시한 것이다. 컴포넌트들은 도 1의 어플리케이션 서버(106, 110)등의 어플리케이션에서 실행될 수 있는 어플리케이션으로 도시된다. 주목할 사항으로, 어플리케이션이 인스트루먼트될 때, 전형적으로 단지 선택된 컴포넌트들만이 어플리케이션에 대한 개발자의 이해 및 관심이 있는 것으로 예상되는 컴포넌트들의 선택에 근거해서만 인스트루먼트된다. 따라서, 관심이 없는 많은 컴포넌트들은 적어도 초기에 어플리케이션에 인보크/콜링 될 수 있으나 인스트루먼트되지는 않는다.

컴포넌트 지향 프로그래밍 모델들이 프로그래머로 하여금 컴포넌트로 일컬어지는 빌딩 블록으로부터 어플리케이션 또는 다른 프로그램을 어셈블리할 수 있게 하는데 유용하다. 각 컴포넌트들은 소프트웨어의 전체적인 기능에 부합되는 특별한 기능을 수행할 수 있다. 더욱이, 어떤 컴포넌트는 다른 컴포넌트들을 콜할 수 있을 뿐만 아니라 반복적인 콜을 통해 스스로 콜링을 행할 수 있어, 한 프로그램에서 컴포넌트들의 시퀀스가 인보크될 수 있게 된다. 이들 컴포넌트는 프로그램이 실행될 때, 컴퓨터 시스템에서 소비되는 자원 즉, 수행되는 작업의 예들이다. 컴포넌트 지향 프로그래밍 모델의 일 예는 J2EE인 바, 이는 JaVa Server Page, Enterprise Java Bean, Servlet, 및 Java Database Connectivity 컴포넌트등의 컴포넌트들을 활용할 수 있다. 그러나, Microsoft.Net 컴포넌트들등의 기타 컴포넌트 지향 프로그래밍 모델들 역시 사용될 수 있다. 더욱이, 이 프로그래밍 모델이 객체 지향일 필요는 없다. 하나의 접근법에서, 이들 컴포넌트들은 메소드들이다.

제시된 특정 실시예에서, 컴포넌트 C1(300) 및 C2(302)는 컴포넌트(304)를 콜 할 수 있다. 화살표는 실행 시작시의 메소드 콜들을 그리고 실행 종료시의 메소드 리턴을 표시한다. 컴포넌트 C3(304) 및 C4(306)는 컴포넌트 C5(308)를 콜한다. 따라서, 가능한 콜 시퀀스는 C1-C3-C5, C2-C3-C5 및 C4-C5를 포함한다. 도시된 이들 컴포넌트 각각은 실행 시간을 포함하는 수행 데이터가 이들로부터 얻어질 수 ㅇ있도록 인스트루먼트된다. 그러나, 콜되지만은 현재 인스트루먼트되지않는 추가적인 컴포넌트들이 있을 수 있다. 어플리케이션의 속도를 지나치게 늦추는 것을 피하기위해, 컴포너트들 모두가 인스트루먼트되지는 않는다. 더욱이, 비록 상기 추가적인 컴포넌트들이 어플리케이션의 성능 문제를 진단하기 위해 일시적으로 인스트루먼트될지라도, 인스트루먼테이션에 의해 제공되는 데이터의 량은 여전히 오버-인크루시브일 수 있다. 최적의 효율을 위해서, 컴포넌트들이 실행을 행하는 콘텍스트에 조건부의 인스트루먼테이션이 제공될 수 있다. 이 콘텍스트는 수행 문제가 발생하는 콘텍스트 혹은 일반적으로, 분석이 요망되는 특정 콘텍스트에 대응하도록 설정될 수 있다. 이 경우에, C5로 콜ㄹ이될 수 있는 언인스ㅌ트루먼티드 메소드, 예컨대 C5의 콜가능한 메소드를 디스커버하기 위한 프로세스들이 실시될 수 있다. 언-인스트루먼트 메소드는 비작동의 인스트루먼테이션 코드 즉, 비-인스트루먼테이션 코드를 가질 수 있다. 도 3b의 예에서, 디스커버드된 컴포넌트들은 C6(310) 및C7(312)이다.

도 3b는 도 3a의 인스트루먼트 컴포넌트들에 의해 콜가능한 디스커버드된 컴포넌트들의 예를 도시한 것이다. 이 디스커버드된 컴포넌트들은 C5와의 수행 문제를 분석하는데 도움이 될 수 있는 수행 데이터를 얻기 위해 인스트루먼트될 수 있다. 예컨대, C6은 너무 길어 C5에 의해 콜되었을 때 실행하기 어려운지만 C7은 C5에 의해 콜되었을 때 허용가능한 성능을 가짐이 판단될 수 있다. 이는 C6과 관련한 추가적인 분석이 보증됨을 나타낸다.

콘텍스트에 관하여, C6 및 C7의 인스트루먼테이션은 콜되는 한 개의 컴포넌트하에서 아니면 복수의 컴포넌트들의 특정 시퀀스하에서 조정(condition)될 수 있다. 예컨대, C5는 시퀀스 C1-C3-C5에서 콜되는 때에는 수행 문제를 갖지만, C2-C3-C5 또는 C4-C5와 같은 그러한 다른 시퀀스에서 콜되는 때에는 성능 문제를 갖지않음이 판단된다. 따라서, C6 및 C7의 인스트루먼테이션은 시퀀스 C1-C3-C5에 의해 콜되는 C6 또는 C7하에서 조정될 수 있다. 만일 C6 또는 C7이 이 시퀀스에 의해 콜되어 특정 콘텍스트에 충족이 되는 경우, C6 또는 C7의 조건부의 인스트루먼테이션은 예컨대 에이전트에 C6 또는 C7의 실행 또는 콜의 보고를 행한다. 마찬가지로, 만일 C6 또는 C7이 다른 시퀀스에 의해 콜되어 특정 콘텍스트가 충족되지 않는 경우, C6 또는 C7의 인스트루먼테이션은 C6 또는 C7의 실행 또는 콜의 보고를 행하지 않는다.

주목할 사항으로, 주어진 콜가능한 컴포넌트에 대해 하나 보다 많은 콘텍스트가 실시될 수 있다. 예컨대, C6은 C1-C3-C5 및 C2-C3-C5의 콘텍스트들에 근거하여 인스트루먼트될 수 있다.

일단 콜가능한 컴포넌트가 디스커버되면, 프로세스는 컴포넌트들의 계층에서 더 레벨 다운되는 콜가능한 컴포넌트들의 추가적인 레벨들을 디스커버하여 인스트루먼팅하도록 반복될 수 있다. 예컨대, 도 3c는 도 3b의 디스커버된 컴포넌트들 중 하나에 의해 콜가능한 디스커버된 컴포넌트들의 예를 도시한 것이다. 특히, 컴포넌트들 C8(314), C9(316) 및 C10(318)이 C6으로부터 콜가능하다. 이들 디스커버된 컴포넌트들은 C6과의 성능 문제를 분석하는데 도움을 줄 수 있는 수행 데이터를 얻기 위해 인스트루먼트될 수 있다. 주목할 사항으로, 본 예는 한번에 컴포넌트들의 한 레벨로 디스커버 및 인스트루먼테이션을 진행하며, 여기서 상기 레벨은 계층적으로 컴포넌트들의 레벨을 칭한다. 예컨대, 도 3c의 계층에서, 제 1레벨은 C1 및 C2를 포함하고, 제 2레벨은 C3 및 C4를 포함하고, 제 3레벨은 C5를포함하고, 제 4레벨은 C6 및 C7을 포함하고, 제 5레벨은 C8, C9 및 C10을 포함한다. 이 계층에서 추가적인 하위 레벨이 있을 수 있거나 없을 수 있다. 또 다른 접근법은 한번에 컴포넌트들의 1보다 큰 레벨로 디스커버 및 인스트루먼테이션을 수행하는 것이다. 예컨대, C6 및 C7이 디스커버되고, 그 후 C8, C9 및 C10이 디스커버되며, 도시하지 않았으나 C7의 콜 가능한 컴포넌트들이 추가로 디스커버될 수 있다. 그 후, 컴포넌트 C6 - C10 및 콜가능한 컴포넌트 C7는 서로 인스트루먼트될 수 있다.

콘텍스트에 관하여, C8,C9 및 C10의 인스트루먼테이션은 콜되는 컴포넌트들의 특정 시퀀스하에서 조정된다. 예컨대, C6은 시퀀스 C1-C3-C5-C6에서 콜되는 때에 수행 문제를 가지지만, 다른 시퀀스에서 콜되는 때는 성능 문제를 가지지않음이 판단된다. 따라서, C8, C9 및 C10의 인스트루먼테이션은 시퀀스 C1-C3-C5-C6에 의해 콜되는 C8, C9 혹은 C10하에서 조정될 수 있다. 만일 C8, C9 혹은 C10이 이 시퀀스에 의해 콜되어 특정 콘텍스트가 충족되면, C8, C9 혹은 C10의 인스트루먼테이션이 C8, C9 혹은 C10의 실행/콜의 보고를 실행한다. 마찬가지로, 만일 C8, C9 혹은 C10이 다른 시퀀스에 의해 콜되어 특정 콘텍스트가 충족되지 않으면, C8, C9 혹은 C10의 인스트루먼테이션은 C8, C9 혹은 C10의 실행/콜의 보고를 실행하지 않는다.

또 3d는 도 3b의 디스커버된 컴포넌트들을 도시한 것으로서, 여기서 컴포넌트들은 트랜젝션 데이터의 콘텍스트에서 콜된다. 콜 콘텍스트의 다른 양상은 `컴포넌트가 실행하는 트랜젝션의 데이터와 관계할 수 있다. 비록 콜 시퀀스에서 디스커버된 컴포넌트들의 인스트루먼테이션을 조정하는 것은 분석할 수행 데이터의 량을 좁히는데 있어 도움이 되지만은, 트랜젝션 데이터 기반 콘텍스트를 설정함으로써 부가적으로 또는 대안적으로 효율들이 얻어질 수 있다. 예컨대, 유저로 하여금 제품을 주문하여 비용을 지불할 수 있게 해주는 웹-기반 전자상거래 어플리케이션을 생각해볼 수 있다. 트랜젝션 데이터는 특정의 페이먼트 유형이 사용될 때, 성능 문제가 초래됨을 나타낼 수 있다.

도 3d에서, 데이터 1 및 데이터 2는 트랜젝션 데이터의 가능한 유형을 나타낸다. 예컨대, 데이터 1은 문제의 페이먼트 유형을 나타내고, 데이터 2는 문제가 없는 페이먼트 유형을 나타내는 것으로 가정해볼 수 있다. 일반적으로, 트랜젝션의 서로 다른 양상들은 각각의 데이터 필드들에 의해 나타내질 수 있다. C1이 C3를 콜링 하는 때에, 이는 예컨대 메세지의 헤더에 데이터 1을 포함하여 C3가 원하는 경우 이 데이터를 엑세스할 수 있게 된다. 이 시퀀스에서, 데이터 1은 C3 내지 C5로 부터 패스되고, 그리고 C5 내지C6 또는 C7로부터 패스된다. 다른 한편으로, C2가 C3를 콜하는 시퀀스에서, (데이터 1과는 다른) 데이터 2가 C2 내지 C3으로부터, C3 내지 C5로부터, 및 C5 내지 C6 또는 C7로부터 패스된다. 이 예에서, C6 또는 C7의 조건부의 인스트루먼테이션은 데이터 1이 C6으로 패스되는 경우에만 수행 데이터의 보고를 실행한다.

도 4a는 인스트루먼트 컴포넌트들 및 디스커버드 컴포넌트의 시퀀스들을 콜하는 것을 포함하는, 전자상거래 웹 사이트에서 물건을 구매하는 트랜젝션의 예를 도시한 것이다. 이는 유저와 관계하는 트랜젝션의 한 예를 보인 것이다. 여기에 사용되는 컴포넌트 식별자들은 이전의 도 3a 내지 도 3d의 예들과 반드시 대응할 필요는 없다. 드러나, 도 4a 내지 도 4e, 도 5a 내지 도 5d 및 도 8j의 컴포넌트 식별자들은 대응되게 사용된다. 유저들로 하여금 아이템들을 주문할 수 있게 하는 웹-기반 전자상거래 어플리케이션을 고려해볼 수 있다. 이들 컴포넌트들은 이 어플리케이션에서 비지니스 로직 또는 전자상거래 단계들에 대응한다. 특히, 컴포넌트 C1(400)은 유저로 하여금 구매할 아이템을 선택하게 하고 그리고 예컨대 페이먼트 메소드의 정보(예컨대, 크레디트 카드 및 크레디트 카드 번호) 및 쇼핑 정보 (예컨대, 상기 아이템을 선적할 주소) 및 선적 메소드 (예컨대, 육로 배송 또는 급행 항공 배송)을 기입할 수 있게 하는 쇼핑 카트를 제공한다. C1은 선택된 아이템이 재고에 있는지를 판단하기 위해 C2(402)에 인벤토리를 체크할 것을 콜한다. 선택된 제품이 재고에 있음이 판단되면, C2는 실행을 종료하고 제어 플로우는 C1으로 리턴된다. C1은 C3A(404) 또는 C3B(406)를 콜하며, C3A(404) 또는 C3B는 트랜젝션이 계류중인 동안 아이템이 다른 유저에게 판매되지 않도록 이 아이템을 보유한다. C3A의 경우, 이 아이템은 유저 자신을 위해 보유되는데 반해, C3B의 경우에는 이 아이템은 예컨대 선물 레지스트리 혹은 위시 리스트에 다른 사람을 위한 선물로서 유저에 의해 보유된다. C3A 또는 C3B는 데빗 페이먼트 컴포넌트 C4A(410)을 콜하거나 또는 크레디트 메이먼트 컴포넌트 C4B(412)를 콜하는데, C4A는 캐시 페이먼트를 예컨대 데빗 카드 혹은 뱅크 어카운트 트랜스퍼 즉, PAYPAL®과 같은 그러한 제 3자 페이어로서 처리하고, 상기 C4B는 크레디트 페이먼트 (예컨대, 특수 크레디트 카드 발행인에 의한 페이먼트 즉, 선물 증서 혹은 쿠폰)를 처리한다. 컴포넌트 C4A 및C4B는 구매에 대한 권한부여 및 인증을 위해 외부 서버와 통신할 수 있다.

본 예에서, C4A 또는 C4B는 컴포넌트 C5(414)를 콜하며, 이 컴포너트는 구매되는 물품의 량을 감분시킴으로써 인벤토리를 조정한다. 그러나, C5는 인스트루먼테이션을 포함하지 않으며, C4A 또는 C4B의 콜가능한 메소드로서 디스커버드된다. 예컨대, 만일 수행 데이터가 C4A는 실행하기에 너무 긴 시간이 걸리는데 반해, C4B는 허용가능함을 나타내면, C5는 C4A의 콜가능한 메소드 및 C5에 적용되는 조건부의 인스트루먼테이션으로서 디스커버될 수 있다. 이는 C5의 수행 데이터가 C4A를 진단하기 위한 시도에서 얻어질 수 있게 한다. C5는 또한 성능 문제를 갖는 C4A 및C4B 모두에 근거하여 디스커버될 수 있다.

일단 C5 및 C5하에서 콜되는 어떤 컴포넌트들(미도시)실행을 완료하면, 실행 플로우는 C1으로 리턴되어 C3A 또는 C3B의 실행의 실행이 완료되며, 그 후 C3A 또는 C3B의 실행이 완료된다. 그 후, C1은 주문 완료 컴포넌트 C7를 콜하여, 예컨대 확인 이메일 또는 웹 페이지로 주문 확인 번호 및 트래킹 번호를 제공함으로써 유저에게 구매를 확인하게 한다.

주목할 사항으로서, 일 컴포넌트는 비동기의 멀티-스레드 혹은 멀티 프로세스 모드에서 실행을 시작하는 다른 컴포넌트의 콜후에도 실행을 계속할 수 있거나 혹은 콜된 컴포넌트가 동기의 단일-스레드 혹은 단일-프로세스 모드에서 실행을 완료할때까지 일시적으로 멈출 수 있다. 예컨대, C3A 또는 C3B는 컴포넌트 C4A 또는 C4B 및 C5가 실행을 하는 동안 멈출 수 있다. 더욱이, 어떤 컴포넌트는 트랜젝션 동안 1번 이상 인보크될 수도 있다.

도 4b는 도 4a의 콜 시퀀스에 근거한 콜 스택 위치 대 시간 드래프를 도시한 것으로서, 조건부의 인스트루먼테이션이 디스커버된 컴포넌트에 적용되고, 조건부의 인스트루먼테이션의 조건이 콜 시퀀스에서 한 컴포넌트에 의해 충족된다. 시간 증분들이 반드시 고르게 이격될 필요는 없다. 그러나, 도 4b-4e, 5b 및 5c의 그래프에서의 시간 증분들은 일치한다.

리프리젠테이션, 즉 트랜젝션 트레이스는 하나 이상의 호스트에 의해 제공되는 실행 경로 정보의 예이다. 이는 예컨대 유저 인터페이스상에서 보고로서 제공되는 그래픽 리프리젠테이션으로 될 수 있으며, 수행 데이터를 메소드들과 같은 그러한 컴포넌트들의 실행 시간 형태로 나타낸다. 실행 경로 정보는 어플리케이션의 매소드들 중 인보크되는 메소드들 및 이들이 인보크되는 시간을 식별할 수 있다. 수평 방향은 시간을 나타내는 반면, 수직 방향은 콜 스택 깊이 또는 위치를 나타낸다. 콜 스택은 하나 이상의 프로그램들 또는 스레드들의 실행 동안 콜 또는 인보크된 메소드들을 식별한다. 실행 경로는 전형적으로 1 초 또는 수초의 몇분에 1로 연장된다.

예시적인 실행 경로는 다음과 같이 컴포넌트들 및 각각의 그래프 영역 및 실행 시간을 나타낸다: C1 420 (t1-t25), C2 422 (t2-t4), C3A 424 (t5-t19), C4A 428 (t6-t18), C5 430 (t7-t17) 및 C7 426 (t20-t24). 본 예는 자신(C3A)을 위한 물품을 보유하고 캐쉬 페이먼트(C4A)를 만드는 옵션을 포함한다. 호스트는 클라이언트로부터 요청을 수신하고, C1이 t1에서 실행을 시작함이 주목된다. 시퀀스에서의 각 트랜젝션은 인스트루먼테이션에 근거하여 에이전트에 의해 주목된다. C1은 t2에서 C2를 콜하고, C2는 t4에서 실행을 완료한다. C1은 t5에서 C3A를 콜하고, C3A는 t6에서 C4A를 콜한다. C4A는 t7에서 C5를 콜하고, C5 t17에서 실행을 완료한다. C4A는 t18에서 실행을 완료한다. C3A는 t19에서 실행을 완료한다. C1는 t20에서 C7을 콜하고, C7는 t24에서 실행을 완료한다. 호스트는 크라이언트에 응답을 제공하는데, 이때에 C1은 t25에서 실행을 완료한다. 상기 호스트는 시간 및 트랜젝션 데이터를 중앙 관리자에게 주시적으로 보고한다.

C56에 대한 영역(430)이 C5가 조건적으로 인스트루먼트됨을 표시하도록 대쉬선으로 도시되었다. 더욱, 본 예에서, 인스트루먼테이션을 작동시키는 요구되는 콘택스트 또는 조건은 C5가 C4A에 의해 콜되는 것이다. 즉, 이 콘텍스트는 스택내에서 하나 이상의 특정한 콜된 메소드들에 근거할 수 있다. 도시된 바와 같이, 콘텍스트에서의 메소드들의 시작 및 종료는 각각 t6 및 t7에서 이루어진다. C4A는 C5가 콜되는 때에 실행되므로, 상기 콘텍스트는 충족되고, C5의 조건부의 인스트루먼테이션이 실행을 행한다.

먼저, C5가 조건부로 인스트루먼트되지않아 도 4b의 그래프가 영역 C5를 포함하고 있지 않음을 가정해보자. 이 그래프는 유저에게 C4A의 응답시간이 너무 길고 트레시홀드 레벨을 초과는지를 판단하도록 자동적으로 처리될 수 있는 그래픽 뒤의 ㄷ대응하는 데이터를 표시한다. 그러나, 이때, C4A에의해 콜되어만 하는 어떤 메소드들에 관한 정보가 유저 인터페이스에 알려지지 않는다. 본 예에서, 여기에 기술된 기법들은 C5가 C4A로부터 콜가능함을 디스커버하는데 이용된다. 콜가능한 컴포넌트는 필연적이지는 않지만 다른 컴포넌트에 의해 콜된다. 그래픽에서 한 레벨 보다 높은 다른 메소드에 의해 직접 콜되는 특별한 메소드는 다른 메소드의 차이들 메소드로 간주될 수 있다. 유사하게, 그래프에 있는 다음의 보다 높은 레벨의 메소드는 상기 특별한 메소드의 그랜드페얼런트 메소드 등일 수 있다. 일단 콜가능한 메소드가 식별되면, 이는 후속적으로 콜되는 때에 이로부터 수행 데이터를 얻기 위해 인스트루먼트될 수 있다. 이 경우에, C5는 이것이 디스커버된 후 인스트루먼트되고, 이 어플리케이션은 실행을 계속하여 새로운 수행 데이터가 수신되고 영역(430)이 그래프에 디스플레이될 수 있다.

도 4c는 도 4a의 콜 시퀀스에 근거한 콜 스택 위치 대 시간을 도시한 것으로서, 조건부의 인스트루먼테이션의 조건이 디스커버드된 컴포넌트에 적용되고, 조건부의 인스트루먼테이션의 조건은 콜 시퀀스에 의해 충족되지 않는다. 도 4b의 경우에서 처럼, 인스트루먼테이을 작동시키기 위해 요구되는 콘텍스트는 C5가 C4A에 의해 콜되는 것이다. 그러나, 이 경우에, C4B가 그래프 영역(429)로 도시한 바와 같이 C4A 대신에 실행된다. 결과ㅣ적으로, C4A의 콘텍스트는 충족되지 않으며, 조건부의 인스트루먼테이션은 실행을 행하지 않아, 영역(43)은 그래프에 나타나지 않게된다. .

도 4d는 도 4a의 콜 시퀀스에 근거한 콜 스택 위치 대 시간을 도시한 것으로서, 조건부의 인스트루먼테이션이 디스커버된 컴포넌트에 적요되고, 조건부의 인스트루먼테이션의 조건은 콜 시퀀스의 한 개의 컴포넌트에 의해 및 트랜젝션 데이터에 의해 충족된다. 전술한 바와 같이, 조건부의 인스트루먼테이션의 콘텍스트 또는 조건은 콜되는 하나 이상의 특정 메소드 및/또는 존재하는 특정 트랜젝션 데이터를 포함할 수 있다. 특히, 트랜젝션에 의해 운반되는 데이터 객체 요소가 검사될 수 있다. 예컨대, 컴포넌트간 메시지들의 헤더에의 특정 값의 존재가 콘텍스트로서 이용될 수 있다. 즉, 무효(null)가 아니거나 무효인 값을 갖는 데이터 필드의 단순한 존재는 콘텍스트로서 이용될 수 있다.

이 트랜젝션 데이터에는 전자상거래 어플리케이션이 특정 포탈, 유저의 지리적 위치, 페이먼트 모드, 제품 선적 모드 등등을 통해 엑세스되는 것에 관계없이 다양한 항목 즉, 주문된 제품의 유형, 제품 판매자의 신원, 구매를 행하는 유저의 계층(예컨대, 유저에게 특별한 특권을 수여하는 멤버쉽을 갖는 "프리미엄" 유저 대 그러한 특권을 갖지 못하는 "일반" 유저)을 포함된다. 이들 경우에서, 인스트루먼테이션은 표시하는 콘텍스트하에서 조절될 수 있다. 따라서, 인스트루먼테이션은 유저가 참여하는 트랜젝션 또는 일반적으로 어떤 트랜젝션의 유형과 관계하는 콘텍스트하에서 조절될 수 있다. 더욱이, 본 발명의 개념들은 웹-기반 전자상거래 어플리케이션에만 국한되는 것이 아니며, 다른 웹-기반 어플리케이션 및 웹-기반이 아닌 어플리케이션들을 포함할 수 있다.

본 예는 콘텍스트와 매칭되는 C4A 내지C5로부터 패스되는 트랜젝션 데이터의 추가를 제외하고는 도 4b와 같다. 결과적으로, 콘텍스트의 2가지 양상이 충족되며, 여기서 제 1 양상은 C5가 콜되는 때 (예컨대, C5가 C4A에 의해 콜되는 때) 실행을 행하는 것이고, 제 2 양상은 특정 데이터가 C4A에 의해 C5로 패스되는 것이다. 이 데이터는 C4A와 C5가 콜되는 트랜젝션의 데이터 객체이다. 상기 콘텍스트가 충족되기 때문에, C5의 조건부의 인스트루먼테이션은 실행을 행한다.

도 4e는 도 4a의 콜 시퀀스에 근거한 콜 스택 위치 대시간을 토시한 것으로서, 여기서 조건부의 인스트루먼테이션이 디스커버된 컴포넌트에 적용되고, 조건부의 인스트루먼테이션의 조건이 콜 시퀀스에서 한개의 컴포넌트에 의해 충족되지만은 트랜젝션 데이터에 의해서는 충족되지 않는다. 본 예에서, C4A에 의해 콜되는 C5의 콘텍스트는 충족되나, 트랜젝션 데이터는 이 콘텍스트와 매칭되지 않는다. 결과적으로, 이 콘텍스트는 충족되지 않으며, 조건부의 인스트루먼테이션은 실행을 행하지 않아 영역(430)은 그래프에 나타나지 않는다.

도 5a는 전자상거래 웹사이트에서 구매를 행하는 트랜젝션의 다른 예를 도시한 것으로서, 인스트루먼트 컴포넌트들 및 디스커버된 컴포넌트들의 콜 시퀀스들을 포함한다. 본 예는 도 4a의 예와 유사하며, C5(414)의 콜가능 컴포넌트들인 컴포넌트 C6A(416) 및 C6B(418)과, 그리고 C6A의 콜가능 컴포넌트들이 되는 것으로 디스커버되는 컴포넌트 C6A1(440), C6A2(442) 및 C6A3(444)를 추가하고 있다. C6A 및 C6B는 각각, 운송회사 A 또는 B를 통해 제품을 선적하는 메소드를 나타낸다. C6A1, C6A2 및 C6A3는 각각, 운송회사 A의 선적부서 A1, A2 또는 A3를 통한 제품의 선적을 나타낸다. 본 예는 C6A1, C6A2 및 C6A3에 대해 조건부의 인스트루먼테이션이 제공되고, C5, C6A 및 C6B에 대해 스태틱 인스트루먼테이션이 제공됨을 보여주고 있다.

도 5b는 도 5a의 콜 시퀀스에 근거한 콜 스택 위치 대 시간을 도시한 것으로서, 여기서 조건부의 인스트루먼테이션이 디스커버된 컴포넌트에 적용되고, 조건부의 인스트루먼테이션의 조건이 코링 시퀀스에서 3개의 컴포넌트에 의해 충족된다. 본 그래프는 C5의 영역(430)이 본 예에서 스태틱으로 인스트루먼트되기 때문에 실선으로 보여진 것을 제외하고는 도 4b의 그래프와 유사하다. 추가로, 영역(45)은 C5에 의해 콜되는 C6A를 나타내며, 점선 영역(452)은 C6A로부터 콜되는 C6A1, C6A2 또는 C6A3를 나타낸다.

C1은 t2에서 C2를 콜하고, C2는 t4에서 실행을 완료한다. C1은 t5에서 C3A를 콜하고, C3A은 t6에서 C4A를 콜하고, C4A는 t7에서 C5를 콜한다. C5는 t8에서 C6A를 콜하고, C6A은 t9에서 C6A1, C6A2 또는 C6A3를 콜한다. C6A1, C6A2 또는 C6A3 t15에서 실행을 완료한다. C6A는 t16에서 실행을 완료한다. C5는 t17에서 실행을 완료한다. C4A는 t18에서 실행을 완료한다. C3A는 t19에서 실행을 완료한다. C1은 t29에서 C7을 콜하고, C7는 t24에서 실행을 완료한다. 호스트는 클라이언트에 응답을 제공하고, 이 시간에 C1은 t25에서 실행을 완료한다.

C6A1, C6A2 또는 C6A3의 조건부의 인스트루먼트에 대한 콘텍스트는 C4A-C5-C6A의 시퀀스가 콜되는 C6A1, C6A2 또는 C6A3에 선행되어야함을 요한다. 이 콘텍스트는 또한 조건부의 인스트루먼테이션을 갖는 컴포넌트들 즉, C6A1, C6A2 또는 C6A3가 시퀀스에서의 마지막 컴포넌트 즉, C6A에 의해 콜되어야 함을 요할 수 있다. 본 예에서, 상기 조건은 충족되어 조건부의 인스트루먼테이션이 실행된다. 특히, C4A (콘텍스트에서의 첫번째 메소드)는 t6에서 실행을 시작한다. C5 (콘텍스트에서의 두번째 메소드)는 t7에서 실행을 시작한다. C6A (콘텍스트에서의 세번째 메소드)는 t8에서 실행을 시작한다. 따라서, 시퀀스에 있는 상기 컴포넌트들 각각은 C6A1, C6A2 또는 C6A3이 콜되는 때에 실행을 행한다. 후속적으로, 상기 콘텍스트의 세번째, 두번째 및 첫번째 메소드들이 각각 t16, t17 및 t18에서 실행을 중지한다.

도 5c는 도 5a의 콜링 시퀀스에 근거한 콜 스택 위치 대 시간 그래프를 도시한 것으로서, 여기서 상기 디스커버드 컴포넌트에 조건부의 인스트루먼테이션이 적용되고 상기 조건부의 인스트루먼테이션의 조건은 상기 콜링 시퀀스에 의해 충족되지 않는다. 여기서, 영역(429)로 나타낸 C4B는 C4A를 대신하여 콜되어, C4A-C5-C6A 의 시퀀스를 요하는 콘텍스트는 충족되지 않고, C6A1, C6A2 또는 C6A3의 조건부의 인스트루먼테이션은 실행되지 않는다.

도 5d는 컴포넌트들과 대응하는 수행 데이터들간의 계층적 관계를 나타내는 유저 인터페이스 디스플레이를 도시한 것으로서, 이에 의해 유저는 조건적으로 인스트루먼트되거나 아니면, 조건부의 인스트루먼테이션을 제거하고, 조건부의 인스트루먼테이션의 시퀀스 길이를 특정하고 그리고 트랙잭션 데이터에 근거하여 수행 데이터를 필터링할 컴포넌트를 수동으로 식별할 수 있다. 유저 인터페이스 디스플레이(500)는 도 5a 및 5b의 예들과 일치한다. 영역(502)의 부분(504)은 하나 이상의 디스커버드된 컴포넌트들, 예컨대 C6A1, C6A2 and C6A3의 이름을 식별한다. 다른 컴포넌트들의 이름 또한 제공될 수 있다. 컴포넌트 이름/식별자 옆에 있는 체크박스는 조건부의 인스트루먼테이션이 컴포넌트들에 적용되도록 하기 위해 유저에 의해 체크될 수 있다. 유저는 인스트루먼테이션이 예컨대 에러에 관련이 있는 컴포넌트들의 관측, 자체적으로 발생된 에러, 이전의 문제해결 경험 및 기타 인자들에 근거하여 임의의 디스커버된 컴포넌트들에 추가되어야 함을 표시할 수 있다. 혹은 인스트루먼테이션은 자동으로 디스커버드 컴포넌트들에 적용될 수 있다.

조건부의 인스트루먼테이션이 컴포넌트에 적용되면, 체크박스는 후속적으로 유저에 의해 체크됨이 없이 제거될 수 있다. 영역(502)의 부분(506)은 유저로하여금 드롭다운 위젯을 이용하여 조건부의 인스트루먼테이션을 위한 콘텍스트에서 시퀀스 길이를 설정할 수 있게 한다. 이는 예컨대, 디스커버된 컴포넌트 앞에서 콜되는 연속적인 컴포넌트들의 수를 나타낸다. 룰 하나의 접근법에서, 시퀀스의 마지막 컴포너트가 디스커버된 컴포넌트를 콜한다. 본 예에서, 상기 길이는 시퀀스 C4A-C5-C6A에 대응하는 각각의 디스커버드된 컴포넌트에 대해 3이다. 여러 컴포넌트들에 대해 서로 다른 시퀀스 길이를 제공하는 것도 가능하다. 시퀀스 길이는 또한 디폴트 레벨로 사전설정될 수 있다. 일반적으로, 제공되는 수행 데이터의 량은 시퀀스 길이를 증대시킴으로써 감소될 수 있다.

디스플레이 영역(502)의 부분(507)은 유저에게 이 유저가 디스플레이 영역(508)에서 데이터 (예컨대, 그의 인스트루먼테이션에 근거한 컴포넌트들에 대한 트레이스)를 디스플레이 영역(51)에 디스플레이하기 위해 디스플레이 영역(508)에서 하나 이상의 컴포넌트들을 선택할 수 있음을 통보함과 아울러, 영역(508)에서 이탤릭체로 보인 컴포넌트 이름들은 더 이상의 데이터가 이용가능하지 않음을 나타내는 것임을 통보한다.

디스플레이 영역(508)에는 어떤 컴포넌트들이 다른 컴포넌트하에 있는지 즉, 다른 컴포넌트에 의해 콜되는지를 보여주는 트리와 같은 그러한 계층적 구조를 이용하여 어플리케이션의 컴포넌트들 각각이 자동으로 퍼퓰레이션될 수 있다. C6A1 는 C6A에 의해 콜되는데, 이는 C6A1의 조건부의 인스트루먼테이션의 콘텍스트가 충족되기 때문이다. 결과적으로, C6A1에 대한 수행 데이터(516)가 영역(508)의 트리에서 마우스 또는 기타 포인팅 디바이스를 이용하여 클릭온 (click on)될 때 이용가능하다. 대조적으로, C6A의 다른 2개의 디스커버된 컴포넌트 즉, C6A2 및 C6A3는 C6A에 의해 콜되지 않는다. 이름 "C6A2" 및 "C6A3"이 트리에 이탤릭체로 디스플레이되어, 어떤 수행 데이터도 현재 이용가능하지 않음을 표시한다. 따라서, C6A2 및 C6A3는 유저가 예컨대 영역(510)에서 대응하는 수행 데이터를 보고자 마우스로 클릭하여도 선택될 수 없다.

디스플레이 영역(510)은 영역(508)의 컴포넌트들 중 선택된 컴포넌트들에 대해 인스트루먼테이션에 근거한 (인스트루먼트 컴포넌트들의 트랜젝션 트레이스들과 같은 그러한) 수행 데이터를 나타낸다. 예컨대, 컴포넌트 C1, C6A 및 C6A1는 영역(508)에서 컴포넌트 이름들의 언더라인으로 표시된 바와 같이 유저에 의해 현재 선택되고, 트랜젝션 트레이스들과 같은 그러한 대응하는 수행 데이터가 영역(510)에서 곡선(512, 514 및 516)에 의해 제공된다. 영역(510)에는 에이전트로부터 중앙 관리자에게 제공되는 수행 데이터가 파퓰레이션된다.

응용가능할 때, 영역(510)의 부분(511)은 유저로 하여금 예컨대 임의의 트랜젝션 데이터를 각각 포함 또는 비포함하도록 박스들을 체킹 또는 비체킹함으로써 수행 데이터를 필터링할 수 있게 해준다. 예컨대, 트랜젝션 데이터 1은 현재 체킹되어, 곡선 (512, 514 및 516)이 각각 트랜젝션 데이터 1하에서 발생하는 C1, C6A 및 C6A1의 인보케이션을 위해서만 제공된다. 일 예로서, 상기 트랜젝션 데이터는 서로 다른 유저 계층들과 관련될 수 있다. 트랜젝션 데이터 1은 "프리미엄" 유저에 관련된 트랜젝션을 나타내고, 트랜젝션 데이터 2는 ("프리미엄" 유저와 "일반" 유저 사이의) "중간-레벨" 유저에 관련된 트랜젝션을 나타내며, 트랜젝션 데이터 3은 "일반" 유저를 나타낸다.

도 6은 JAVA 런타임 환경을 도시한 것이다. JAVA 런타임 환경(600)은 하드웨어(616)에 구축된 오퍼레이팅 시스템(614)에 구축된다. 이 JAVA 런타임 환경은 JAVA API Class (602) 및 JVM( 604)를 비롯한 다수의 가상 부분들을 포함한다. JVM(604)은 레지스터들(606), 오퍼랜드 스택(608), 히프(heap)(610) 및 메소드 영역(method area)(612)을 포함한다. 이 JVM은 바이트 코드 스트림을 명령들의 시퀀스로서 처리한다. JVM 명령은 수행될 오퍼레이션을 특정하는 오피코드로 이루어지며, 이 오피코드에는 연산될 값을 구현하는 제로 또는 그 이상의 오퍼랜드들이 뒤따른다. 오퍼랜드 스택, 히프 및 메소드 영역은 어드레스 가능한 메모리내에 놓인다. 어드레스의 사이즈는 32비트이며, 이들 각각의 메모리 위치는 1바이트를 내포하고, 각 레지스터는 1개의 32-비트 어드레스를 저장한다. 상기 메소드 영역은 바이트 코드들을 내포하며, 바이트 바운드리들에 정렬되는데 반해 오퍼랜드 스택 및 히프는 워드(32-비트) 바운드리들에 정렬된다.

상기 레지스터들은 프로그램 카운터(pc)를 포함하며, 이 카운터는 메모리에서 명령들을 실행하는 트랙을 유지한다. 이 프로그램 카운터는 실행된 다음 바이트 코드를 식별한다. 프레임 레지스터는 오퍼랜드 스택에 있는 현재의 메소드의 실행 환경에 대한 포인터를 포함한다. 오퍼랜드 탑(optop) 레지스터는 오퍼랜드 스택에 대한 ㅍ포인터를 포함하며, 산술 표현들(arithmetic expressions)을 평가하는데 이용된다. 변수(vars) 레지스터는 로컬 변수들에 대한 포인터를 포함한다.

상기 오퍼랜드 스택은 메소드들 및 오퍼레이션들에 파라미터들을 공급하며, 이들로부터 결과를 수신한다. 모든 바이트 코드 명령들은 상기 스택트로부터 오퍼랜드를 취하고, 이들 상에서 연산을 행하며 결과를 상기 스택에 리턴한다. 오퍼랜드 스택은 실행 메소드의 스택 프레임을 포함한다. 스택 프레임은 상태 예컨대, 로컬 변수, ㅁ및 메소드의 특별한 인보케이션에 대한 중간 계산 결과를 홀드한다. 특히, 각 JVM 스레드는 스레드와 같은 시간에 생성되는 개별 JVM 스택(private JVM stack)을 갖는다. JVM 스택은 프레임들을 저장하고, 로컬 변수 및 부분적인 결과들을 홀드하고, 메소드 인보케이션 및 리턴에서 일 부분을 플레이한다. 따라서, 데이터 및 부분적인 결과를 저장함과 아울러 다이내믹 링킹을 수행하고, 메소드들에 대한 값을 리턴하고 예외들을 디스패치하기 위해 프레임이 이용된다. 새로운 프레임이 메소드가 인보크될 때마다 매번 생성된다. 프레임은 그의 메소드 인보케이션이 완료될 때 그 완료가 정상적이건 갑작스런 것이건 간에 상관없이 파괴된다(이는 잡히지 않은 예외를 내던진다). 프레임들은 프레임을 형성하는 스레드의 JVM 스택으로부터 할당된다. 각 프레임은 그 자신의 로컬 변수 어레이 및 그 자신의 오퍼랜드 스택 및 현재 메소드의 클래스의 런타임 상수 풀(rumtime constant pool)에 대한 참조를 가지고 있다.

히프 및 메모리 할당 풀은 스레기 수집된다. 히프는 런타임 데이터 영역이며, 이로부터 모든 크래스 인스턴스들 및 어레이들의 메모리가 할당된다. 히프는 가상 머신 스타트업에서 생성되며, 객체들에 대한 히프 스토리지는 쓰레기 수집기로 알려진 자동 관리 시스템에 의해 리클레임(reclaim)된다. 특히, Java 런타임 환경에서 실행되는 각 프로그램은 거기에 할당되는 쓰레기 수집 히프를 가진다. 더욱이, 히프에서의 각 클래스는 그와 관련된 일정한 풀을 갖는다. 더욱이, 히프에서의 각 클래스는 그와 관련된 일정한 풀을 갖는다. 상수들은 변하지않기 때문에, 이들은 대개 컴파일 시간에 생성된다. 땐과녀각 상기 일정한 풀에 있는 항목들은 특정 클래스에서 어떤 메소드에 의해 이용되는 모든 이름들을 인코드(encode)한다. 이 클래스는 얼마나 많은 상수들이 존재하는지의 카운트 및 상수들의 특정 리스트가 클래스 디스클립션내에서 시작되는 곳을 특정하는 옵셋을 내포한다.

이 메소드 영역은 컴파일된 코드에 있는 메소드들과 관련되는 바이트 코드 명령들 및 실행환경이 다이내믹 링킹을 위해 필요로 하는 심볼 테이블을 저장한다. 메소드와 관련될 필요가 있는 어떤 디버깅 또는 추가적인 정보 또한 이 영역에 저장된다. 프로그램 카운터는 항상 예컨대 메소드 영역에서 일부 비이트의 어드레스를 포인트한다. 이 프로그램 카운터는 실행 스레드의 트랙을 지키는데 이용된다. 바이트 코드 명령이 실행된 후, 프로그램 카운터는 실행할 다음 명령의 어드레스를 내포하게 된다.

상기 메소드 영역은 모든 JVM 스레드들간에서 공유되며, 클래스 및 인스턴스 최기화 및 인터페이스 타입 초기화를 포함하는, 런타임 상수 풀, 필트 및 메소드 데이터, 및 메소드들 및 구성자들의 코드와 같은 그러한 클래스당 스트럭쳐들을 저장한다.

이 메소드 영역은 가상 머신 스타트-업에서 생성된다. 런타임 상수 풀은 클래스 파일에 있는 상수 풀 테이트블의 크래스당 또는 인터페이스당 런타임 리프리젠테이션이다. 이는 컴파일 시간에 알려지는 수치 문자로부터 런타임에 리솔브되어야만 하는 메소드 및 필드 레퍼런스들에 이르는 여러 종류의 상수들을 내포한다. 각 런타임 상수 풀은 JVM의 메소드 영역으로부터 할당된다. 클래스 또는 인터페이스에 대한 런타임 상수 풀은 이 클래스 또는 인터페이스가 JVM에 의해 생성될 때 구성된다.

도 7a는 스태틱 인스트루먼테이션을 위한 JAVA-기반의 예시적인 프로세스 흐름을 도시한 것이다. 이 프로세스는 하나의 가능한 접근법으로서, 도 1의 에이전트(108 또는 112)와 같은 그러한 에이전트(700)에 의해 실시된다. 인스트루먼테이션을 위한 하나의 접근법은 어떤 컴포넌트들 (메소드들 등)이 인스트루먼트 될것인지를 판단하는 스태틱 규칙을 제공하는 것을 수반한다. 이 규칙은 컴포넌트들이 애플리케이션에 로드될 때 엑세스된다. 이러한 접근법에서, 클래스 로더(720)이 어플리케이션의 원시 데이터 바이트들 변환기(715)에 제공하는데 이용되며, 이 변환기는 이 원시 바이트를 예컨대 클래스로 변환한다. 예컨대, JAVA에서, 이는 클래스를 로딩하는 역할을 하는 ClassLoader 객체의 메소드 defineClass를 이용하는 것을 수반한다. 클래스 ClassLoader는 초록 클래스이다. 클래스의 이름을 고려해볼 때, 클래스 로더는 클래스에 대한 정의를 구성하는 데이터를 찾거나 발생하는 것을 시도해야한다. 전형적인 전략은 이름을 파일 이름으로 변환하고, 파일 시스템으로부터 그 이름의 "클래스 파일"을 읽어야만 한다. 이 메소드 defineClass은 바이트의 어레이를 클래스 Class의 인스턴스로 변환한다. 클래스 Class의 인스턴스는 실행중인 JAVA 어플리케이션에서 클래스 및 인터페이스를 나타낸다. 변환기(715)는 따라서 클래스를 변환함으로써 인스트루먼테이션을 추가하기위해 바이트 코드를 변한할 수 있는 소프트웨어이다. 하나의 접근법에서, 변환기(715)의 프로세싱의 최소 유닛은 클래스 파일 및 그의 바이트 어레이이다.

만일 어플리케이션 바이트 코드가 판단 블록(710)에서 규칙(다이렉티브)(705)과 매칭되면, 변환기(705)는 트레이서 바이트 코드 형태로 프로브들을 추가한다. 만일 어플리케이션이 판단 블록(710)에서 규칙과 매칭되지 않으면, 변환기(715)는 바이트 코드에 인스트루먼테이션을 추가하지 않는다. 변환기(715) 및 판단 블록(710)은 프로브 빌더(725)의 일부가 되는 것으로 고려된다.

이 실시예에서, 규칙(705)은 인스트루먼트될 관리 애플리케이션의 부분들을 식별하는 전형적인 스태틱 규칙의 세트이다. 이 규칙들은 일반적으로 가상 머신에 클래스가 처음으로 정의되는 때 실시된다. 클래스는 단지 한번 정의되는 동안 복수번 로드될 수 dLT다 예컨대, 같은 클래스를 로드하는 복수개의 로더들이 있을 수 있다. 더욱이, 클래스들 등의 컴포넌트들은 이들이 어떤 식으로 명명되었는지, 이들이 임의의 서브클래스 또는 수퍼클래스로 확장하는지 등에 근거하여 인스투르먼트될 수 있다. 그러한 컴포넌트들은 인스트루먼트되도록 선택되는데, 그 이유는 이들이 유용하거나 혹은 관심이 있는 수행 데이터를 제공하는 것으로 믿어지기 때문이다.

예컨대, 규칙은 모든 서브렛들이 인스트루먼트되어야 함을 표시하는바, 이는 상기 서브렛들 중에서 적어도 일부가 관심 데이터를 제공할 수 있을 것으로 믿어지기 때문이다. 이 경우에, 규칙(705)은 JAVA클래스 HttpServlet의 서브클래스인 모든 컴포넌트들이 인스트루먼트되어야 함을 표시한다. HttpServlet는 모든 서브랫들이 기존하는 초록 클레스(abstract class)이다. 그러나 모든 컴포넌트들이 인스크루먼티드 될 수 있는 것은 아니며, 오버-인크루시브 인스트루먼테이션의 결과 과도한 오버헤드 비용 및 가능하에는 어플리케이션의 동장 손상을 야기하는데 반해 언더-인크루시브 인스트루먼테이션의 결과 중요한 성능데이터의 누락을 야기한다는 점에서 텐션이 있다.

도7b는 스태틱 인스트루먼테이션의 .Net-기반의 예시적인 프로세스 흐름을 도시한 것이다. 다른 가능한 접근법에서, 관리되는 어플리케이션의 컴포넌트들은 MICRISOFT CORD.".NET"프레임워크에 따라 제공된다. JAVA와는 달리, .NET프레임워크는 클래스로서 이용하지 않는다, 대신에, .NET는 프레임워크를 위해 특별히 기입된 프로그램들의 실행을 관리하는 가상머신을 포함한다. .NET 프레임워크의 런타임 원칙은 Common Language Runtime(CLR)으로 알려져 있다. 어플리케이션 가상머신의 어피어런스를 제공하므로 프로그래머들이 프로그램을 실행할 특정 CPU의 성능을 고려할 필요가 없게 된다. CRL은 또한 보안,메모리 관리 및 예외 처리들의 다른 서비스들을 제공한다. 사전 코딩된 솔루션의 클래스 라이브러리 및 CLR은 서로 .NET프레임 워크를 구성한다

더욱이, CLR은 예외 처리,쓰레기 수집, 보안 및 상호 동작성을 위한 기능들을 비롯한 어플리케이션 개발 및 실행을 위한 언어중접 플랫폼을 제공하는 CLI의 구현이다. CLI는 코어 클래스 라이브러리,커몬 타입 시스템, 커몬 인터미디에이트 랭귀지(CLI)를 포함한다. JAVA바이트 코드에서 처럼, CLI는 중간바이트코드의 다른 예이다. JAVA 및 .NET는 단지 예시적인 구현을 제공하며, 다른구현들도 가능하다.

여기서, 프로세스는 하나의 가능한 접근법에서 에이전트(750)에 의해서 실시된다. 하나의 가능한 시나리오에서, .NET 프레임워크에서의 어떤 프로세스는 클래스를 이름에 의해 참조하며, CLR은 클래스를 발견하여,(있는 경우) 변환기(765)에 보여주고 결과적인 CLI을 이용한다. 특히, 만일 클래스가 판단 블럭(760)에서 규착(755)와 매칭되면 인스트루먼테이션이 추가된다. 만일 클래스가 결정블럭(760)에서 규칙(755)와 매칭되지 않으면, 인스트루먼테이션은 추가되지 않는다. 변환기(765) 및 차단 블럭(760)은 프로브 빌더(775)DML 부분이 되는 것으로 고려될 수있다.

도 8A는 콜가능 메소드들을 식별하고 조건부의 인스트루먼테이션을 적용함으로써 소프트웨어를 분석하는 방법을 도시한 것이다. 하나의 접근법에서, 소프트웨어가 관련된 에이전트는 단계들 중 일부 또는 모두를 수행한다. 전술한 바와 같이, 인스트루먼테이션의 량은 과도한 오버헤드를 괴하도록 제한되어야만 하며, 따라서 어플리케이션의 동작을 이해할 수 있는 능력이 제한된다. 일부 경우들에서, 소오스코드는 만일 이것이 어플리케이션을 진단하기 위해 이용가능했었다면 검토될 수 있으나, 이 소오스 코드는 일반적으로 이용가능하지않고 대부분의 유저들에게는 쉽게 이해될수 없다. 결과적으로, 유저는 어플리케이션을 진단하기 위한 관련정보를 얻기위해 어떤 추가적은 메소드들이 인스트루먼트 되어야만 하는지를 알지 못한다. 대신에, 어플이케이션에 대한 심층 이해 및 진단이 현재 언인스트루먼트 되며 따라서 인지되지 않을 수 있는 콜가능한 메소드들을 선택적으로 디스커버함과 아울러 콜가능한 메소드들의 콜되는 콘텍스트를 식별함으로써 이루어질 수 있다. 이들 추가적인 메소드들은 진단 세션 동안 인스트루먼트될 수 있으며, 후속적으로 이 인스트루먼테이션은 제거될 수 있다. 여기에 제시된 기법들은 또한 커스텀 소프트웨어에 인스트루먼테이션을 추가하는데 유용한바, 표준 인스트루먼테이션 패키지는 인스트루먼테이션이 바람직할 수 있는 코드들의 부분들을 간과할 수도 있다, 에이전드는 이 기법들을 이용하여, 필요 시 특정 메소드 또는 메소드들의 세트에 의해 콜 되는 코드의 부분들을 발견할 수 있다. 예시적인 실시에서 바이트코드분석이 이용된다.

일반적으로, 트레이싱은 유저들로 하여금, 실행을 통해 특정 유저 트랜젝션을 따르고 실행되는 메소드의 시퀀스, 지속기간 및 순서를 보고함으로써 코드문제에 대한 심층진단을 수행할 수 있게 한다. 그러나, 현재의 접근법들은 트랜젝션 범위내에서 및 그 범위 밖에서 메소드들의 실행을 구분하지 못하는바, 이는 오버헤드 및 노이지정보를 야기한다. 더욱이, 콘텍스트없이, 서로다른 트랜젝션들에 대한 보고된 성능 메트릭들의 상대적인 가중이 결정될 수 없다. 전형적으로, 유저들은 트랜젝션 트레이스를 시작하고, 트레이스된 에소드의 인보케이션과 시작하는 어떤 특징의유형의 트랜젝션은 성능 문제를 갖는다. 문제에 관한 보다 많은 정보를 얻기 위해, 유저는 조건부의 트레이싱을 트레이스된 메소드에 적용할수 있다.

단계(800)는 어플리케이션의 런타임 동안 인스트루먼티드 된 메소드들로부터 성능데이터를 얻는 것을 포함한다. 이는 도7a 및 7b와 관련하여 논의한 바와같이 어플리케이션에 로드될 때 어떤 메소드들이 인스트루먼트 될것인지를 판단하는 스태틱규칙에 근거하는 것과 같은 그러한 이미 인스트루먼트되는 메소드들을 포함한다. 다른 접근법에서, 이 메소드들은 어플리케이션에 로드된 후 인스트루먼트 될 수 있다. 도 8b에서 추가적인 설명이 제공된다.

단계(802)는 성능데이터에 근거하여 분석을 행할 어플리케이션의 적어도 하나의 선택된 메소드를 식별하는 것을 포함한다. 예컨대, 도4a의 예에서, 분석할 메소드는 C4A 또는 C4B이다. 도5a의 예에서, 분석할 메소드는 C6A이다. 추가적인 설명이 도 8C에 제공된다.

단계(804)는 분석을 행할 적어도 하나의 메소드의 하나 이상의 콜 가능한 메소드들을 식별하는 것을 포함한다. 추가적인 설명이 도 8d에 제공된다.

단계(806)는 하나 이상의 콜 가능한 메소드들의 콘텍스트를 식별하는 것을 포함한다. 추가적인 설명이 도8e에 제공된다.

단계(808)는 분석을 행할 적어도 하나의 메소드 및 또는 적어도 분석을 행할 적어도 하나의 메소드를 포함하는 컴포넌트의 시퀀스를 재인스트루먼팅 하는것을 포함한다. 추가적인 설명이 도8g에 제공된다.

단계(810)는 콘텍스트에 근거한 조건부의 인스트루먼테이션을 갖는 하나 이상의 콜 가능한 메소드들을 인스트루먼트하는 것을 포함한다. 추가적인 설명이 도8G에 제공된다.

단계(812)는 하나 이상의 콜가능한 메소드들이 어플리케이션의 런타임 동안 연속적으로 콜되고 그리고 콘텍스트가 충족될 때 하나이상의 콜 가능한 메소드들로부터 수행 데이터를 얻는 것을 포함한다. 이 수행 데이터는 조건부의 인스트루먼테이션을 실행함으로써 얻어진다. 보다 세부적인 내용은 도8i에 제공된다.

도 8b는 도 8a의 단계(800)에 대한 보다 세부적인 내용을 제공한다. 단(814)는 인보크 될 때, 성능데이터를 에이전트에 제공하는 인스트루먼트된 메소드들을 포함한다. 단계(816)는 에이전트가 수행 데이터를 관리자에 제공하는 것을 포함한다. 전술한 바와 같은 유저 인터페이스가 단계(817)에서 업데이트될 수 있다.

도8c는 도8a의 단계(802)에 대한 보다 세부적인 내용을 제공한다. 단계(818)는 성능데이터를 수락가능한 성능 레벨의 범위와 비교한다. 단계(816)는 성능이 수락가능하지 않은 적어도 하나의 메소드를 식별한다. EK라서, 분석을 행할 적어도 하나의 메소드가 예컨대 적어도 하나의 메소드와 성능 문제를 표시하는 성능데이터에 근거하여 식별될 수 있다. 이 식별은 성능데이터를 연속적으로 모니터링 하고 예컨대 유저인터페이스 상에서 유저에게 리포트를 제공함으로써 수행될 수 있다. 사전설정된 제한들과의 비교에 근거 범위 밖에 있는 수행 데이터는 자동적으로 플래그 될수있다. 다른 가능한 접근법에서, 이 프로세스는 사용자와 관여 없이 완전자동으로 이루어질 수 없으며, EK라서 식별된 메소드는 수행 데이터가 특정성능 레벨 아래에 있거나 혹은 관심범위에 있음을 표시할 때 자동으로 인스트루먼트 된다.

도8d는 도8a의 단계(804)의 세부적인 내용을 제공한다. 먼저 단계(821)에서, 분석을 행할 적어도 하나의 메소드의 메소드콜들이 존대하는지를 진단하기 위해 캐쉬가 체크될 수 있다. 이 캐쉬는 예컨대 어플리케이션을 실행하는 어플리케이션 서버의 에이전트의 가상머신 내에 있을 수 있다. 일반적으로, 케쉬는 실행 성능을 위해 제공된다. 어플리케이션이 실행을 시작할 때, 이 캐쉬는 비어있다. 분석을 행할 적어도 하나의 메소드를 메소드 doSomething()이라고 가정한다. 이 콜 가능한 메소드들을 검색하는 프로세스가 시작된다. 우리가 하는 첫번째 일은 캐쉬내를 들여다보는 것이다. 만일 콜 가능 메소드들이 캐쉬에 없으면, 도8d의 단계(822-840)는 콜가능한 메소드들을 식별하여 캐쉬에 저장하는 것을 수행한다. 단계(840)는 다음의 의사 코드를 이용하여 doSomething()를 위해 검색되는 메소드 콜들을 캐쉬한다. 메소드 doSomething()을 위해 절차가 작동되는 다음번, 캐쉬는 이전에 검색된 정보를 포함하게 되며, 따라서 우리는 캐쉬에서 콜된 메소드에 관한 정보를 가지고 있기 때문에 단계(822-838)를 더 이상 수행할 필요가 없다. 우리는 전술한 키로 정보를 검색한다.

단계(822)는 반영을 통해 분석을 행할 적어도 하나의 방법의 클래스를 판단한다. 하나의 가능한 실시에서, 이는 JAVA 어플리케이션 프로그래밍 인터페이스(API), java.lang.instument를 이용하는 것을 포함한다(단계824). 분석을 행할 적어도 하나의 방법은 이것이 하나 또는 그 이상의 콜 가능한 메소드들을 인보크 또는 콜할 수 있기 때문에 인보킹 메소드가 되는 것으로 고려될 수 있다. 단계(822)는 메모리에 있는(예컨대 JVM)에 있는 모든 로드된 클래스들 중으로 부터 JAVA클래스를 패치하는 것을 포함한다.

단계(826)는 바이트코드가 얻어진 오리지날 리소스 위치로부터 클래스의 바이트 코드 리프리젠테이션을 로딩하는 것을 포함한다. 예시적인 실시에서, 만일 이용가능한 경우, JAVA클래스 ClassLoader가 사용된다(단계(828)). 주목할 사항으로, 메모리에 로딩되는 코드의 량을 제한하도록 보안 조치가 취해질 수 있으며, 따라서 매우 큰 자동적으로 발생되는 클래스들이 메모리를 압도하지 않게 된다.

단계(830)는 인보크 바이트코드의 하나 이상의 인스턴스를 식별하기 위해 얻어진 각 클래스의 바이트 코드 리프리젠테이션을 파싱하는 것을 포함한다. 특별한 실시예에서, 이는 클래스의 바이트 코드 리프리젠테이션에서 특정 오피코드를(operation code)을 식별하는 것을 포함한다(단계832). 예컨대, JAVA언어에서 4개의 모피코드들은 다른 메소드를 인보크 할 수 있는 바이트 코드를 식별한다. 특히,invokevirtual 위한 오피코드는 데시멀 값182 혹은 헥사데시멀값(0*b6 또는b6)이고, invokevirtual을 위한 opcode는 데시멀 값183 RH는 헥사데시멀값(0*b7 또는 b7)이고, invokestatic을 위한 opcode는 데시멀값 184EH는 헥사데시멀값(0*b8 또는 b8)이고, 그리고 invokeinterface를 위한 opcode는 데시멀 값185 또는 헥사데시멀 값(0*b9 또는 b9)이다. 이들 opcode들 중 어느 것의 존재는 콜가능 메소드들을 식별한다.

또한, 하나 이상의 opcode들(그러나, 모든가능한 opcode들 보다 작음)을 검출하기 위해 단계(832)를 제한하는 것이 가능하다. 예컨대, 인터페이스 메소드는 관심이 없음을 판단할 수 있으며, 이 경우에, invokeinterface를 제외한 인보크virtual, invokestatic을 위한 opcode들 만이 검출된다.

단계(834)는 인보크 바이트코드의 하나 또는 그 이상의 인스턴스들에 근거하여 하나 또는 그 이상의 메소드들을 식별한다. 예시적인 실시에서, 하나 또는 그 이상의콜가능한 메소드들이 단계(822)에서 결정 된 클래스의 상수들로부터 추출된다. 특히, 단계(836)는 opcode들에 근거한 상수 풀에 있는 엔트리들에의 인덱스들을 식별하고, 단계(838)는 이 인덱스들에 근거하여 하나 또는 그 이상의 참조 메소드들을 식별한다. 단계(840)는 하나 이상의 콜 가능한 메소드들을 저장하며, 이 메소드들은 캐쉬에 있는 스티어링으로서 하나이상의 참조 메소드들(예컨대, dosomethig()을 위한 콜 된 메소드들)이다. 주목할 사항으로, 도8d의 프로세스는 다수의 서로 다른 메소드에 대해, 동시에 또는 서로 다른 시간에 개별적으로 수행될 수 있다.

도8e는 도8a의 단계(806)의 세부내용을 제공한다. 단계(842)는 분석을 행할 적어도 하나의 및/또는 분석을 행할 적어도 하나의 메소드를 포함하는 시퀀스와 같은 그러한 메소드들의 시퀀스를 식별하는 것을 포함한다. 이는 도5d의 유저 인터페이스 디스플레이(500)의 영역(508)에 사용을 위해 보고되는 동일한 수행 데이터를 이용하여 행해질수 있다. 본질적으로, 각 방법은 분석을 행할 적어도 하나의 메소드를 콜하게되는 메소드들의 시퀀스에서의 인스트루먼테이션으로부터 알려진다. 예컨대, 도5d 에서, 만일 C6A가 분석을 행할 메소드이면, 트리를 다음의 하위레벨로 트래비싱함으로써 우리는 C6A, C6A2 및 C6A3는 조건부의 인스트루먼테이션을 추가할 메소드들임을 알게 된다. 더욱이, 트리를 상위레벨로 트래비싱 함으로써, 우리는 분석을 행할 적어도 하나의 방법을 포함하는 메소드들의 시퀀스는 시퀀스길이가 2컴포넌트/메소드 일 때는 C5-C6A이고, 시퀀스 길이가 3컴포넌트/메소드일때는 C4A-C5-C6A이며, 시퀀스 길이가 4 컴포넌트/메소드일때는 C3A-C4A-C5-C6A임을 알게된다. 단계(844)는 분석을 행할 적어도 하나의 메소드와 관련된 트랜젝션 데이터 및/ 또는 분석을 행할 적어도 하나의 방법을 포함하는 시퀀스와 같은 그러한 메소드들의 시퀀스를 식별하는 것을 포함한다. 전술한 예에서, 트랜젝션데이터는 유저의 분류를 표시할 수 있다. 그러나, 많은 다른 유형의 트렌젝션 이터들도 가능하다.하나의 가능한 실시에서, 트렌젝션 데이터는 하나 이상의 어플리케이션들에 있는 메소드들 중에서 패스되는 특정데이터 필드에 있다. 예컨데, 유저로부터의 요청은 Userclass=premium은 조건부의 인스트루먼테이션에 의해 검사되는 트랜젝션 데이터 일수있다. Userclass=premium인 경우, 콘텍스트는 충족된다. Userclass=medium 또는 Userclass=regular인 경우 콘텍스트는 충족되지 않는다.

도8f는 도8a의 단계(808)의 세부내용을 제공한다. 단계(846)는 분석을 행할 적어도 하나의 메소드의 클래스 및/또는 분석을 행할 적어도 하나의 방법을 포함하는 시퀀스와 같은 그러한 메소드들의 시퀀스를 각 메소드의 시작 및 종료시 조건부의 앵커들과 함께 재정의하는 것을 포함한다. 클래스들을 재정의하는 것에 대해서는 도10과 관련하여 더 논의된다. 조건부의 앵커들에 대해서는 도8i및 8j와 관련하여 더 논의된다. 단계(848)는 하나 이상의 재정의된 클래스들을 로딩하는것을 포함한다(도10참조). 단계(850)는 하나 이상의 재정의된 클래스들에 근거 바이트코드 인스트루먼테이션을 제공하는 것을 포함한다(도10 참조).

도8g는 도8a의 단계(810)의 세부내용을 제공한다. 단계(852)는 조건이 충족되는 지를 판단하기 위해 스레드-로컬캐쉬와 같은 그러한 메모리 자원을 체크하는 조건부의 인스트루먼테이션을 포함하도록 하나이상의 콜 가능한 메소드들 각각의 클래스를 재정의하는 것을 포함한다. 단계(854)는 하나 이상의 재정의된 클래스들을 로딩하는 것을 포함한다. 단계(856)는 하나이상의 재정의된 클래스들에 근거 바이트코드 인스트루먼테이션을 제공하는 것을 포함한다.

도8b는 도8g의 프로세스에 추가적으로 발생할 수 있는 도8A의 단계(810)의 다른 실시의 상세 내용을 제공한다. 도1과 관련하여 언급한 바와 같이, 복수의 어플리케이션 서버들이 중앙 관리자와 통신하는 각각의 에이전트들을 갖는다. 따라서, 에이전트들은 어플리케이션과 동일한 코드의 개별 인스턴스들을 내포하는 어플리케이션을 실행하는 JVM들의 클러스터에 배치될 수 있다. 에이전트A1(108)과 같은 그러한 하나의 에이전트가 어플리케이션에 있는 적어도 하나의 메소드를 분석하고 하나 이상의 참조, 메소드를 판단할 때, 상기 하나 이상의 참조 메소드의 관리자(120)를 통해서 하나 이상의 다른 에이전트와 공유될 수 있다. 예컨대, 에이전트A1(108)는 새로운 세트의 메소드콜(예컨대,콜가능한 메소드들)이 소정의 클래스 및 메소드를 위해 검색되었음을 관리자(120)에 신호한다. 그 후, 관리자(120)는 관심이 있는 에이전트A2(112)와 같은 그러한 클러스터에 있는 다른 에이전트들에서 메소드콜 검출 단계들의 불필요한 반복을 피할 수 있게 하고 에이전트들로 하여금 디스커버된 콜가능 메소드들의 서로 다른 인스턴스들로부터 수행 데이터를 모을 수 있게 한다. 어플리케이션의 서로 다른 인스턴스들에 걸친 동일 메소드를 위한 수행 데이터를 봄으로써, 보다 큰 인사이트가 어플리케이션의 오퍼레이션에 얻어질 수 있다.

예시적인 프로세스에서, 단계(858)는 어플리케이션의 제1인스턴스와 관련 된 제1에이전트(108)로부터 관리자에게 하나이상의 콜가능 메소드들을 보고한다. 단계(860)에서, 관리자는 어플리케이션의 하나이상의 다른 인스턴스들과 관련된 하나 이상의 다른 에이전트들(112)에 상기 하나 이상의 콜가능 메소드들의 신원을 푸시한다. 단계(862)에서, 상기 하나 이상의 다른 에이전트들은 상기 어플리케이션의 하나 이상의 인스턴스들을 인스트루먼팅한다.

도8i는 도8a의 단계(812)의 세부내용을 제공한다. 단계(864)에서, 콘텍스트의 제1방법이 콜된다. 일부 경우들에서, 콘텍스트가 분석되는 메소드에게 조건부의 인스트루먼테이션을 갖는 메소드를 콜하도록 단지 요청하는 경우와 같은 그러한 단지 하나의 메소드가 콘텍스트에 있을 수 있다. 다른 경우들에서, 상기 콘텍스트는 조건부의 인스트루먼테이션을 갖는 메소드가 콜되기전 메소드콜들의 특정 시퀀스 또는 체인을 요구한다. 단계(866)에서, 콘텍스트의 제1메소드의 시작시 조건부의 앵커가 실행되어 상기 메소드가 실행을 시작했음을 스레드-로컬 캐쉬에 통보한다. 제1메소드는 콘텍스트에 있는 메소드들의 시퀀스에서 그의 위치(예컨데,1,2...)를 반드시 표시해야함을 요하지는 않는다. 보다 구체적인 내용은 도8j를 참조 바란다. 조건부의 앵커는 메소드의 인스트루먼테이션에 있는 코드에 의해 제공될 수 있다. 이 메소드는 EH한 그의 인스트루먼테이션을 통해 성능데이터를 에이전트에 제공할 수 있다. 성능데이터는 메소드가 실행을 시작했음을 단지 표시할 수 있다. 판단단계(868)에서, 만일 콘텍스트에 다음 메소드가 있으면, 다음 메소드는 단계(870)에서 콜된다. 콘텍스트의 다음 메소드의 시작시 조건부의 앵커가 실행되고, 스레드-로컬 캐쉬에 상기 메소드가 실행을 시작했음을 통보한다. 만일 판단단계(868)에서 콘텍스트에 다음 메소드가 없으면, 상기 하나 이상의 메소드가 단계(872)에서 콜된다. 주목할 사항으로, 분석되는 메소드는 동시에 조건부의 인스트루먼테이션을 갖는 하나 또는 복수의 메소드들을 콜할수 있다.

콘텍스트에 잊지않은 메소드가 실행되는 단계(876)는 대안적인 경로를 단계(872)에 제공한다.

단계(874)에서,단계(872)에서 콜되는 상기 하나 이상의 콜가능 메소드들의 조건부의 인스트루먼테이션이 상기 콘텍스트가 충족되는지를 판단하기 위해 상기 스레트-로컬 캐쉬를 체크한다. 도8j를 참조바람.

단계(876)가 인보크 될때와 같이 만일 콘텍스트가 충족되지 않으면, 단계(880)에서 상기 하나 이상의 콜가능 메소드들의 조건부의 인스트루먼테이션은 실행되지 않는다(단계 878). 만일 콘텍스트가 충족되면 판단단계(880)에서 상기 하나 이상의 콜가능 메소드들의 조건부의 인스트루먼테이션은 단계(882)에서 실행되지 않으며, 에이전트에 수행 데이터를 제공한다. 따라서, 조건부의 인스트루먼테이션은 적어도 하나의 콜가능 메소드가 콘텍스트에서 콜됨을 판단할 때 상기 적어도 하나의 콜가능 메소드의 실행에 관해 보고하기 시작한다. 유사하게, 상기 조건부의 인스트루먼테이션은 상기 적어도 하나의 콜가능 메소드가 콘텍스트에서 콜 되지 않음을 판단할 때 상기 적어도 하나의 콜가능 메소드의 실행에 관해 보고하지 않는다.

단계(884)에서, 콘텍스트에 있는 마지막 메소드의 종료시 조건부의 앵커가 실행되고 상기 메소드가 실행을 정지하였음을 스레드-로컬 캐쉬에 통보한다. 판단단계(886)에서, 만일 콘텍스에 다른 메소드가 있으면, 단계(888)가 수행되며, 여기서 상기 콘텍스트에 있는 다음메소드의 종료시 조건부의 앵커가 실행되고, 상기 메소드가 실행을 정지하였음을 상기 스레드-로컬 캐쉬에 통보한다. 만일 단계(886)에서 콘텍스트에 다음 메소드가 없으면, 콘텍스트 외부의 어플리케이션의 실행이 계속된다(단계 890). 이는 예컨대 에이전트가 관리자에게 수행 데이터를 제공하는 것을 포함하거나, 혹은 유저 인터페이스 디스플레이를 갱신하는 것을 포함한다(단계 892). 이들 동작들은 콘텍스트내에서의 실행 동안에도 역시 발생할 수 있다.

도8j는 도5b 및 8i와 일치하는 스레드-로컬 래쉬와 관계하는 동작들을 도시한 것이다. 스레드-로컬 캐쉬는 어플리케이션에 이용가능 하며, 고속 엑세스를 위해 어플리케이션에 로컬인 메모리 자원일 수 있다. 스레드-로컬 캐쉬는 콘텍스트에 있는 메소드들의 인스트루먼테이션에 의해 제공되는 정보를 저장할 수 있으며, 요정하에서 조건부의 인스트루먼테이션에 상기 정보를 제공한다. 토한 도5b를 참조하면, C6A1의 조건부의 인스트루먼테이션을 위해 C4A-C5-C6A의 시퀀스를 요구하는 콘텍스트의 예가 나타나있다. t6에서, C4A는 실행을 시작하고, C4A의 인스트루먼테이션의 조건부의 앵커/코드는 메소드의 식별자/이름 (예컨대,MethodName=C4A)및 실행상태(ExecutionStatus=Executing)를 포함하는 메시지를 스레드-로컬 캐쉬에 전송한다. 이 정보는 메소드가 실행되고 있다는 표시로서 스레드-로컬 캐쉬에 저장된다. 유사하게, t7에서 C5가 실행되기 시작하고, C5DML 인스트루먼테이션의 조건부의 앵커/코드가 메소드의 식별자/이름(예컨대, MethodName=C5)및 실행상태(예컨대, ExecutionStatus=Executing)를 포함하는 메시지를 스레드-로컬 캐쉬에 전송한다. 이 정보는 스레드-로컬 캐쉬에 저장된다. t8에서. C6A의 인스트루먼테이션의 조건부의 앵커/코드가 메소드의 식별자/이름(예컨대, MethodName=C6A)및 실행 상태(예컨대, ExecutionStatus=Executing)를 포함하는 메시지를 스레드-로컬 캐쉬에 전송한다. 이 정보는 스레드-로컬 캐쉬에 저장된다. t9에서,C6A1이 C6A에 의해 콜될때, C6A1의 조건부의 인스트루먼테이션은 하나 이상의 특정 메소드들에 대한 실행 상태를 검색하라는 요청을 스레드-로컬 캐쉬에 전송한다. 이는 메모리 자원으로부터, 하나이상의 메소드들이 실행을 행하는 하나 이상의 표시들을 엑세스하는 요청이다. 이 요천은 MethodName=C4A,C5 및 C6A에 대한 의사코드 검색 실행 상태로 표시된다. C6A1의 조건부의 인스트루먼테이션은 이 정보를 엑세스하고 이를 이용하여 콘텍스트가 충족되는지를 판단한다. 주목할 사항으로, 전술한 바와 같이 콘텍스트가 충족되는지를 판단하기 위해 트랜젝션 데이터가 또한 상기 C6A1의 조건부의 인스트루먼테이션에 의해 추가로 또는 대안적으로 이용될 수 있다. 하나의 가능한 실시에서, 상기 트랜젝션 데이터는 C6A에 의해 C6A1의 상기 조건부의 인스트루먼테이션에 패스되어, C6A1의 상기조건부의 인스트루먼테이션은 스레드-로컬 캐쉬로 부터 상기 트랜젝션 데이터를 엑세스 하지 않는다. 그러나, 상기 트렌젝션 데이터가 콘텍스트에 있는 메소드들에 의해 제공되도록 함과 아울러, 콘텍스트가 충족되는지를 판단하기위해 상기 조건부의 인스트루먼테이션에 의해 엑세스 되도록 하는 것이 가능하다. C6A1의 상기 조건부의 인스트루먼테이션이 상기 콘텍스트가 충족됨을 판단하면, 상기 조건부의 인스트루먼테이션은 적어도 하나의 콜가능 메소드의 실행에 관해 보고를 실행한다. 이 실행은 적어도 부분적으로 C4A,C5 및 C6A로부터 엑세스된 하나 이상의 신원들에 근거한다.

후속적으로, 콘텍스트에 있는 메소드들은 연속해서 실행하는 것을 멈춘다. t16에서, C6A는 실행을 중지하고, C6A의 인스트루먼테이션의 제 2의 조건부의 앵커/코드는 메소드의 식별자/이름 (예컨대, MethodName=C6A) 및 실행 상태 제거/소거 요청(예컨대, Remove ExecutionStatus)을 포함하는 메시지를 스레드-로컬 캐쉬에 전송한다. 혹은 실행상태를 ExecutionStatus=NotExecuting로 세팅하라는 요청이 전송될 수도 있다. t17에서, C5는 실행을 정지하고, C5의 인스트루먼테이션의 제 2의 조건부의 앵커/코드는 메소드의 식별자/이름 (예컨대, MethodName=C5) 및 요청 Remove ExecutionStatus을 포함하는 메시지를 스레드-로컬 캐쉬에 전송한다. t18에서, C4A는 실행을 정지하고, C4A의 인스트루먼테이션의 제2의 조건부의 앵커/코드는 메소드의 식별자/이름 (예컨대, MethodName=C4A) 및 요청 Remove ExecutionStatus을 포함하는 메시지를 스레드-로컬 캐쉬에 전송한다.

조건부의 앵커는 메소드의 시작 및 종료시에 콘텍스트에 있는 트레이스된 메소[0드의 바이트 코드에 추가되는 트레이서이다. 이 트레이서는 2개의 동작을 수행한다. 즉, 이는 메소드가 콜되고 실행을 시작할때 콜되었다는 사실을 맵과 같은 그러한 데이터 구조로 스레드-로컬 캐쉬에 저장하고, 그리고 메소드의 종료시 이 정보를 제거한다. 조건부의 앵커들의 이용에 의해 발생되는 오버헤드는 미미하다. 하나의 가능한 접근법에서, 조건부의 앵커 트레싱서들은 일정한 엑셋스 시간으로 맵 구조를 업데이트한다. 이 맵은 스레드-로컬 캐쉬에 있으므로 경합이 존재하지 않는다. 마찬가지로, 조건부의 인스트루먼테이션의 사용에 의해 발생되는 오버헤드는 미미하다.

스레드-로컬 캐쉬에 대한 대안으로서, 메소드의 조건부의 인스트루먼테이션은 콘텍스트가 충족되는지를 판단하기 위해 메소드의 인보케이션 시간에 콜 스택을 분석할 수 도 있다. 전술한 바와같이, 콜 스택은 하나 이상의 프로그램 또는 스레드의 실행동안 콜 또는 인보트된 메소드들을 식별한다. 이 접근법에서, 상기 메소드는 콜 스택이 콘텍스트가 충족됨을 표시하는지를 판단한다. 스레드-로컬 캐쉬의 이용이 더 수행될 수 있는데, 이는 스택의 깊이에 따라 상당한 엑세스 시간을 야기할 수 있는 스택 관찰이 필요 없기 때문이다.

도9는 도 8d의 메소드와 관련하여 이용될 수 있는 소프트웨어 및 하드웨어(집합적으로, 900으로 표시함)를 도시한다. 하드웨어는 다이내믹 인스트루먼테이션 캐쉬(902), 메모리 자원인 스레드-로컬 캐쉬()904)(도 8j 참조) 및 다른 메모리 자원(915)을 포함한다. 스레드-로컬 캐쉬는 스레드 로컬인 스태틱 또는 글로벌 메모리 자원일 수 있다. JAVA에서, ㅅ스슬스레드-로컬 변수들이 ThreadLocal 클래스로 실시된다. ThreadLocal 객체는 이 객체의 겟트(get) 또는 세트 메소드를 콜하는 각 스레드에 대한 변수의 개별 인스턴스를 유지한다.

다이내믹 인스트루먼테이션 캐쉬는 분석되는 메소드에 대해 식별된 콜가능 메소드들을 저장한다. 이후, 이 콜가능 메소드는 동일 메소드의 후속 분석이 수행되면 캐쉬로부터 빠르게 식별됨으로써 컴퓨팅 자원들의 소비를 줄일 수 있다. 자원(915)은 어플리케이션이 인스트루먼트되어 실행을 시작할때 메모리에 로드되는 어플리케이션의 서로 다른 클래스들의 바이트 코드를 저장하느데 이용되는 메모리 로케이션일 수도 있다. 하나의 가능한 실시예서, 다이내믹 인스트루먼테이션 캐쉬 (902) 및 자원(915)이 어플리케이션 서버에 있는 도 2의 메모리(240)에 제공된다.

java.lang.instrument API(910)는 도 8d의 단계(822) 및 (824)에 따라 분석되는 적어도 하나의 메소드의 특정 클래스(295)를 판단하기 위해 모든 로드된 클래스(905)에 엑세스 하는데 이용된다. 한 접근법에서, 모든 로드된 클래스들은 어레이로 제공된다. 클래스(925)에 근거하여, 캐쉬 로더(920)가 도 8d의 단계(826) 및 (828)에 따라 클래스(925)에 대한 크래스 바이트 코드(930)를 로딩하기위해 자원(915)에 엑세스하는데 이용된다. 클래스 바이트 코드(930)는 도 8d의 단계(830) 및 (832)에 따라 opcode들 (935, 940, 945 및 950)의 하나 이상의 인스턴스를 식별하기 위해 파싱된다. 각 opcode는 도 8d의 단계(834, 836 및 838)에 따라 정수 풀(955)로부터 메소드 콜의 스트링을 페치하는데 이용되는 각각의 인덱스 바이트 <indexbyte1, indexbyte 2>를 가질 수 있다.

도 10은 소프트웨어를 인스트루먼팅하는 예시적인 프로세스 흐름을 도시한 것이다. 도 5a에 따라, 컴포넌트(1010)의 스태틱 리스트가 클래스 로더(1002)에 제공될 수 있으며, 이 클래스 로더(1002)는 변환기/프로브 빌더(1000)이 인스트루먼트된 바이트 코드를 제공하는데 이용되는 바이트 코드를 로드한다. 이 바이트 코드는 옵션에 따라 메신 코드에 컴파일될 수 있다. 예컨대, 이 메소드 defineClass는 바이트의 어레이를 클래스 Class의 인스턴스로 변환한다. 더욱이, 도 8a의 프로세스에 의해 디스커버드된 메소드들과 같은 그러한 디스커버드 컴포넌트(1006)이 인스트루먼트될 수 있다. 한 접근법에서, 도 5d에 도시한 유저 인터페이스(1008)는 유저로 하여금 인스트루먼트될 디스커버드 컴포넌트들을 지정할 수 있게 한다. 유저는 또한 스태틱 리스트(1010)를 수정할 수 있다. 유저 인터페이스는 관리 어플리케이션에 있는 기존 인스트루먼테이션으로부터 흐르는 수행 데이터를 모니터하는 수행 모니터(1012)에 응답할 수 있으며, 예컨대 일부 컴포넌트들이 실행하기에 너무 긴 시간을 취하는 등의 트랜젝션에 있어서의 문제를 야기한다는 사실을 식별할 수 있다. 이 수행 데이터는 그것이 범위 밖에 있는지를 판단하기 위해 상위 및 하위 드레시홀드와 비교될 수 있다.

디스커버드 컴포넌트는 인스트루먼트되어야만 하는 클래스들의 다이나믹하게 업데이트가능한 리스트를 포함할 수 있다. 이 리스트는 특정 메소드들이 진단이 수행되는 제한된 시간 주기동안 인스트루먼트될 수 있도록 시간에 따라 변할 수 있다. 유저 인터페이스(1008)는 시간 주기를 특정하며, 혹은 디폴트 시간 주기가 이용될 수 있다. 따라서, 예컨대 어느 한 시간 지점에서 인스트루먼테이션을 갖지 않는 것으로부터 다른 시간 지점에서 인스트루먼테이션을 갖는 것으로 천이하도록 컴포넌트가 재정의될 수 있다. 또한, 인스트루먼테이션의 서로 다른 유형 또는 레벨 예컨대, 컴포넌트의 수행의 많은 양상들이트랙킹되는 인스트루먼트의 하이 레벨 및 컴포넌트의 수행의 단지 일부 양상들이트랙킹되는 로우 레벨을 제공하는 것이 가능하다. 따라서, 컴포넌트를 재정의하는 것은 인스트루먼테이션의 다른 유형으로의 천이를 수반한다.

인스트루먼테이션은 많은 유형의 수행 메트릭/데이터를 산출할 수 있는바, 이들에는 컴포넌트의 평균 실행 또는 응답 시간, 초당 또는 인터벌당 인보케이션, 인보케이션의 카운트, 시작되었으나 인터발당 완료되지 않은 다수의 인보케이션을 표시하는 동시 메트릭, 및 시작되었으며, 그의 메소드 인보케이션 시간이 인터벌당 특정 드레시홀드를 초과한 다수이 인보케이션을 포함하는 정체된 메트릭이 포함된다. 또한, 데이터는 쓰레기 수집 하프 사이즈, 화일 및 소켓 동작을 표시하는 대역폭, 다수의 스레드, 시스템 로그, 예외, 메모리 리크 및 컴포넌트 인터액션을 식별할 수 있다. 이 데이터는 또한 어떤 컴포넌트들이 인스트루먼트된 컴포넌트에 의해 콜되었는지를 식별하거나 혹은 인스트루먼트된 컴포넌트를 콜할 수 있다. 예컨대, 제어기 아키텍처에서, 어떤 컴포넌트들이 다음에 실행되는지에 대해 제어를 가지며, 이들이 얼마나 종종 실행을 행하는지 및 이들이 어떻게 수행을 하는지를 아는 제어기 컴포넌트를 통해 제어가 흐른다. 제어기 컴포넌트는 인스트루먼테이션을 통해 어떤 인스트루먼트되지않은 컴포넌트가 빈번히 인보크되고 따라서 아마도 관심이 있고 인스트루먼테이션을 추가하기 위해 재정의되어야만 하는지를 보고할 수 있다.

전술한 바와같이, 인스트루먼테이션의 유형을 변경하기위해 컴포넌트를 재정의하는 것이 가능하다. 예컨대, 기존 인스트루먼테이션이 예컨대 반운드를 벗어난 하나 이상의 파라메터들로 인한 문제를 검출할때 보다 많은 인스트루먼테이션이 추가될 수 있다. 또한, 추가적인 인스트루먼테이션은 이 인스트루먼테이션이 정상 조건이 리턴되었음을 설정하는 때 후속적으로 제거될 수 있다. 이 제거는 유저 명령에 의해 혹은 유저 개입없이 자동으로 수행될 수 있다.

주목할 사항으로, 디스커버드 컴포넌트(1006), 유저 인터페이스 (1008), 컴포넌트(1010)의 스태틱 리스트 및 수행 모니터(1012)가 동일 위치 또는 서로 다른 위치에 제공될 수 있다. 예컨대, 유저 인터페이스(1008)는 유저 인터페이스 호스트(122)(도 1)에 제공될 수 있고, 디스커버드 컴포넌트들(1006) 및 컴포넌트(1010)의 스태틱 리스트는 어플리케이션 서버(106 또는 110)에 제공될 수 있고, 수행 모니터(1012)는 관리기(120)과 관련되고 이 관리기는 어플리케이션 서버(106, 110)에 있는 에이저느(108, 112) 각각으로부터 수행 데이터를 수신한다.

수행 모니터(1012)는 어떤 컴포넌트들이 문제의 트랜젝션에 연루되는지에 대한 아이디어를 제공하며, 이들 컴포넌트가 문제를 야기할 수 있는지, 혹은 야기하는지를 판단하고 이 정보를 유저 인터페이스(1008)에서 식별할 수 있다.

유저 인터페이스(1008)는 유저로 하여금 예컨대 디스커버드 컴포넌트들을 비롯한 어떤 컴포넌트들이 인스트루먼트될 것이지 아니될 것인지를 수동으로 취해 선택할 수 있게 한다. 서로 다른 유형들이 이용가능할 때, 상기 인스트루먼테이션의 유형이 또한 유저 인터페이스를 통해 특정될 수 있다.

컴포넌트들(1010)의 스태틱 리스트는 어플리케이션이 실행될때 인스트루먼트될 클래스들 또는 다른 컴포넌트들을 포함할 수 있다. 이는 중요한 데이터를 산출하는 것으로 예상되는 컴포넌트들의 베이스라인 리스트일 수 있다. 하나의 접근법에서, 디스커버드 컴포넌트(1006)의 리스트는 시스템이 시동하는 다음번 동일한 컴포넌트들이 인스트루먼트되도록 계속된다. 이는 유저로 하여금 컴포너ㅌ트로부터 일정한 데이터, 보고 및 수행 데이터를 갖도록 해주며, 유저로 하여금 환경을 설정할 수 있도록 하는 옳바른 방안을 제공한다.

컴포넌트는 이 컴포넌트가 런타임에서 어플리케이션내에 이미 통합되었는지 여부에 따라 서로 다른 방식으로 재정의될 수 있다. 만일 컴포넌트가 어플리케이션에 이미 통합되어 있지 않으면, 이는 하나의 가능한 실시에서, 클래스 로더(1002)에 의해 JVM에 로드됨으로써 통합될 수 있다. 다른 실시들에서, .NET 프레임워크를 이용하는 것들의 경우에서는 클래스 로더가 사용되지 않는다.

컴포넌트가 로드되는 때에, 변환기/프로브 빌더(1000)는 만일 지시가 있는 경우 예컨대 유저 인터페이스(1008), 디스커버드 컴포넌트(1006), 컴포넌트의 스태틱 리스트(1010) 및 수행 모니터(1012)에 응답하여 컴포넌트를 인스트루먼트한다. 이미 어플리케이션에 통합되어 있으나 인스트루먼트되지 않은 컴포넌트는 인스트루먼테이션으로 어플리케이션에 제통합될 수 있다. 예컨대, 이 컴포넌트는 어플리케이션으로부터 제거되어 런타임동안 가상 머신을 재가동함이 없이 재로드될 수 있다. 이를 달성하기 위해, JAVA redefineClass 명령이 컴포넌트를 갖는 클래스 로터(1002)에 제공된다. JAVA DEVELOPMENT KIT (JDK) 버전 1.5 또는 상위 버전은 이 명령을 이용하는 재정의 성능을 갖는다. 이 명령은 공급되는 클래스 파일들을 이용하여 공급된 클래스 세트를 재정의한다. 이는 동시에 아나 보다 많은 클래스로의 인터록킹된 변경을 가능하게 하기위해 세트로 동작한다. 더욱이, 만일 재정의된 메소드가 액티브 스택 프레임들을 가지고 있는 경우, 이들 액티브 프레임들은 오리지날 메소드의 바이트 코드들을 계속 실행하고 재정의된 메소드는 새로운 인보크들에서 이용되게 된다.

클래스와 같은 그러한 컴포넌트를 재정의하는 것은 그 클래스에 대해서만 가상 머산을 재시동하는 것과 유사하다. 클래스가 재정의되는 때에, 만일 이 클래스가 이미 기존 메소드 스택에 있으면, 이는 그곳에 머무른다. 그러나, 모든 새로운 인보케이션에 대해 상기 새로운 클래스가 이용된다. 즉, 일단 재정의되면, 새로운 버전이 픽업된다.

변환기/프로브 빌더(1000)가 재정의된 컴포넌트를 수신하는 때에, 이는 만일 그렇게 해도록 지시된 경우 상기 컴포넌트를 인스트루먼트한다. 변환기/프로브 빌더(1000)는 또한 인스트루먼테이션의 특정 유형을 상기 컴포넌트에 추가할 수 있다.

디스커버드 컴포넌트가 인스트루먼트되어 어플리케이션에 재통합된 후, 이 인스트루먼트는 진단을 위해 더 이상 필요하지 않으며, 상기 컴포넌트는 다시 상기 어플리케이션에 인스트루먼테이션 없이 재통합된다. 이와 같은 인스트루먼테이션의 제거는 유저 명령, 특정 진단 주기 후의 타임아웃 또는 기타 일부 다른 이벤트에 근거하여 이루어질 수 있다. 예컨대, 수행 모니터(1012)는 디스커버드 컴포넌트의 수행 데이터가 임의의 시간 주기동안 수락가능한지 아니면 컴포넌트의 인보케이션들의 수 동안 수락가는한지를 판단할 수 있다. 즉, 수행 모니터(1012)는 인스트루먼트 메소드들중 적어도 하나의 메소드의 수행 데이터가 더 이상 드레쉬홀드 수행 레벨을 충족하지 못하는지를 판단할 수 있다. 이에 응답하여, 수행 모니터(1012)는 인스트루먼테이션을 제거하도록 redefineClass와 같은 그러한 명령을 발행할 수 있다.

인스트루먼테이션의 추거 및 제거는 런타임에 동적으로 행해질 수 있어 바이트 코드를 실행하는 가상 머신을 낮출 필요가 없게 되며, 인스트루먼트된 컴포넌트들로부터의 데이터는 (인스트루먼테이션을 추가하는 경우) 즉시 엑세스될 수 있다.

전술한 본 발명의 상세한 설명은 예시 및 설명 목적으로 제공되었다. 이러한 것이 본 발명의 모두를 설명하도록 의도되지 않았으며 혹은 본 발명이 이렇게 개시되는 특정 형태로만 한정되도록 의도되지도 않았다. 많은 수정 및 변형이 앞서의 가르침을 고려하는 경우 가능하다. 본 명세서에서 설명되는 실시예들은 본 발명의 원리 및 그 실제 응용을 가장 잘 설명하기 위해 선택되었는 바, 이로 인해 본 발명의 기술 분야에서 숙련된 기술을 가진 다른 사람들이 다양한 실시예로 그리고 고려하는 특정 용도에 적합하도록 다양하게 수정하여 본 발명을 가장 잘 사용할 수 있도록 하기 위한 것이다. 본 발명의 범위는 본 명세서에 첨부되는 특허청구범위에 의해 정의되도록 의도되었다.

Claims (16)

1. 컴퓨터에 의해 실시되는 단계들을 포함하는 어플리케이션을 인스트루먼팅하는, 컴퓨터에 의해 실시되는 방법으로서,
   상기 단계들은:
   인스트루먼트 메소드들(C1-C7)을 포함하는 인스트루먼트 컴포넌트들의 베이스라인 세트로 상기 어플리케이션을 구성(configuring)하는 단계와, 상기 어플리케이션의 코드는 또한 언인스트루먼트 메소드들(C4A)을 포함하며;
   컴퓨터 시스템에서 상기 어플리케이션의 코드를 실행하는 동안, 상기 인스트루먼트 메소드들로부터 수행 데이터를 얻는 단계와;
   상기 수행 데이터에 근거하여, 세부적인 분석을 위해 상기 인스트루먼트 메소드들(C4A)중 적어도 하나를 선택하는 단계와;
   상기 선택에 근거하여, 상기 적어도 하나의 선택된 인스트먼트 메소드에 의해 콜될 수 있는 언인스트트먼트 메소드들중 적어도 하나의 콜가능 메소드(C5)를 결정하는 단계와;
   상기 결정에 응답하여, 상기 적어도 하나의 콜가능 메소드에 대한 조건부의 인스트루먼테이션으로 상기 어플리케이션의 코드를 구성하는 단계와, 여기서 상기 조건부의 인스트루먼테리션은 상기 적어도 하나의 콜가능 메소드가 콜될 때 상기 조건부의 인스트루먼테이션이 작동될 콘텍스트를 특정하고, 상기 콘텍스트는 상기 적어도 하나의 선택된 인스트루먼트 메소드에 의해 콜되는 상기 적어도 하나의 콜가능 메소드를 포함하며;
   상기 컴퓨터 시스템에서 상기 조건부의 인스트루먼테이션으로 상기 어플리케이션의 코드를 실행하는 동안, 상기 적어도 하나의 콜가능 메소드가 상기 콘텍스트에서 콜되는지를 판단하고 만일 상기 적어도 하나의 콜가능 메소드가 상기 콘텍스트에서 콜되면 상기 적어도 하나의 콜가능 메소드로부터 수행 데이터를 얻기 위해 상기 조건부의 인스트루먼테이션을 작동시키는 단계를 포함하는 것을 특징으로 하는 어플리케이션을 인스트루먼팅하는 방법.
2. 제 1항에 있어서,
   만일 상기 적어도 하나의 콜가능 메소드가 콜되지만은 상기 콘텍스트에서는 콜되지않으면, 상기 조건부의 인스트루먼테이션을 작동시키지 않는 단계를 더 포함하는 것을 특징으로 하는 어플리케이션을 인스트루먼팅하는 방법.
3. 제 1항 또는 2항에 있어서,
   상기 적어도 하나의 선택된 인스트루먼트 메소드가 실행을 시작 및 중지할때 상기 적어도 하나의 선택된 인스트루먼트 메소드를 스레드-로컬 캐쉬에 보고하여 상기 스레드-로컬 캐쉬가 상기 어플리케이션의 하나 이상의 실행 메소드들을 식별하도록, 상기 적어도 하나의 선택된 인스트루먼트 메소드의 인스트루먼테이션을 수정하는 단계를 더 포함하는 것을 특징으로 하는 어플리케이션을 인스트루먼팅하는 방법.
4. 제 3항에 있어서,
   상기 조건부의 인스트루먼테이션은 상기 콘텍스트를 충족하도록 실행됨이 요구되는, 적어도 하나의 선택된 인스트루먼트 메소드를 포함한 하나 이상의 메소드들을 식별하고; 그리고
   상기 적어도 하나의 콜가능 메소드가 상기 콘텍스트에서 콜되는지의 판단하는 것은 상기 조건부의 인스트루먼테이션이 상기 적어도 하나의 메소드들이 실행을 행하는지를 판단하기 위해 상기 스레드-로컬 캐쉬를 엑세스하는 것을 포함하는 것을 특징으로 하는 어플리케이션을 인스트루먼팅하는 방법.
5. 제 3항 또는 4항에 있어서,
   상기 조건부의 인스트루먼테이션은 상기 콘텍스트를 충족하도록 실행됨이 요구되는, 메소드들의 시퀀스를 식별하고, 상기 메소드들의 시퀀스는 상기 적어도 ㅎ하나의 선택된 인스트루먼트 메소드 및 상기 적어도 하나의 선택된 인스트루먼트된 메소드의 페어런트 메소드(parent method)를 포함하며; 그리고
   상기 적어도 하나의 콜가능 메소드가 상기 콘텍스트에서 콜되는지의 판단하는 것은 상기 조건부의 인스트루먼테이션이 상기 메소드들의 시퀀스가 실행을 행하는지를 판단하기 위해 상기 스레드-로컬 캐쉬를 엑세스 하는 것을 포함하는 것을 특징으로 하는 어플리케이션을 인스트루먼팅하는 방법.
6. 제 1항 내지 5항 중 어느 한 항에 있어서,
   조건부의 인스트루먼테이션을 갖는 상기 어플리케이션의 코드는 유저를 위한 트랜젝션을 수행하도록 실행되며, 상기 조건부의 인스트루먼테이션은 상기 어플리케이션이 특정 포탈, 유저의 지리적 위치, 페이먼트 모드 및 제품 선적 모드을 통해 엑세스되든지 간에 상기 콘텍스트를 만족시킴이 요구되는, 주문된 제품 유형, 제품 판매자의 신원, 구매를 하는 유저의 클래스 중 적어도 하나를 포함하는 특정 트랜젝션 데이터를 식별하는 것을 특징으로 하는 어플리케이션을 인스트루먼팅하는 방법.
7. 제 6항에 있어서,
   상기 특정 트랜젝션 데이터는 컴포넌트간 메시지의 헤더에 데이터 객체의 특정 값을 포함하는 것을 특징으로 하는 어플리케이션을 인스트루먼팅하는 방법.
8. 제 5항 내지 7항중 어느 한 항에 있어서,
   유저로 하여금 상기 메소드들의 시퀀스의 길이를 특정할 수 있게 하는 유저 인터페이스 디스플레이(250, 500)를 제공하는 단계를 더 포함하는 것을 특징으로 하는 어플리케이션을 인스트루먼팅하는 방법.
9. 제 1항 내지 8항 중 어느 한 항에 있어서,
   유저로 하여금 (a) 상기 적어도 하나의 콜가능 메소드에 대해 상기 조건부의 인스트루먼테이션을 제공하고 (b) 상기 적어도 하나의 콜가능 메소드에 대해 상기 조건부의 인스트루먼테이션을 제거하도록 하는 것 중 적어도 하나의 명령을 제공하도록 하는 유저 인터 페이스 디스플레이를 제공하는 단계를 더 포함하는 것을 특징으로 하는 어플리케이션을 인스트루먼팅하는 방법.
10. 제 1항 내지 9항 중 어느 한 항에 있어서,
    상기 인스트루먼트 메소드들을 포함하는 인스트루먼트 컴포넌트들의 베이스라인 세트로 상기 어플리케이션을 구성하는 것은 상기 어플리케이션의 코드를 가상 메신에 로드하고 상기 어플리케이션의 코드에 프로브들을 추가하는 것을 포함하며; 그리고
    상기 적어도 하나의 콜가능 메소드에 대한 조건부의 인스트루먼테이션으로 상기 어플리케이션의 코드를 구성하는 것은 사기 적어도 하나의 콜가능 메소드에 대한 상기 어플리케이션의 코드를 상기 가상 머시에 재로드하고, 상기 적어도 하나의 콜가능 메소드에 대해 상기 어플리케이션의 코드에 프로브들을 추가는 것을 포함하는 것을 특징으로 하는 어플리케이션을 인스트루먼팅하는 방법.
11. 제 1항 내지 10항 중 어느 한 항에 있어서,
    상기 가상 머신은 오퍼레이팅 시스템상에 구축되는 런타임 환경의 일부이며, 상기 오퍼레이팅 시스템은 하드웨어에 구축되는 것을 특징으로 하는 어플리케이션을 인스트루먼팅하는 방법.
12. 제 1항 내지 11항 중 어느 한 항에 있어서,
    상기 적어도 하나의 콜가능 메소드에 대한 조건부의 인스트루먼테이션으로 상기 어플리케이션의 코드를 구성하는 것은 조건부의 인스트루먼테이션을 포함하도록 상기 적어도 하나의 콜가능 메소드의 하나 이상의 클래스들을 재정의하고, 그리고 상기 하나 이상의 재정의된 클래스들을 상기 가상 머신에 로드하는 것을 특징으로 하는 어플리케이션을 인스트루먼팅하는 방법.
13. 제 1항 내지 12항 중 어느 한 항에 있어서,
    상기 인스트루먼트 메소드들의 수행 데이터는 상기 인스트루먼트 메소드들의 시작 및 정지 시간을 포함하고; 그리고
    상기 적어도 하나의 콜가능 메소드로부터의 수행 데이터는 상기 적어도 하나의 콜가능 메소드의 시작 및 정지 시간을 포함하는 것을 특징으로 하는 어플리케이션을 인스트루먼팅하는 방법.
14. 제 1항 내지 13항 중 어느 한 항에 있어서,
    상기 적어도 하나의 인스트루먼트 메소드 및 상기 적어도 하나의 콜가능 메소드의 수행 데이터를 나타내는 유저 인터페이스 디스플레이를 제공하는 단계를 더 포함하는 것을 특징으로 하는 어플리케이션을 인스트루먼팅하는 방법.
15. 어플리케이션을 인스트루먼팅하는 방법을 수행하도록 적어도 하나의 프로세서를 프로그래밍하는 컴퓨터 판독가능 소프트웨어가 수록된 컴퓨터 판독가능 저장 장치로서,
    상기 방법은:
    인스트루먼트 메소드들(C1-C7)을 포함하는 인스트루먼트 컴포넌트들의 베이스라인 세트로 상기 어플리케이션을 구성(configuring)하는 단계와, 상기 어플리케이션의 코드는 또한 언인스트루먼트 메소드들(C4A)를 포함하며;
    컴퓨터 시스템에서 상기 어플리케이션의 코드를 실행하는 동안, 상기 인스트루먼트 메소드들로부터 수행 데이터를 얻는 단계와;
    상기 수행 데이터에 근거하여, 세부적인 분석을 위해 상기 인스트루먼트 메소드들(C4A)중 적어도 하나를 선택하는 단계와;
    상기 선택에 근거하여, 상기 적어도 하나의 선택된 인스트먼트 메소드에 의해 콜(콜)될 수 있는 언인스트트먼트 메소드들중 적어도 하나의 콜가능 메소드(C5)를 결정하는 단계와;
    상기 결정에 응답하여, 상기 적어도 하나의 콜가능 메소드에 대한 조건부의 인스트루먼테이션으로 상기 어플리케이션의 코드를 구성하는 단계와, 여기서 상기 조건부의 인스트루먼테리션은 상기 적어도 하나의 콜가능 메소드가 콜될 때 상기 조건부의 인스트루먼테이션이 작동될 콘텍스트를 특정하고, 상기 콘텍스트는 상기 적어도 하나의 선택된 인스트루먼트 메소드에 의해 콜되는 상기 적어도 하나의 콜가능 메소드를 포함하며;
    상기 컴퓨터 시스템에서 상기 조건부의 인스트루먼테이션으로 상기 어플리케이션의 코드를 실행하는 동안, 상기 적어도 하나의 콜가능 메소드가 상기 콘텍스트에서 콜되는지를 판단하고 만일 상기 적어도 하나의 콜가능 메소드가 상기 콘텍스트에서 콜되면 상기 적어도 하나의 콜가능 메소드로부터 수행 데이터를 얻기위해 상기 조건부의 인스트루먼테이션을 작동시키는 단계를 포함하는 것을 특징으로 하는 컴퓨터 판독가능 저장 장치.
16. 컴퓨터 시스템으로서,
    소프트웨어 명령들을 저장하는 저장 장치와;
    상기 저장 장치로부터의 소프트웨어 명령들을 자신에 로드하는 작업 메모리와; 그리고
    상기 소프트웨어 명령들을 실행하는 프로세서를 포함하며,
    상기 소프트웨어 명령들은 실행시,
    인스트루먼트 메소드들(C1-C7)을 포함하는 인스트루먼트 컴포넌트들의 베이스라인 세트로 상기 어플리케이션을 구성(configuring)하고, 상기 어플리케이션의 코드는 또한 언인스트루먼트 메소드들(C4A)를 포함하며;
    컴퓨터 시스템에서 상기 어플리케이션의 코드를 실행하는 동안, 상기 인스트루먼트 메소드들로부터 수행 데이터를 얻고;
    상기 수행 데이터에 근거하여, 세부적인 분석을 위해 상기 인스트루먼트 메소드들(C4A)중 적어도 하나를 선택하고;
    상기 선택에 근거하여, 상기 적어도 하나의 선택된 인스트먼트 메소드에 의해 콜(콜)될 수 있는 언인스트트먼트 메소드들중 적어도 하나의 콜가능 메소드(C5)를 결정하고;
    상기 결정에 응답하여, 상기 적어도 하나의 콜가능 메소드에 대한 조건부의 인스트루먼테이션으로 상기 어플리케이션의 코드를 구성하고, 여기서 상기 조건부의 인스트루먼테리션은 상기 적어도 하나의 콜가능 메소드가 콜될때 상기 조건부의 인스트루먼테이션이 작동될 콘텍스트를 특정하고, 상기 콘텍스트는 상기 적어도 하나의 선택된 인스트루먼트 메소드에 의해 콜되는 상기 적어도 하나의 콜가능 메소드를 포함하며;
    상기 컴퓨터 시스템에서 상기 조건부의 인스트루먼테이션으로 상기 어플리케이션의 코드를 실행하는 동안, 상기 적어도 하나의 콜가능 메소드가 상기 콘텍스트에서 콜되는지를 판단하고 만일 상기 적어도 하나의 콜가능 메소드가 상기 콘텍스트에서 콜되면 상기 적어도 하나의 콜가능 메소드로부터 수행 데이터를 얻기위해 상기 조건부의 인스트루먼테이션을 작동시키는 것을 특징으로 하는 컴퓨터 시스템.

Images