特許 5798372 動的計測を介してのカスタムコードの診断を効率化するためのメソッド呼び出しの検出

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5798372

(24)【登録日】2015年8月28日

(45)【発行日】2015年10月21日

(54)【発明の名称】動的計測を介してのカスタムコードの診断を効率化するためのメソッド呼び出しの検出

(51)【国際特許分類】

   G06F 11/34 20060101AFI20151001BHJP

   G06F 9/44 20060101ALI20151001BHJP

【ＦＩ】

   G06F11/34 S

   G06F11/34 M

   G06F9/44 530P

【請求項の数】25

【外国語出願】

【全頁数】28

(21)【出願番号】特願2011-104689(P2011-104689)

(22)【出願日】2011年5月9日

(65)【公開番号】特開2011-238233(P2011-238233A)

(43)【公開日】2011年11月24日

【審査請求日】2014年3月4日

(31)【優先権主張番号】12/777496

(32)【優先日】2010年5月11日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】512212896

【氏名又は名称】シーエー，インク

【氏名又は名称原語表記】ＣＡ，Ｉｎｃ．

(74)【代理人】

【識別番号】110000110

【氏名又は名称】特許業務法人快友国際特許事務所

(72)【発明者】

【氏名】ガグリアルディ，マルコ

【審査官】 多賀 実

(56)【参考文献】

【文献】 特開２０１０−０３３５４３（ＪＰ，Ａ）

【文献】 特開２００４−２６４９１４（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００８／０２７６２２７（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ９／４４

Ｇ０６Ｆ１１／２８−１１／３６

(57)【特許請求の範囲】

【請求項1】

アプリケーションを解析するための方法であってコンピュータに実装される方法であり、コンピュータに実装される以下のステップ：
アプリケーションのコードをコンピュータシステムのメモリ（２４０）にロードするステップ；このロードするステップは、計測されたメソッド（Ｃ１−Ｃ６）を含んでいる計測されたコンポーネントのベースラインの規定によってアプリケーションのコードを構成することを含み、このアプリケーションのコードは未計測メソッド（Ｃ５Ａ）も含む；
メモリ内のアプリケーションのコードを実行している間に、計測されたメソッドからパフォーマンスデータを取得するステップ；
パフォーマンスデータに基づいて、さらに詳細に解析するために計測されたメソッド（Ｃ５）の少なくとも一つを選択するステップ；
前記選択に基づいて、前記少なくとも一つの選択された計測されたメソッドによって参照された未計測メソッドの一以上の参照メソッド（Ｃ５Ａ）を特定するステップ；当該一以上の参照メソッドを特定するステップは、
メモリ内にロードされたクラス群の中から、前記少なくとも一つの選択された計測されたメソッドのクラス（７２５）を決定するステップ；
リソースロケーション（７１５）からメモリへ前記クラスのバイトコード表現をロードするステップ；
呼び出しバイトコードの一以上のインスタンスを特定するために前記クラスのバイトコード表現を構文解析するステップ；および
前記呼び出しバイトコードの前記一以上のインスタンスに基づいて、前記一以上の参照メソッドを特定するステップ；を有し、
前記特定するステップに対応して、前記一以上の参照メソッドに対する前記アプリケーションのコードをメモリへロードするステップ；当該ロードするステップは、前記一以上の参照メソッドに対する前記アプリケーションの前記コードに計測手段を付加することを含む；
を備える方法。

【請求項2】

前記一以上の参照メソッドに対する前記アプリケーションの前記コードを実行している間に、前記一以上の参照メソッドの計測からパフォーマンスデータを取得する、
請求項１の方法。

【請求項3】

呼び出しバイトコードの前記一以上のインスタンスは、前記クラスのバイトコード表現における一以上の関連付けられたオペコード（７３５、７４０、７４５および７５０）から特定され；
一以上のオペコードは、定数プールテーブル（７５５）内の一以上のエントリへの一以上のインデックス(<indexbyte1, indexbyte2>)に関連付けられ；
前記一以上の参照メソッドは、前記一以上のインデックスを使用して特定される、
請求項２の方法。

【請求項4】

前記一以上の呼び出しバイトコードは、仮想呼び出し、特定呼び出し、静的呼び出し、および、インタフェース呼び出し、の中の一つ以上を含む、
請求項３の方法。

【請求項5】

前記クラスは、Java Instrument APIを使用して決定される、請求項４の方法。

【請求項6】

前記クラスの前記バイトコード表現の前記ロードするステップは、JavaクラスのClassLoader（７２０）を使用する、請求項５の方法。

【請求項7】

前記一以上の参照メソッドは、少なくとも一つのメソッドによって呼び出され得るメソッドであるが、前記一以上の参照メソッドを特定する時に前記一以上の参照メソッドが前記少なくとも一つの選択された計測されたメソッドによって呼び出されたかどうかは知られていない、請求項１から６のいずれか一項の方法。

【請求項8】

前記一以上の参照メソッドは、前記少なくとも一つの選択された計測されたメソッドの一以上の子の参照メソッドであり、
当該コンピュータに実装される方法は、
前記一以上の子の参照メソッドにより参照された未計測の一以上の孫の参照メソッドを特定することをさらに含み、前記一以上の孫の参照メソッドを特定することは：
前記一以上の子の参照メソッドのクラスを決定すること；
前記一以上の子の参照メソッドの前記クラスのバイトコード表現をリソースロケーションから前記メモリにロードすること；
前記一以上の子の参照メソッドの呼び出しバイトコードの一以上のインスタンスを特定するために、前記一以上の子の参照メソッドの前記クラスの前記バイトコード表現を構文解析すること；
前記一以上の子の参照メソッドの前記呼び出しバイトコードの前記一以上のインスタンスに基づいて、前記一以上の孫の参照メソッドを特定すること；および
前記一以上の孫の参照メソッドを文字列として格納すること、
を有する請求項１から７のいずれか一項の方法。

【請求項9】

前記一以上の未計測の参照メソッドを第１のアプリケーションサーバ（１０６）からセントラルマネージャ（１２０）へ報告すること、を含み、
当該セントラルマネージャは、第２アプリケーションサーバ（１１０）に対して前記一以上の未計測の参照メソッドの特定をプッシュし、前記第２アプリケーションサーバ（１１０）は、前記特定を使って前記アプリケーションの他のインスタンスを計測する、
ことをさらに有する請求項１から８のいずれか一項の方法。

【請求項10】

前記一以上の参照メソッドのために、前記一以上の参照メソッドに計測を付加するか否かの決定を助けるために情報を提供すること；ここで、前記情報は、前記アプリケーションの静的計測が一以上の参照メソッドが計測されるべきではないことを示しているか否かを示している；
をさらに有する請求項１から９のいずれか一項の方法。

【請求項11】

前記一以上の参照メソッドのために、前記一以上の参照メソッドに計測を付加するか否かの決定を助けるために情報を提供すること；ここで、前記情報は、前記一以上の参照メソッドが既に計測されたか否かを示している；
をさらに有する請求項１から１０のいずれか一項の方法。

【請求項12】

前記一以上の参照メソッドのために、前記一以上の参照メソッドに計測を付加するか否かの決定を助けるために情報を提供すること；ここで、前記情報は、前記一以上の参照メソッドがインスタンスを参照しているか否かを示している；
をさらに有する請求項１から１１のいずれか一項の方法。

【請求項13】

前記一以上の参照メソッドのために、前記一以上の参照メソッドに計測を付加するか否かの決定を助けるために、JAVA Reflection APIを用いた情報を提供すること；
をさらに有する請求項１から１１のいずれか一項の方法。

【請求項14】

アプリケーションを解析するための方法を実行するために、少なくとも一つのプロセッサをプログラムするために具現化されたソフトウェアであってコンピュータで読み取り可能なソフトウェアを有している有体のコンピュータで読み取り可能な記憶装置であり、当該方法は：
アプリケーションのコードをコンピュータシステムのメモリ（２４０）にロードすること；このロードすることは、計測されたメソッド（Ｃ１−Ｃ６）を含んでいる計測されたコンポーネントのベースラインの規定によってアプリケーションのコードを構成することを含み、このアプリケーションのコードは未計測メソッド（Ｃ５Ａ）も含む；
メモリ内のアプリケーションのコードを実行している間に、計測されたメソッドからパフォーマンスデータを取得すること；
パフォーマンスデータに基づいて、さらに詳細に解析するために計測されたメソッド（Ｃ５）の少なくとも一つを選択すること；
前記選択に基づいて、前記少なくとも一つの選択された計測されたメソッドによって参照された未計測メソッドの一以上の参照メソッド（Ｃ５Ａ）を特定すること；当該一以上の参照メソッドを特定することは、
メモリ内にロードされたクラス群の中から、前記少なくとも一つの選択された計測されたメソッドのクラス（７２５）を決定すること；
リソースロケーション（７１５）からメモリへ前記クラスのバイトコード表現をロードすること；
呼び出しバイトコードの一以上のインスタンスを特定するために前記クラスのバイトコード表現を構文解析すること；および
前記呼び出しバイトコードの前記一以上のインスタンスに基づいて、前記一以上の参照メソッドを特定すること；を有し、
前記特定することに対応して、前記一以上の参照メソッドに対する前記アプリケーションのコードをメモリへロードすること；当該ロードすることは、前記一以上の参照メソッドに対する前記アプリケーションの前記コードに計測手段を付加することを含む；
ことを特徴とするコンピュータで読み取り可能な記憶装置。

【請求項15】

前記一以上の参照メソッドに対する前記アプリケーションの前記コードを実行している間に、前記一以上の参照メソッドの計測からパフォーマンスデータを取得する、
請求項１４の記憶装置。

【請求項16】

呼び出しバイトコードの前記一以上のインスタンスは、前記クラスのバイトコード表現における一以上の関連付けられたオペコード（７３５、７４０、７４５および７５０）から特定され；
一以上のオペコードは、定数プールテーブル（７５５）内の一以上のエントリへの一以上のインデックス(<indexbyte1, indexbyte2>)に関連付けられ；
前記一以上の参照メソッドは、前記一以上のインデックスを使用して特定される、
請求項１４又は１５の記憶装置。

【請求項17】

前記一以上の呼び出しバイトコードは、仮想呼び出し、特定呼び出し、静的呼び出し、および、インタフェース呼び出し、の中の一つ以上を含む、
請求項１４から１６のいずれか一項の記憶装置。

【請求項18】

前記クラスは、Java Instrument APIを使用して決定される、請求項１４から１７のいずれか一項の記憶装置。

【請求項19】

前記クラスの前記バイトコード表現の前記ロードするステップは、JavaクラスのClassLoader（７２０）を使用する、請求項１４から１８のいずれか一項の記憶装置。

【請求項20】

ソフトウェア命令を格納する記憶装置；
前記記憶装置から前記ソフトウェア命令がロードされる作業メモリ；および
前記ソフトウェア命令を実行するためのプロセッサ；
を備えており、前記ソフトウェア命令は：
アプリケーションのコードをコンピュータシステムの作業メモリ（２４０）にロードし；このロードすることは、計測されたメソッド（Ｃ１−Ｃ６）を含んでいる計測されたコンポーネントのベースラインの規定によってアプリケーションのコードを構成することを含み、このアプリケーションのコードは未計測メソッド（Ｃ５Ａ）も含む；
作業メモリ内のアプリケーションのコードを実行している間に、計測されたメソッドからパフォーマンスデータを取得し；
パフォーマンスデータに基づいて、さらに詳細に解析するために計測されたメソッド（Ｃ５）の少なくとも一つを選択し；
前記選択に基づいて、前記少なくとも一つの選択された計測されたメソッドによって参照された未計測メソッドの一以上の参照メソッド（Ｃ５Ａ）を特定し；当該一以上の参照メソッドを特定する際に、当該ソフトウェア命令は、
メモリ内にロードされたクラス群の中から、前記少なくとも一つの選択された計測されたメソッドのクラス（７２５）を決定し；
リソースロケーション（７１５）から作業メモリへ前記クラスのバイトコード表現をロードし；
呼び出しバイトコードの一以上のインスタンスを特定するために前記クラスのバイトコード表現を構文解析し；および
前記呼び出しバイトコードの前記一以上のインスタンスに基づいて、前記一以上の参照メソッドを特定させることを有し、
前記特定することに対応して、前記一以上の参照メソッドに対する前記アプリケーションのコードを作業メモリへロードすること；当該ロードすることは、前記一以上の参照メソッドに対する前記アプリケーションの前記コードに計測手段を付加することを含む、
コンピュータシステム。

【請求項21】

前記ソフトウェア命令は、前記一以上の参照メソッドに対する前記アプリケーションの前記コードが実行されている間に、前記一以上の参照メソッドの計測からパフォーマンスデータを取得する、
請求項２０のコンピュータシステム。

【請求項22】

呼び出しバイトコードの前記一以上のインスタンスは、前記クラスのバイトコード表現における一以上の関連付けられたオペコード（７３５、７４０、７４５および７５０）から特定され；
一以上のオペコードは、定数プールテーブル（７５５）内の一以上のエントリへの一以上のインデックス(<indexbyte1, indexbyte2>)に関連付けられ；
前記一以上の参照メソッドは、前記一以上のインデックスを使用して特定される、
請求項２０又は２１のコンピュータシステム。

【請求項23】

前記一以上の呼び出しバイトコードは、仮想呼び出し、特定呼び出し、静的呼び出し、および、インタフェース呼び出し、の中の一つ以上を含む、請求項２０から２２のいずれか一項のコンピュータシステム。

【請求項24】

前記クラスは、Java Instrument APIを使用して決定される、請求項２０から２３のいずれか一項のコンピュータシステム。

【請求項25】

前記クラスの前記バイトコード表現の前記ロードするステップは、JavaクラスのClassLoader（７２０）を使用する、請求項２０から２４のいずれか一項のコンピュータシステム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、コンピューティング環境でソフトウェアを監視する技術に関する。

【背景技術】

【0002】

インターネットの存在が増長するにつれて、エクストラネット、イントラネットなどの他のコンピュータネットワークと同様に、電子商取引、教育、他の分野において多くの新しいアプリケーションをもたらした。組織は、ビジネスやその他目的を行うのにそのようなアプリケーションへの依存を深めており、期待通りの成果を確実に得るために相当の資源を投入している。このような状況のもと、様々なアプリケーションの管理技術が開発されている。

【0003】

一つのアプローチとして、アプリケーションで呼び出される個々のソフトウェアコンポーネントに関するアプリケーションの実行データを集めることにより、アプリケーションのインフラストラクチャー（基礎構造）を監視することが挙げられる。このアプローチでは、監視されるシステムに元来、存在するエージェントを用いることができる。例えば、ソフトウェアによるインスツルメンテーション（計測）を用いることによって、呼び出される個々のコンポーネントを特定するためや、個々のコンポーネントの実行時間のような実行データを得るために、スレッドまたはプロセスがトレースされ得る。コンピュータプログラムが実行するステップの詳細なレコード、またはトレースを得ることをトレーシングという。トレースの一種類にスタックトレースがある。トレースはデバッグにおける補助の役目を果たし得る。しかしながら、どのコンポーネントを計測するかを決定することが課題となり得る。アプローチが包括的であり過ぎると、過度にオーバーヘッドコストがかかる結果となり、アプリケーションの操作性が損なわれ得る一方で、アプローチが包括的ではなさ過ぎると、重要なパフォーマンスデータの欠落という結果に繋がるおそれがある。その結果、ソフトウェアの解析や診断が課題となり得る。

【発明の開示】

【発明が解決しようとする課題】

【0004】

本発明は、上記課題および他の課題を解決する解析ソフトウェアのための技術を提供する。

【課題を解決するための手段】

【0005】

一実施形態では、アプリケーションを解析するための方法であってコンピュータに実装される方法は、コンピュータに実装される以下のステップを含む。解析するためにアプリケーション内の少なくとも一つのメソッドを特定するステップ。メモリ内にロードされたクラス群の中から少なくとも一つのメソッドのクラスを決定するステップ。リソースロケーションからそのクラスのバイトコード表現をロードするステップ。呼び出しバイトコードの一以上のインスタンスを特定するためにそのクラスのバイトコード表現を構文解析するステップ。その呼び出しバイトコードの一以上のインスタンスに基づいて、一以上の参照されるメソッドを特定するステップ。この方法は、さらに、その一以上の参照されるメソッドを文字列として格納することを含む。

【0006】

別の実施形態では、アプリケーションを解析するための方法であってコンピュータに実装される方法は、以下を含む。第１のアプリケーションサーバにおいてアプリケーションの１番目のインスタンス内で解析するために、少なくとも一つの計測されたメソッドを特定すること。メモリ内にロードされたクラス群の中から、その少なくとも一つの計測されたメソッドのクラスを決定すること。リソースロケーションからそのクラスのバイトコード表現をロードすること。呼び出しバイトコードの一以上のインスタンスを特定するためにクラスのバイトコード表現を構文解析すること。呼び出しバイトコードの一以上のインスタンスに基づいて、一以上の未計測の参照されるメソッドを特定すること。この方法はさらに、第１のアプリケーションサーバからセントラルマネージャへその一以上の未計測の参照されるメソッドを報告することを含む。ここで、セントラルマネージャは、第２のアプリケーションサーバにおいて、そのアプリケーションの第２のインスタンスへ、上記一以上の未計測の参照されるメソッドの特定をプッシュする。

【0007】

他の実施形態では、アプリケーションの解析をするためのメソッドを実行するための少なくとも一つのプロセッサでプログラムするために具現化されてコンピュータ読み取り可能なソフトウェアを有している有体のコンピュータで読み取り可能な記憶装置を提供する。実行される方法は以下を含む。アプリケーション内のコンポーネントを計測すること。計測されたコンポーネントからパフォーマンスデータを取得すること。計測されたコンポーネント群の少なくとも一つのコンポーネントのパフォーマンスデータが閾値のパフォーマンスレベルを下回るか否かを判断すること。この判断に応じて、現在は未計測であって、少なくとも一つのコンポーネントによって呼び出し可能な一以上のコンポーネントを特定し計測するための処理を起動すること。

【0008】

対応する方法、システム、及び、コンピュータ若しくはプロセッサで読み取り可能な記憶装置であって本明細書が提示する方法を実現する命令を符号化している記憶媒体を含む記憶装置も提供される。

【図面の簡単な説明】

【0009】

【図1】管理されたアプリケーションを含むシステムを示す。

【図2】図１のネットワークのコンピュータシステムを示す。

【図3】実行パス内のコンポーネントの呼び出し関係を示す。

【図4A】図３の呼び出し関係に基づく１番目の呼び出しスタックの位置と時間のグラフを示す。

【図4B】コンポーネントＣ５Ａが特定され計測された場合における、図３の呼び出し関係に基づく２番目の呼び出しスタック位置と時間のグラフを示す。

【図4C】Java（登録商標）実行環境を示す。

【図5A】静的計測のための処理フローの例としてJavaベースのものを示す。

【図5B】静的計測のための処理フローの例として.NETベースのものを示す。

【図6】呼び出し可能なメソッドを特定することによるソフトウェアを解析するためのメソッドを示す。

【図7】図６のメソッドに関して使用され得るソフトウェアおよびハードウェアを示す。

【図8】ソフトウェアを計測するための処理フローの例を示す。

【図9】コンポーネント群とそれに対応したパフォーマンスデータ間の階層的関係を示すユーザインタフェース表示を示すもので、これにより、ユーザは、計測すべきコンポーネントを手動により特定することが可能となる。

【図10】図６のステップ６００の詳細を示す。

【図11】図６のステップ６４０の詳細を示す。

【図12】図６のステップ６４０の詳細を示す。

【図13】図１１のステップ１１２５の詳細を示す。

【図14】図６のステップ６４０の詳細を示す。

【発明を実施するための形態】

【0010】

本発明は、ソフトウェアの実行中に未計測のコンポーネントを発見して動的に計測し得る、ソフトウェアを解析する技術を提供する。最初に、アプリケーションのようなソフトウェアは、メソッドのような計測されたコンポーネントのベースラインの規定（セット）によって設定される。アプリケーションが動作すると、計測からパフォーマンスデータが集められ、いくつかのメソッドのパフォーマンスが期待値を下回っていること、あるいは問題があることがわかる。この問題を解析するため、問題の対象となっているメソッドから呼び出し可能な任意のメソッドを発見する技術が用いられ得る。ある特定の実装では、呼び出し可能なメソッドは、Java（登録商標）仮想マシン（ＪＶＭ）にロードされたクラスのバイトコードを検査することによって見つけ出される。そして、この発見されたメソッドを計測および／または報告する決定がされ得る。選択的に計測を付加することによって、初期の包括的過ぎる計測を必要とすることなく、パフォーマンス問題の深い診断をするために発見されたコンポーネントから追加のパフォーマンスデータを得ることが可能となる。このように、必要に応じて深い診断を行う能力を伴うことにより、効率的で軽い計測が達成される。

【0011】

図１は、異なったコンピュータシステムがマネージャにデータを提供するネットワークを示す。例示のコンピュータシステムは、アプリケーションサーバ１０６および１１０、または所望の機能を実現するためにコードを実行するプロセッサを有する他の任意の種類のコンピュータシステムをも含み得る。アプリケーションサーバ群は、異なったアプリケーションを実行し、または同じアプリケーションの別々のインスタンスを実行することができる。アプリケーションサーバ群は、互いに離れて位置することができ、または同じ場所に位置することもできる。この例では、アプリケーションサーバ１０６および１１０は、ローカルマネージャコンピュータ１２０と通信している。マネージャコンピュータ１２０は、あるいは、アプリケーションサーバ１０６および１１０から離れていてもよく、そのような場合にはこれらの間の通信はネットワーククラウド１０４を介して行われる。

【0012】

例えば、webベースの電子商取引アプリケーションのようなエンタープライズアプリケーションを運営する会社は、負荷分散のために多くのアプリケーションサーバを一つの場所で使用する。ユーザからのリクエストは、ユーザのWebブラウザ１０２の例のように、インターネットのようなネットワーククラウド１０４経由で受信され、アプリケーションサーバ１０６および１１０のいずれかに送られる。Webブラウザ１０２は、通常、図示していないインターネットサービスプロバイダーを介してネットワーククラウド１０４にアクセスする。アプリケーションサーバ１０６および１１０上で実行するエージェントソフトウェアは、エージェントＡ１（１０８）およびエージェントＡ２（１１２）とそれぞれ表示されるが、それぞれアプリケーションサーバ１０６および１１０上で実行され、ある可能なアプローチで、アプリケーション、ミドルウェア、またはその他のソフトウェアからの情報を集める。例えば、そのような情報は、計測を用いることによって得ることができ、その一例は、バイトコード計測である。しかしながら、集められたデータは他の方法でも得ることができる。エージェント群は、監視されるコンピュータシステムに本質的に存在し、データの取得ポイントを提供する。エージェント群は、マネージャ１２０と通信してデータを編成し最適化する。

【0013】

ソフトウエアの実行を監視するためのソフトウエア計測について様々なアプローチが知られている。例えば、最初に述べたように、トレーシングはソフトウェアの実行を追跡するために用いられる。トレーシングの例が、２００４年４月２２日に公開された、“Transaction Tracer”と題する米国特許出願公開No. 2004/0078691にて述べられており、それは参照により本明細書に組み込まれる。そこで述べられている一つのアプローチでは、監視されるべきアプリケーションのオブジェクトコードまたはバイトコードは、プローブにより計測、例えば変更、される。アプリケーションのジョブまたは他のロジックを変更することなくアプリケーションに関する特定の情報をそのプローブが測定する。一旦、そのプローブがアプリケーションのバイトコードにインストールされると、それは管理されたアプリケーションと呼ばれる。エージェントソフトウェアは、当該プローブからのパフォーマンスデータのような情報を受信し、その情報を、例えばマネージャ１２０において、別の処理へ通信する。エージェントソフトウエアは、あるいは、その情報が異常状況を示すか否かを判断するなど、情報を局所的に処理する。例えば、当該プローブからの情報は、トランザクションまたは他の実行フローの開始や停止の回数、またはトランザクション／実行フロー内の個々のコンポーネントの開始や停止の回数などのパフォーマンスデータを示す。この情報は、それが範囲内にあるかどうかを決定するために予め決められた基準と比較される。もし情報が範囲内にない場合には、エージェントは適切なトラブルシューティングが実行できるようにこの事実をマネージャに報告する。エージェント１０８、１１２および１１６は、それぞれが関連付けられているローカルアプリケーションサーバー１０６、１１０上でソフトウェアが実行中であるであることを通常認識している。

【0014】

マネージャ１２０は、ワークステーションなどの別のコンピュータシステムに備えられ、モニターのようなユーザインタフェース１２２と通信し、エージェントから受信したデータに基づいた情報を表示する。図４Ａ−Ｃおよび図９の表示の例を参照されたい。マネージャは、また、データベース１１８にアクセスすることができ、エージェントから受信したデータを格納する。提示された例では、アプリケーションサーバは、ネットワーククラウド１０４にアクセスすることなく、マネージャ１２０と通信することができる。例えば、通信は、ローカルエリアネットワークを介して行われる。他の設計では、マネージャ１２０は、ネットワーククラウド１０４を介して複数のアプリケーションサーバのエージェントからデータを受信することが可能となる。例えば、大きな組織は、セントラルネットワークオペレーションセンターを採用し、そこでは、一つまたはそれ以上のマネージャが、地理的に異なる場所に分散している複数のエージェントからデータを取得する。説明すると、Webベースの電子商取引企業では、顧客の注文を受ける地理的に異なる場所にあるサーバからエージェントのデータを取得する可能性がある。そのサーバは、支払いを処理するサーバ、倉庫で在庫を調べたり、受注を受けたりするサーバなどである。マネージャ１２０およびユーザインタフェースディスプレィ１２２は、企業の本社の場所に備えられることがある。必ずしもWebベースまたは小売、若しくはその他の販売に関するものでなくともよい他のアプリケーションにおいて同様にシステムを管理するためにエージェントとマネージャを採用することができる。例えば、銀行では、小切手の処理やクレジットの口座用にアプリケーションを使用することがある。また、上述した複数のコンピュータシステム装置に加えて、一つまたはそれ以上のエージェントによって単一のコンピュータシステムを同様に監視することができる。

【0015】

図２は、図１のネットワークのコンピュータシステムを示す。コンピュータシステム２００は、図１に関して説明したように、Webブラウザ１０２、ホスト（アプリケーションサーバ１０６および１１０など）、セントラルマネージャ１２０および／またはユーザインタフェース１２２として使われているシステムを簡略化して表したものである。コンピュータシステム２００は、ハードディスクまたはポータブルメディアのような記憶装置２１０、他のコンピュータシステムと通信するためのネットワークインタフェース２２０、ソフトウェアの命令を実行するためのプロセッサ２３０、例えば、記憶装置２１０からロードされた後にソフトウェアの命令を格納するためのＲＡＭのような作業メモリ２４０、および、ユーザインタフェースディスプレィ２５０を含む。記憶装置２１０は、ここで説明する機能を提供するためのメソッドを実行するようにプロセッサ２３０をプログラムするために具体化されているプロセッサの読み取り可能なコードを有する、プロセッサにより読み取り可能な記憶装置と考えることができる。ユーザインタフェースディスプレィ２５０は、一つまたはそれ以上のエージェントから受信したデータに基づいて、人間のオペレータに情報を提供することが可能である。ユーザインタフェースディスプレィ２５０は、グラフィカルまたは表形式のような既知の任意の表示方式を使用することができる。画面上の表示に加え、プリンタからのハードコピーなどの出力も提供することができる。

【0016】

また、本明細書で説明する機能は、ハードウェア、ソフトウェアまたはハードウェアとソフトウェアの両方の組み合わせを使用して実装されてもよい。ソフトウェアについては、一つまたはそれ以上のプロセッサをプログラムするために具体化されているプロセッサの読み取り可能なコードを有する、一つまたはそれ以上のプロセッサにより読み取り可能な有体の記憶装置を使用することができる。プロセッサにより読み取り可能な有体の記憶装置は、揮発性および不揮発性媒体、リムーバブルおよび非リムーバブルメディアなどのコンピュータ読み取り可能な媒体を含むことが可能である。例えば、コンピュータにより読み取り可能な有体の媒体には、コンピュータにより読み取り可能な命令、データ構造やプログラムモジュールまたは他のデータといった情報を記憶するために、任意の方法や技術でインプリメントされた揮発性、不揮発性、リムーバブル、非リムーバブルの媒体が含まれ得る。コンピュータにより読み取り可能な有体の媒体の例としては、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリ技術、ＣＤ−ＲＯＭ、デジタルバーサタイルディスク（ＤＶＤ）、または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、他の磁気記憶装置、または所望の情報を格納したり、コンピュータによってアクセスしたりすることに用いられる他の媒体などがある。他の実施形態においては、一部またはすべてのソフトウェアは、カスタムＩＣ、ゲートアレイ、ＦＰＧＡ、ＰＬＤや特殊用途向けプロセッサなど、専用のハードウェアに置き換えることができる。一実施形態では、一つまたはそれ以上の実施形態を実装するソフトウェア（記憶装置に格納されている）は、一つまたはそれ以上のプロセッサをプログラムするために用いられる。一つまたはそれ以上のプロセッサは、一つまたはそれ以上のコンピュータにより読み取り可能な有体の媒体／記憶装置、周辺機器、および／または通信インタフェースと通信することができる。

【0017】

図３は、実行パス内のコンポーネントの呼び出し関係を示す。図１のアプリケーションサーバ１０６、または１１０などのアプリケーションサーバ上で実行され得るアプリケーション内のコンポーネントが示されている。ここで提供されるコンポーネントのシーケンスは、実行パスの一つの可能なタイプの例である。呼び出される各コンポーネントは、実行パスの一部と考えられる。アプリケーションが計測されるときには、通常、このアプリケーションの開発者の理解や着目する対象となるであろうコンポーネントの選択に基づいて、選択されたコンポーネントのみが計測されることに留意されたい。このように、少なくとも最初は着目すべきとみなされていない多くのコンポーネントはアプリケーション内で呼び出され得るが、実行パスの中には含まれない。

【0018】

コンポーネント指向のプログラムモジュールは、コンポーネントと呼ばれる構成要素からアプリケーションや他のプログラムをプログラマに組ませるのに役に立つ。各コンポーネントは、ソフトウェアの全体的機能に適合するよう特定の機能を実行することができる。さらに、コンポーネントは、他のコンポーネントを呼び出し、また、再帰呼び出しによって自分自身を呼び出し、コンポーネントのシーケンスがプログラム内に呼び出される。コンポーネントは、消費されるコンピュータシステム内のリソースの例、或いは、プログラムの実行時に実行される作業（work）の例である。コンポーネント指向のプログラミングモデルの一例は、Ｊ２ＥＥであり、それはJava Server Page、Enterprise Java Bean、サーブレットおよびJava Database Connectivityコンポーネントといったコンポーネントを用いることができる。しかしながら、その他のコンポーネント指向のプログラミングモデルが使用されてもよく、例えば、マイクロソフト社の.NETコンポーネントが使用される。さらに、プログラミングモデルはオブジェクト指向である必要はない。一つのアプローチでは、コンポーネントはメソッドであると考えられている。

【0019】

ここで示されている特定の例は、ユーザがアイテムを注文するWebベースの電子商取引のアプリケーションを示している。コンポーネントは、アプリケーション内のビジネスロジックまたは電子商取引の手順に対応する。具体的には、コンポーネントＣ１ ３１２では、ユーザがアイテムを選び、購入し、クレジットカードの種類やクレジットカード番号といった支払い方法の情報、アイテムを発送する住所といった発送情報、陸送または翌朝配達の航空発送といった発送方法の情報を入力する、ショッピングカートを提供している。Ｃ１ ３１２は、コンポーネントＣ１Ａ ３１４を呼び出し、選択されたアイテムがストックにあるかどうかを決定するために在庫を調べる。一旦、選択されたアイテムがストックにあることが決定されると、Ｃ１ ３１２は、コンポーネントＣ２ ３２２を呼び出し、そこでトランザクションが保留にされている間、アイテムを予約し、そのアイテムが他のユーザに販売されないようにする。一旦、終了すると、Ｃ２ ３２２がコンポーネントＣ３ ３２４を呼び出し、そこでユーザのクレジットカード情報を調べ、購入の承認と認証が行われる。これは、通常、クレジットカード情報センターにより管理されている外部サーバと通信することを伴う。例えば、Ｃ３ ３２４は、クレジットカードサービスにコンタクトするコンポーネントＣ３Ａ ３２６を呼び出し得る。

【0020】

一旦、Ｃ３ ３２４が正常に終了すると、購入が承認され、コンポーネントＣ４ ３３０が呼び出され、購入されたアイテムの数量を減少させることによって在庫を調整する。Ｃ４ ３３０はコンポーネントＣ３ ３４２を呼び出し、これにより、出荷ラベルがプリントされたり、オペレータがアイテムを手作業で置いたり梱包したりすることが求められる場所である、例えば、倉庫にコンタクトをし、出荷されるアイテムの手配が行われる。例えば、Ｃ５ ３４２は、コンポーネントＣ５Ａ ３４４を呼び出すことができ倉庫Ａにコンタクトし、および／またはコンポーネントＣ５Ｂ ３４６を呼び出して倉庫Ｂにコンタクトする。

【0021】

一旦、コンポーネントＣ２−Ｃ５が実行されると、実行パスはＣ１ ３１２に戻り、発注完了コンポーネントＣ６ ３１６を呼び出し、例えば確認の電子メールまたはWebページで発注確認番号および追跡番号等を提供してユーザに購入を確認する。もし、Ｃ１Ａ ３１４で倉庫が在庫切れであったり、Ｃ３ ３２４でクレジットカード払いが失敗したりした場合には、実行パスは同様にＣ１ ３１２に戻る。可能性のある実装としては、Ｃ１およびＣ６はJava Server Pagesであり、Ｃ２−Ｃ５はEnterprise JavaBeansである。

【0022】

１番目のコンポーネントは、非同期モードでマルチスレッドまたはマルチプロセスモードの実行を開始する別のコンポーネントを呼び出した後、実行を継続することができ、またはこの呼び出されたコンポーネントが同期モードでシングルスレッドまたはシングルプロセスモードの実行を終了するまで、このコンポーネントを一時的に休止することができる、ことに留意されたい。例えば、Ｃ２−Ｃ５のコンポーネントが実行している間、Ｃ１ ３１２は休止する。さらに、任意のコンポーネントは、トランザクションにおいて１回以上呼び出されることが可能である。例えば、異なる倉庫に保管されている複数のアイテムをユーザが購入すると仮定する。この場合、Ｃ５ ３４２は繰り返し実行されることがあり、異なる倉庫および／または各アイテム用の異なる倉庫部門にコンタクトする。

【0023】

図４Ａは、図３の呼び出し関係に基づく１番目の呼び出しスタックの位置に対する時間のグラフを示す。時間の増分は、必ずしも等間隔ではない。この表現は、トランザクションのトレースであり、一つまたはそれ以上のホストによって提供される実行パス情報の種類の一例である。これは、ユーザインタフェース上で報告として提供されグラフィカルに表示し得るもので、例えばメソッドのようなコンポーネントの実行時間といった形式でパフォーマンスデータを表現したものである。実行パス情報では、アプリケーションのどのメソッドが呼び出されるか、および、呼び出された時間についても特定することができる。水平方向は時間を表し、垂直方向は呼び出しスタックの深さや位置を表す。呼び出しスタックは、一つまたはそれ以上のプログラムまたはスレッドの実行中に呼び出される或いは起動されるメソッドを特定する。実行パスは、通常、１秒から数秒程度に亘るものである。

【0024】

例えば、実行パスはシーケンス：Ｃ１（４１２）、Ｃ１Ａ（４１４）、Ｃ１（４１２）、Ｃ２（４２２）、Ｃ３（４２４）、Ｃ３Ａ（４２６）、Ｃ３（４２４）、Ｃ４（４３０）、Ｃ５（４４２）、Ｃ４（４３０）、Ｃ３（４２４）、Ｃ２（４２２）、Ｃ１（４１２）、Ｃ６（４１６）およびＣ１（４１２）を含む。ホストは、クライアントからのリクエストを受信して、Ｃ１がｔ１において実行を開始したことに気づく。このシーケンス内における各移行は、計測に基づいてエージェントによって把握される。Ｃ１がｔ２においてＣ１Ａを呼び出す。Ｃ１Ａがｔ４において実行を完了する。Ｃ１がｔ５においてＣ２を呼び出す。Ｃ２がｔ６においてＣ３を呼び出す。Ｃ３がｔ７においてＣ３Ａを呼び出す。Ｃ３Ａがｔ９において実行を完了する。Ｃ３がｔ１０においてＣ４を呼び出す。Ｃ４がｔ１１においてＣ５を呼び出す。Ｃ５がｔ１６において実行を完了する。Ｃ４がｔ１７において実行を完了する。ｔ１８において、Ｃ３が実行を完了する。Ｃ２がｔ１９において実行を完了する。Ｃ１がｔ２０においてＣ６を呼び出す。Ｃ６がｔ２４において実行を完了する。Ｃ１がｔ２５において実行を完了するとき、ホストがクライアントにレスポンスを出す。ホストは、定期的にセントラルマネージャに時間とトランザクションデータを報告する。

【0025】

図４Ｂは、コンポーネントＣ５Ａが特定され計測された場合における図３の呼び出し関係に基づく２番目の呼び出しスタック位置に対する時間のグラフを示す。例として、ｔ１６−ｔ１１である、Ｃ５（４４２）の応答時間が長すぎて閾値レベルを超えることを、応答時間などのパフォーマンスデータが示すと仮定する。この場合、Ｃ５によって呼び出される可能性のあるメソッドに関して知らされる情報はない。この例では、ここに記載されている技術は、コンポーネント／メソッドのＣ５Ａ（４４４）がＣ５から呼び出されることを見つけ出すために用いられる。呼び出し可能なコンポーネントは、必ずではないが、別のコンポーネントから呼び出される可能性がある。Ｃ５によって直接呼び出されるメソッドは子メソッドであると見なされる。一方、Ｃ５の子メソッドによって呼び出されるメソッドはＣ５の孫メソッドであると見なされる。以降も同様である。一旦、呼び出し可能なメソッドが特定されると、それからパフォーマンスデータを取得するために計測される。しかし、このような計測は、呼び出し可能なメソッドとして要求されるものではなく、他の手段によって解析したものも報告され得る。

【0026】

この場合、Ｃ５Ａは、見つけ出された後に計測され、アプリケーションは実行を継続し、新しいパフォーマンスデータが集められる。図４Ｂの呼び出しスタック位置に対する時間のグラフは、単に図４Ａと同じであると見ることもできるが、それは異なるメソッド呼び出しインスタンスを表しており、図４Ａでの時間ｔ１−ｔ２５の後に図４Ｂの時間ｔ１−ｔ２５が発生している。このグラフは、Ｃ５Ａの応答時間がｔ１５−ｔ１２であるように、Ｃ５がｔ１２においてＣ５Ａ（４４４）を呼び出し、Ｃ５Ａはｔ１５まで実行することを示している。このことは、アプリケーションを診断したり解析したりするのに重要な助けを提供する。例えば、それは、Ｃ５Ａが過剰な実行時間の原因であると結論づけられる可能性がある。このメソッドの発見処理は、Ｃ５ＢがＣ５から呼び出し可能であることもまた判定する。図４Ｂの例では、Ｃ５Ｂは、それに付加される計測を有すると仮定することができる。しかしながら、この例では呼び出されなかったのであるから、Ｃ５Ｂは過剰な実行時間の原因ではないと結論づけられる可能性がある。これは、他では入手し得ないであろう重要な診断情報である。

【0027】

図４Ｃは、Java実行環境を示している。Java実行環境４８４は、ハードウェア４８０の上に構築されているオペレーティングシステム４８２上に構築されている。Java実行環境は、Java ＡＰＩクラス４８６とＪＶＭ４８８を含むいくつかの仮想部品を含む。ＪＶＭは、レジスタ４９０、オペランドスタック４９２、ヒープ４９４およびメソッド領域４９６を含む。ＪＶＭは、命令のシーケンスとして一連のバイトコードを処理する。ＪＶＭの命令は、実行すべきオペレーションを特定するオペコードからなり、そのオペレーションにおいて操作されるべき値を具現化するゼロ又はそれ以上のオペランドを伴う。オペランドスタック４９２、ヒープ４９４およびメソッド領域４９６は、指定可能なメモリ内にある。アドレスのサイズは３２ビットで、各メモリロケーションは１バイトを含み、各レジスタは一つの３２ビットアドレスを格納する。メソッド領域４９６は、バイトコードを含んでバイトバウンダリに配置され、オペランドスタック４９２とヒープ４９４は、ワード（３２ビット）バウンダリに配置される。

【0028】

レジスタ４９０は、メモリ内で実行すべき命令を追跡するプログラムカウンタ（ＰＣ）を含む。プログラムカウンタは、実行すべき次のバイトコードを特定する。フレームレジスタは、オペランドスタック内のカレントメソッドの実行環境に対するポインタを含む。オペランドトップ（optop）レジスタは、オペランドスタックの先頭へのポインタを含み、算術式を評価するのに用いられる。変数（vars）レジスタは、局所変数へのポインタを含む。

【0029】

オペランドスタック４９２は、メソッドと操作へパラメータを供給し、それらから結果を得る。すべてのバイトコード命令は、スタックからオペランドを取得してそれらの上で操作して、スタックに結果を戻す。オペランドスタックは、実行中のメソッドのスタックフレームを含む。スタックフレームは、例えば、局所変数、計算の中間結果など、メソッドの特定呼び出しのために、状態を保持する。具体的には、各ＪＶＭスレッドは、同時にスレッドとして生成された、専用のＪＶＭスタックを有している。ＪＶＭスタックは、フレームを格納し、局所変数と部分的な結果を保持し、メソッド呼び出しと戻り値の役割を果たす。このようにフレームは、動的リンキングを実行し、メソッドのための値を戻したり、例外処理をディスパッチするために使用されると同様に、データおよび部分的な結果を格納するため使用される。新しいフレームは、メソッドが呼び出されるたびに生成される。フレームは、メソッドの呼び出しが終了すると、その完了が正常か中断（受け取れない例外処理をスローした）かにかかわらず、破棄される。フレームは、フレームを生成するスレッドのＪＶＭスタックから割り当てられる。各フレームは、局所変数の独自の配列、独自のオペランドスタック、および、カレントメソッドのクラスの実行時定数プールへの参照（リファレンス）を持っている。

【0030】

ヒープ４９４またはメモリ割り当てプールは、ガーベジコレクトされる。ヒープは、すべてのクラスのインスタンスに対するメモリと配列がそこから割り当てられる実行時データ領域である。ヒープは、起動した仮想マシン上に生成され、オブジェクトのためのヒープ記憶域は、ガーベジコレクタとして知られている自動記憶装置管理システムにより再生される。具体的には、Java実行環境で実行中の各プログラムが、それに割り当てられたガーベジコレクトされたヒープを持っている。また、ヒープ内の各クラスには、それに関連付けられた定数プールがある。定数は変更することはないから、通常、コンパイル時に生成される。定数プール内のアイテムは、特定のクラス内の任意のメソッドで使用されるすべての名前をエンコードする。クラスは、いくつの定数が存在するかのカウントを含み、クラスの記述内における定数の特定リストの始点を特定するオフセットを含む。

【0031】

メソッド領域４９６は、コンパイルされたコード内でメソッドと関連付けられたバイトコード命令、および、動的リンクのために実行環境が必要とするシンボルテーブルを格納する。メソッドと関連付けられる必要があるデバッグや付加的情報も、またこの領域内に格納される。プログラムカウンタは、常にメソッド領域の数バイトを示し、その数バイトには、例えば、メソッド領域のアドレスが含まれる。プログラムカウンタは、スレッドの実行を追跡するために使用される。バイトコード命令が実行された後、プログラムカウンタは、次に実行する命令のアドレスを保持する。

【0032】

メソッド領域４９６は、すべてのＪＶＭスレッド間で共有され、実行時定数プール、フィールドおよびメソッドデータ、および、メソッドやコンストラクタのためのコードのようなクラスごとの構造体などを格納している。そのようなメソッドは、クラスおよびインスタンスの初期化やインタフェースタイプの初期化で使用される特別のメソッドを含む。メソッド領域は、起動した仮想マシン上に生成される。実行時定数プールは、クラスファイル内の定数プールテーブルの実行時間をクラスごとに、またはインタフェースごとに、表現したものである。これには、コンパイル時に知られている数値リテラルから実行時に解決されるべきメソッドやフィールドリファレンスに至るまでの範囲で、いくつかの種類の定数が含まれる。各実行時定数プールは、ＪＶＭのメソッド領域から割り当てられる。クラスまたはインタフェースの実行時定数プールは、ＪＶＭによってクラスまたはインタフェースが生成されるときに構築される。

【0033】

図５Ａは、静的計測のための処理フローの例としてJavaベースのものを示す。この処理は、一つの可能性のあるアプローチにおいては、例えば、図１のエージェント１０８または１１２のようなエージェント５００によって実装され得る。計測に対する一つのアプローチは、メソッドのような、どのコンポーネントを計測するべきかを決める静的なルールを提供することを含む。ルールは、コンポーネントがアプリケーションにロードされる時にアクセスされる。そのようなアプローチでは、クラスローダ５２０は、トランスフォーマ５１５にアプリケーションのバイトコードの生のデータバイトを提供するのに使用され、例えば、生のデータバイトをクラスに変換する。例えば、Javaでは、これは、クラスのロードに関与するClassLoaderオブジェクトのdefineClassメソッドを使用する可能性がある。ClassLoaderクラスは、抽象クラスである。クラスの名前を付与すると、クラスローダは、クラスの定義を構成するデータを配置したり生成したりしようとする。代表的な手順は、名前をファイル名に変換し、ファイルシステムからその名前の「クラスファイル」を読み込むことである。defineClassメソッドは、バイトの配列をClassクラスのインスタンスに変換する。Classクラスのインスタンスは、Javaアプリケーションを実行中にクラスおよびインタフェースを表す。トランスフォーマ５１５は、したがって、例えばクラスを変換することによって、計測を付加するためにバイトコードを変換することができるソフトウェアである。一つのアプローチでは、トランスフォーマ５１５の最小処理単位をクラスファイルおよびそのバイト配列とすることができる。

【0034】

アプリケーションのバイトコードが、判断ブロック５１０においてルール（指令）５０５に一致する場合、トランスフォーマ５１５はトレーサーバイトコードの形式でプローブを付加する。アプリケーションのバイトコードが、判断ブロック５１０においてルール５０５に一致しない場合、トランスフォーマ５１５はバイトコードに計測を付加しない。トランスフォーマ５１５と判断ブロック５１０は、プローブビルダ５２５の一部と考えることができる。

【0035】

この実装では、ルール５０５は、計測されるべき管理されたアプリケーションの一部を特定する代表的な静的ルールの規定である。ルールは、通常、最初に仮想マシン内でクラスが定義されるときに実装される。クラスは、たった一度の定義で複数回ロードすることができる。例えば、同じクラスをロードする複数のクラスローダが存在し得る。また、クラスなどのコンポーネントは、特定の方法で名前付けられるかどうか、特定のインタフェースを実装するかどうか、特定のサブクラスまたはスーパークラスを拡張するかどうか、等々に基づいて、計測され得る。そのようなコンポーネントは、有用な、あるいは着目するパフォーマンスデータを提供する可能性があると考えられるので、計測すべきものとして選択される。

【0036】

例えば、ルールは、少なくともいくつかのサーブレットは着目するデータを提供し得ると考えられているので、すべてのサーブレットが計測されるべきであることを示すことがある。この場合、ルール５０５が、JavaクラスのHttpServletのサブクラスであるすべてのコンポーネントを計測すべきであることを示す。HttpServletは、すべてのサーブレットが依存する抽象クラスである。しかしながら、すべてのコンポーネントが計測されるわけではなく、包括的過ぎる計測は過度にオーバーヘッドコストがかかる結果となり、アプリケーションの操作性が損なわれる可能性があるというおそれがある。その一方で、包括的でなさ過ぎる計測は、重要なパフォーマンスデータの欠落という結果に繋がるおそれがある。

【0037】

図５Ｂは、静的計測のための処理フローの例として.NETベースのものを示す。別の可能性のあるアプローチでは、管理されたアプリケーションのコンポーネントは、マイクロソフト社の「.NET」フレームワークにより提供される。Javaとは異なり.NETフレームワークはクラスローダを使用しない。代わりに、.NETは、フレームワーク用に特別に書かれたプログラムの実行を管理する仮想マシンを含む。.NETフレームワークの実行環境は、共通言語ランタイム（ＣＬＲ）として知られている。ＣＬＲは、プログラムを実行する特定のＣＰＵの能力をプログラマが考慮する必要がないように、アプリケーションの仮想マシンの外観を呈している。ＣＬＲは、セキュリティ、メモリ管理および例外処理などの他のサービスの提供もしている。予めコード化されたソリューションのクラスライブラリとＣＬＲは、共に.NETフレームワークを構成している。

【0038】

さらに、ＣＬＲは、アプリケーションの開発および実行のための言語に中立的なプラットフォームを提供する共通言語基盤（ＣＬＩ）の実装であり、例外処理、ガーベッジコレクション、セキュリティおよび相互運用のための各機能を果たしている。ＣＬＩは、コアクラスライブラリィ、コモンタイプシステムおよび共通中間言語（ＣＩＬ）を含む。Javaバイトコードと同様に、ＣＩＬは中間バイトコードの他の例である。Javaと.NETは、実装の一例にすぎず、他の実装もまた可能である。

【0039】

ここでは、一つの可能なアプローチとして、処理がエージェント５５０によって実装される。一つの可能性のある状況では、.NETフレームワーク内では、名前によってクラスを参照し、ＣＬＲ５７０がクラスを発見し、トランスフォーマ５６５（もしあれば）にそれを示し、その結果ＣＩＬを使用するという処理が行われる。特に、判定ブロック５６０でクラスがルール５５５に一致する場合、計測が付加される。判断ブロック５６０でクラスがルール５５５に一致しない場合は、計測は付加されない。トランスフォーマ５６５と判断ブロック５６０は、プローブビルダ５７５の一部であると考えることができる。

【0040】

図６は、呼び出し可能なメソッドを特定することによりソフトウェアを解析するためのメソッドを示す。上述したように、過度のオーバーヘッドを避けるために計測の量を制限しなければならず、そのため、アプリケーションの動作を把握する能力が制限される。時として、アプリケーションを診断しようとしてソースコードが利用可能であればソースコードは見直される可能性があるが、ソースコードは、通常、利用可能ではなく、殆どのユーザに容易には理解され得ない。その結果、ユーザは、アプリケーションを診断するための関連情報を得るため、いずれの付加されたメソッドを計測すべきかわからない。代わりに、現在は計測されておらずそれゆえ気付かれないであろう呼び出し可能なメソッドを選択的に発見することによって、アプリケーションのより深い理解と診断が可能となる。これらの付加メソッドは、診断のセッション中に計測され、その後、この計測は削除され得る。ここで提供される技術もまた、カスタムソフトウェアに計測を付加するのに有用ではあるが、標準的な計測パッケージは、計測するのが望ましいコードの一部を見落とす可能性がある。エージェントは、特定のメソッドまたは一連のメソッドによって呼び出され得るコードの一部をオンデマンドで発見するために技術を使用することができる。バイトコード解析が実装例で使用される。

【0041】

ステップ６００は、アプリケーションにおける解析するための少なくとも一つのメソッドを特定することを含む。詳細は、図１０に記載されている。これは、図５Ａおよび５Ｂに関して記載した通り、コンポーネントがアプリケーション内にロードされる際、メソッドのようなどのコンポーネントを計測するべきかを決める静的なルールに基づくなどして、すでに計測された少なくとも一つのメソッドとなり得る。別のアプローチでは、アプリケーションにロードされた後に少なくとも一つのメソッドが計測され得る。この少なくとも一つのメソッドは、パフォーマンスデータに基づいて特定され、例えば、その少なくとも一つのメソッドのパフォーマンの問題を示す。この特定は、パフォーマンスデータを継続的に監視することによって達成され、例えば、ユーザインタフェース上に報告をユーザに提供する。例えば、図９を参照されたい。プリセット範囲との比較に基づいて、範囲外のパフォーマンスデータには自動的にフラグが設定される。ユーザは、次に、計測するために一つまたはそれ以上のメソッドを手動により選択することができる。他の可能なアプローチでは、処理は完全に自動化されており、ユーザの介入を必要とせず、それゆえ、特定されたメソッドは自動的に計測される。ステップ６０５は、少なくとも一つのメソッドのメソッド呼び出しが存在しているかどうかを決定するためにキャッシュを調べることを含む。キャッシュは、例えば、アプリケーションが実行中のアプリケーションサーバのエージェントの仮想マシン内に存在し得る。

【0042】

一般的に、キャッシュは実行性能のために提供され得る。アプリケーションが実行を開始するとき、キャッシュは空である。ステップ６００内で特定される少なくとも一つのメソッドがdoSomething()メソッドと呼ばれると仮定する。呼び出し可能なメソッドを検索する処理を開始する。最初にすることは、キャッシュの中を見ることである。判断ステップ６１０で、呼び出し可能なメソッドがキャッシュにないときには、ステップ６１５から６３５が呼び出し可能なメソッドを特定するために実行され、キャッシュに格納される。ステップ６３５は、doSomething()のために検索されるメソッド呼び出しを、以下の疑似コードを使用してキャッシュする: cache.put([{クラスのclassLoader}; {doSomething()メソッドが定義されているクラス};doSomething()], [呼び出し可能なメソッド1, 呼び出し可能なメソッド 2 ....]); ここで、 ([{クラスのclassLoader}; {doSomething()メソッドが定義されているクラス};doSomething()] は、明確にdoSomething()メソッドを明確に特定するためのキーであり、呼び出し可能なメソッドは、doSomething()のための特定された呼び出し可能なメソッドである。doSomething()メソッドのためにプロシージャが次回に起動される際、キャッシュは以前に検索した情報を含む。そのため、キャッシュ内に呼び出されたメソッドに関する情報を持っているので、もうステップ６１５から６３５を実行する必要はない。上述したキーによって情報を取り出す。

【0043】

このように、もし、判断ステップ６１０において、ステップ６００の少なくとも一つの特定されたメソッドの呼び出し可能なメソッドが一つまたはそれ以上の参照されるメソッド（参照メソッド）としてキャッシュ内にあるならば、この一つまたはそれ以上の参照メソッドは、図１１および１２にて詳しく説明されるように、ステップ６４０で報告および／または計測され得る。もし、判断ステップ６１０において、このステップ６００の少なくとも一つの特定された呼び出し可能なメソッドがキャッシュ内にないのであれば、ステップ６１５から６３５が実行される。ステップ６１５は、少なくとも一つのメソッドのクラスを、リフレクションを介して決定する。一つの可能性ある実装において、これはJavaアプリケーションプログラミングインタフェース（ＡＰＩ）、java.lang.instrument（ステップ６１７）の使用を含む。少なくとも一つのメソッドは、それが一つまたはそれ以上の呼び出し可能なメソッドを起動したり呼び出したりすることから、呼び出しメソッドであると考えられる。ステップ６１５は、メモリ内、例えばＪＶＭ内のすべてのロードされたクラスの中からJavaクラスをフェッチすることなどによって少なくとも一つのメソッドのクラスを決定することを含むことができる。

【0044】

ステップ６２０は、例えば、バイトコードが取得された元のリソース場所から、クラスのバイトコード表現をロードすることを含む。実装例では、可能な場合には、JavaクラスのClassLoaderが使用される（ステップ６２２）。自動的に発生したクラスが非常に大きくてメモリをいっぱいにしないように、ステップ６２０にて安全のための予防策によりメモリにロードされるコードの量が制限されることに留意されたい。

【0045】

ステップ６２５は、呼び出しバイトコードの一つまたはそれ以上のインスタンスを特定するためにステップ６２０で得られる各クラスのバイトコード表現を構文解析することを含む。特定の実装においては、クラスのバイトコード表現の特定のオペコード（オペレーションコード）を特定することが含まれる（ステップ６２７）。例えば、Java言語の４つのオペコードが、別のメソッドを呼び出すバイトコードを特定する。具体的には、仮想呼び出しのためのオペコードは１０進値１８２または１６進値（0xb6またはb6）、特定呼び出しのオペコードは１０進値１８３または１６進値（0xb7またはb7）、静的呼び出しのオペコードは１０進値１８４または１６進値（0xb8またはb8）、および、インタフェース呼び出しのオペコードは１０進値１８５または１６進値（0xb9またはb9）、である。これらのオペコードのいずれかの存在が呼び出し可能なメソッドを特定する。

【0046】

ステップ６２５を、一つまたはそれ以上の特定のオペコードを検出するために制限することも可能であるが、すべての可能なオペコードよりも少ない。例えば、インタフェースメソッドは着目するものでないと定めることができ、その場合には、オペコードが、仮想呼び出し、特殊呼び出し、及び、静的呼び出しの場合のみ検出され、インタフェース呼び出しの場合は検出されない。

【0047】

ステップ６３０は、呼び出しバイトコードの一つまたはそれ以上のインスタンスに基づく一つまたはそれ以上の参照メソッドを特定する。実装例では、ステップ６１５にて、この一つまたはそれ以上の参照メソッドは、決定されるクラスの定数プールから抽出される。特に、ステップ６３２は、オペコードに基づき定数プールテーブル内のエントリに対してインデックスを特定し、ステップ６３４は、インデックスに基づき参照された一つまたはそれ以上のメソッドを特定する。ステップ６３５は、一つまたはそれ以上の参照メソッドをキャッシュ内に、文字列、例えばdoSomething()のために呼び出されたメソッド、として格納する。ステップ６４０は、図１１−１４にて詳しく説明されているように、一つまたはそれ以上の参照メソッドを報告および／または計測することを含む。

【0048】

図６の処理は、同時に、または異なる時間に、多くの異なるメソッドに対して個別に実行され得ることに留意されたい。

【0049】

図７は、７００でまとめて示しているが、図６のメソッドに関連して使用されるソフトウェアおよびハードウェアを示す。ハードウェアは、動的計測キャッシュ７０２およびメモリリソース７１５を含む。図６のステップ６０５、６１０および６４０に関連して述べたように、動的計測キャッシュは、解析対象のメソッドに対して特定された呼び出し可能なメソッドを格納することができる。その呼び出し可能なメソッドは、同じメソッドの解析が続けて行われる場合、図６のステップ６１５から６３０を実行することなく、キャッシュから直ちに特定されることができ、これにより、コンピュータリソース消費量を削減することができる。リソース７１５は、アプリケーションの実行が開始され計測されるときにメモリにロードされるアプリケーションの異なるクラスのバイトコードを格納するために使用される記憶場所となり得る。一つの可能な実装においては、動的計測キャッシュ７０２およびリソース７１５は、アプリケーションサーバ内の図２のメモリ２４０において提供される。

【0050】

図６のステップ６１５および６１７に対応して、Java.lang.instrument ＡＰＩ７１０は、少なくとも一つの解析されるメソッドの特定のクラス７２５を決定するため、ロードされたすべてのクラス７０５へのアクセスに使用される。一つのアプローチでは、ロードされたすべてのクラスは配列で提供される。図６のステップ６２０および６２２に対応して、クラスローダ７２０は、クラス７２５に基づいて、クラス７２５のためのバイトコード７３０をロードするため、リソース７１５へのアクセスに使用される。図６のステップ６２５および６２７に対応して、クラスバイトコード７３０は、オペコード７３５、７４０、７４５および７５０の一つまたはそれ以上のインスタンスを特定するために構文解析される。図６のステップ６３０、６３２および６３４に対応して、各オペコードは、定数プール７５５からメソッド呼び出しの文字列をフェッチするために使用されるインデックスバイト<indexbyte1, indexbyte2>をそれぞれ持つことができる。

【0051】

図８は、ソフトウェアを計測するための処理フローの例を示す。図５Ａに対応して、コンポーネント８１０の静的リストは、計測されたバイトコードを提供するためのトランスフォーマ／プローブビルダ８００の使用のためにバイトコードをロードするクラスローダ８０２に提供され得る。例えば、defineClassメソッドが、バイト配列をClassクラスのインスタンスに変換する。さらに、図６の処理によって発見されたメソッドのような発見されたコンポーネント８０６は、計測されることが可能である。一つのアプローチでは、図４Ｃまたは９に示されているように、ユーザインタフェース８０８は、発見されたコンポーネントを計測すべきものとしてユーザに指定させることができる。ユーザも静的リスト８１０を変更することができる。ユーザインタフェースは、管理されたアプリケーション内に存在する既存のインスツルメンテーション（計測）から流入するパフォーマンスデータを監視するパフォーマンスモニタ８１２に応答することができ、例えば、あるコンポーネントがトランザクションにおいて実行に時間がかかるというような問題を起こしている事実を特定することができる。パフォーマンスデータは、範囲外にあるかどうかを決定するための下限および上限の閾値と比較され得る。

【0052】

発見されたコンポーネントは、計測すべきクラスの動的更新可能なリストを含む場合がある。このリストは、診断が行われる時間の限れた期間内に特定のメソッドが計測されるように随時変更することができる。ユーザインタフェース８０８によって時間期間を指定してもよいし、既定の時間期間を用いてもよい。したがって、コンポーネントは、例えば、インスツルメンテーション（計測）を有しないある時点からインスツルメンテーション（計測）を有する別の時点まで遷移するように、再定義することが可能である。計測の種類またはレベルが異なるものを提供することが可能であり、例えば、高いレベルの計測は、コンポーネントのパフォーマンスの多くの側面が追跡され、低いレベルの計測は、コンポーネントのパフォーマンスの僅かな側面が追跡される。コンポーネントを再定義することは、このように異なる計測の種類への遷移を含むことができる。

【0053】

計測は、多くの種類のパフォーマンス基準（メトリクス）／データを生成することができる。そのメトリクス／データには、コンポーネントの平均実行または応答時間、毎秒またはインターバルごとの呼び出し率、呼び出し回数、インターバルごとの、開始したが終了していない呼び出しの回数を示す同時並行性の基準、インターバルごとの、呼び出しを開始したメソッド呼び出しの回数が特定の閾値を超えた呼び出し回数を示すストール状態の基準が含まれる。また、データは、ガーベジコレクションのヒープサイズ、ファイルやソケットのアクティビティを示すバンド幅メトリック、スレッドの数、システムログ、例外処理、メモリリークおよびコンポーネントの相互作用を特定し得る。データは、どのコンポーネントが計測されたコンポーネントによって呼び出されたか、またはどれが計測されたコンポーネントを呼び出すか、を特定することもできる。例えば、コントローラのアーキテクチャにおいては、コンポーネントを管理するコントローラコンポーネント内の制御フローは、次に実行されて、どのくらいの頻度で実行され、どのように実行されるかを知っている。コントローラコンポーネントは、計測を介して、未計測のどのコンポーネントが頻繁に呼び出され、その結果、おそらく重要で計測を付加するために再定義される必要があることを報告することができる。

【0054】

上述のように、計測の種類を変更するためにコンポーネントを再定義することが可能である。例えば、一つまたはそれ以上のパラメータが範囲外に存在するなど、既存の計測が問題を検出しているときには、より多くの計測が付加される可能性がある。また、計測が通常の状態に戻った場合には、その付加的な計測が削除されることがある。削除は、ユーザのコマンドに基づき、またはユーザの介入なしに自動的に行うことができる。

【0055】

発見されたコンポーネント８０６、ユーザインタフェース８０８、コンポーネントの静的リスト８１０およびパフォーマンスモニタ８１２は、同じ場所または異なる場所に提供され得ることに留意されたい。例えば、ユーザインタフェース８０８は、ユーザインタフェースホスト１２２（図１）に提供されることが可能であり、発見されたコンポーネント８０６およびコンポーネントの静的リスト８１０は、アプリケーションサーバ１０６または１１０に提供されることが可能であり、そして、パフォーマンスモニタ８１２は、エージェント１０８および１１２からのパフォーマンスデータをアプリケーションサーバ１０６、１１０でそれぞれ受信するマネージャ１２０に関連付けられることが可能である。

【0056】

パフォーマンスモニタ８１２は、呼び出されたどのコンポーネントが問題のトランザクションに関与しているかの見解を提供し、これらのコンポーネントに問題があるのか、問題を起こすのかを判断し、ユーザインタフェース８０８上でこの情報を特定することができる。

【0057】

ユーザインタフェース８０８は、例えば、発見されたコンポーネントを含むどのコンポーネントを計測すべきであるのか、または計測しないのかをユーザに手動で取捨選択させることができる。異なった種類が利用可能であるときは、計測の種類は、ユーザインタフェースを介して指定することもできる。

【0058】

コンポーネントの静的リスト８１０は、アプリケーションの実行開始時に計測すべきクラスまたは他のコンポーネントを含めることができる。これは、重要なデータを生成すると予想されるコンポーネントのベースラインリストになり得る。一つのアプローチでは、発見されたコンポーネント８０６のリストは、次回、システムが起動したときに同じコンポーネントが計測されるように、残しておくこともできる。これは、ユーザが一定のデータ、レポートやコンポーネントからのパフォーマンスデータを得られることができるようにし、ユーザに環境をセットアップさせるのに良い方法を提供する。

【0059】

コンポーネントは、コンポーネントがアプリケーションの実行時に既に組み込まれているかどうかに応じて異なる方法で再定義されることができる。コンポーネントがアプリケーションにまだ組み込まれていない場合には、一つの可能な実装として、ＪＭＶなどのクラスローダ８０２によってロードされることによって、正常に組み込まれることが可能である。例えば、.NETフレームワークを使用するような他の実装においては、クラスローダは使用されない。

【0060】

コンポーネントがロードされる場合には、命令があれば、例えば、ユーザインタフェース８０８、発見されたコンポーネント８０６、コンポーネントの静的リスト８１０およびパフォーマンスモニタ８１２、に応答して、トランスフォーマ／プローブビルダ８００がコンポーネントを計測する。アプリケーションにすでに組み込まれているが、計測されていないコンポーネントは、計測によりアプリケーションに再組み込みされることができる。例えば、コンポーネントは、アプリケーションから削除することができ、仮想マシンを再起動することなく実行中にリロードすることが可能である。これを達成するためには、JavaのredefineClassコマンドがコンポーネントとともにクラスローダ８０２に提供される。Java開発キット（ＪＤＫ）バージョン１．５またはそれ以降のバージョンがこのコマンドを使用する再定義機能を備えている。このコマンドは、提供されたクラスファイルを使用して提供されたクラスのセットを再定義する。それは、同時に複数のクラスの連動変更を許容するためにセットで動作する。また、再定義されたメソッドがアクティブなスタックフレームを有している場合には、これらのアクティブなフレームが元のメソッドのバイトコードの実行を続行し、再定義されたメソッドが新しい呼び出しで使用される。

【0061】

コンポーネントを例えばクラスのように再定義することは、クラスだけであるが、仮想マシンを再起動することに類似している。クラスが再定義されると、もしクラスが既存のメソッドスタックに存在するならば、そこにとどまる。しかし、すべての新しいメソッドが呼び出される場合には、新しいクラスが使用される。つまり、一旦、再定義されると、新しいバージョンがピックアップされる。

【0062】

トランスフォーマ／プローブビルダ８００は、再定義されたコンポーネントを受信する際、もしそうするように命令されていたのであれば、コンポーネントを計測する。トランスフォーマ／プローブビルダ８００は、コンポーネントに特定の種類の計測を付加することも可能である。

【0063】

発見されたコンポーネントが計測されアプリケーションに再組み込みされた後、計測が診断のために必要ではないならば、コンポーネントは、再度、アプリケーションに再組み込みされるが計測は行われなくなる。この計測の削除は、特定された診断期間または他のいくつかの他のイベントの後、ユーザコマンド、或いは、タイムアウトに基づいて行われる。例えば、パフォーマンスモニタ８１２は、発見されたコンポーネントのパフォーマンスデータが一定期間またはコンポーネントの呼び出し数が許容されていることを判断する。つまり、パフォーマンスモニタ８１２は、計測されたメソッドの少なくとも一つのメソッドのパフォーマンスデータがもはやパフォーマンスレベルの閾値に合致しない、ということはないということを判断する。応答においては、パフォーマンスモニタ８１２は、例えば、インスツルメンテーション（計測）を削除するためにredefineClassのようなコマンドを発行することができる。

【0064】

計測の付加および削除は実行時に動的に行われるので、バイトコードを実行している仮想マシンがダウンさせられることはなく、計測されたコンポーネントからのデータは直ちにアクセスされ得る（計測を付加する場合）。

【0065】

図９は、パフォーマンスデータに呼応したコンポーネント間の階層的関係を示すユーザインタフェース表示を示すもので、これにより、ユーザは、計測すべきコンポーネントを手動により特定することが可能となる。ユーザインタフェース９００は、解析されるメソッドの呼び出し可能なコンポーネントとして発見された一以上のコンポーネントの名前を特定する表示領域９０２を含む。他のコンポーネントの名称もまた提供され得る。この例では、Ｃ５Ａが唯一発見されたコンポーネントである。コンポーネントの名称／符号の横にあるチェックボックスは、このコンポーネントのための計測を選択するのにユーザがチェックを付けるものである。または、計測は、コンポーネントに自動的に付加され得る。表示領域９０２は、また、例えば、表示領域９０６内の計測に基づいたコンポーネントに対するトレースなどのデータを表示するために表示領域９０４内の一以上のコンポーネントを選択できることをユーザに通知する。

【0066】

同様に、ユーザは計測がコンポーネントから削除されるように示すためにチェックボックスのチェックを外すことも可能である。異なる種類の計測を特定するために、チェックボックスの追加または他のユーザインタフェース技術の使用もまた可能である。また、ユーザがユーザインタフェース９００を最初に見る場合、現在の計測状態に応じてチェックボックスに事前にチェックを付けたり、チェックを外したりすることも可能である。場合によっては、チェックボックスは、例えば、計測が誤って重要なコンポーネントから削除されないように、例えば、コンポーネントの計測状態は変更することができないことを示すためにグレー表示されることがある。

【0067】

ユーザは、例えば、コンポーネントがエラーに関与しているか否か、コンポーネント自身がエラーを起こしていないか、以前のトラブルシューティングの経験やその他の要因の観測に基づいて、ある発見されたコンポーネントに計測を付加すべきかどうかを指示することができる。

【0068】

表示領域９０４は、どのコンポーネントが別のコンポーネントの下にあるのか、または別のコンポーネントによって呼び出されるのかを示すツリーのような階層構造を使って、アプリケーション内の各コンポーネントを自動的に付加する。表示領域９０６は、領域９０４内のコンポーネントうち選択された一つについて計測に基づいて計測されたコンポーネントのトランザクショントレースなどのパフォーマンスデータを表示している。例えば、コンポーネント名がアンダーラインで示されているように、コンポーネントＣ１、Ｃ５およびＣ５Ａが現在ユーザによって選択されており、そして、対応するパフォーマンスデータ、例えば、トランザクショントレースが領域９０６における曲線９１０、９１２および９１４によって提示される。領域９０６は、エージェントからセントラルマネージャに提供されるパフォーマンスデータを付加する。

【0069】

いくつかのアプローチでは、領域９０４に表示されている情報は、発見されたコンポーネントのみが表示されるようにフィルタリングすることができる。また、ユーザは、ノードの下位レベルのコンポーネントを見るために、ツリーのノードを展開することができる。

【0070】

図１０は、図６のステップ６００の詳細を示す。解析するためのアプリケーション内の少なくとも一つのメソッドの特定は、様々な要因に基づいて行われ得る。一つの可能なアプローチでは、少なくとも一つのメソッドはパフォーマンスデータに基づいて特定される。具体的には、ステップ１０００は、アプリケーション内のメソッドを計測することを含む。例えば、これは、図５Ａおよび５Ｂに関連して記載したように静的計測を含むことができる。ステップ１００５は、計測されたメソッドからパフォーマンスデータを取得することを含む。パフォーマンスデータは、図４Ａ−Ｃおよび９に示されているように、継続的に得ることができ、リアルタイムの更新でユーザインタフェースに表示される。棒グラフ（バーチャート）、グラフ、テーブル等々のような様々な表示もまた提示することができる。ステップ１０１０は、計測されたメソッドの少なくとも一つのメソッドのパフォーマンスデータが閾値のパフォーマンスレベルを下回っていることを判断することを含む。例えば、図４Ａでは、パフォーマンスデータは、ｔ１６−ｔ１１であるＣ５（４４２）の応答時間を含み得る。今回、例えば、５タイムユニットでは、長すぎて閾値のパフォーマンスレベルを超えるので、応答時間は４タイムユニット以下にする必要があると仮定する。コンポーネントまたはメソッドＣ５は、このように、解析するための少なくとも１つのメソッドとして特定され得る。実際には、多くの異なるメソッドのパフォーマンスデータは、メソッドが期待された範囲内にあるか否かを確認するために閾値レベルに対して継続的に評価され、期待された範囲にないメソッドには解析のためにフラグが設定され得る。ステップ１０１５は、図６のステップ６０５から６４０の処理のように、少なくとも一つのメソッドによって呼び出し可能な一以上のメソッドを特定および／または計測するための処理を起動する。

【0071】

図１１は、一つまたはそれ以上の参照メソッドを報告および／または計測することに関する図６のステップ６４０の詳細を示す。ステップ１１００は、一つまたはそれ以上の参照メソッドを報告することを含む。即ち、それは、解析中の少なくとも一つのメソッドによって呼び出し可能なメソッドである。例えば、図４Ｃに表されているように、報告はユーザインタフェース表示の形式とすることができる。図４Ｃでは、一つまたはそれ以上の参照メソッドは、新しく発見されたコンポーネントＣ５Ａを含む。ステップ１１０５は、一つまたはそれ以上の参照メソッドを計測することを含む。これは、例えば図８の技術を含み得る。例えば、計測がアプリーションの実行中に発生するように、計測を動的にすることが可能であり、また、例えばアプリケーションはユーザから離れている。

【0072】

ステップ１１１０は、一つまたはそれ以上の計測されたメソッドを含むアプリケーションを実行することを含む。実際には、アプリケーションは、計測が付加されている一つまたはそれ以上の参照メソッドを含んで実行を継続する可能性がある。ステップ１１１５は、一つまたはそれ以上の計測されたメソッドのためのパフォーマンスデータを取得することを含む。このように、計測が付加される結果、一つまたはそれ以上の発見されたメソッドに関するパフォーマンスデータがそれから取得され得る。これは、特にメソッドに関係する問題を診断するのに役に立つ。ステップ１１２０は、パフォーマンスデータを評価することを含む。このことは、例えば、パフォーマンスデータと値の許容範囲とを比較することにより、そして、パフォーマンスデータが範囲外である場合、最小レベルを下回る場合、若しくは、最大レベルを上回る場合にフラグを設定することにより、自動的に行われる。例えば、図１３に示されたように、ステップ１１２５は、一つまたはそれ以上の計測されたメソッドによって呼び出し可能な一つまたはそれ以上のメソッドを特定および／または計測するための処理を起動することを含む。即ち、解析されている元のメソッドより１レベル低いメソッド、子メソッドに掘り下げる（ドリルダウン）という、反復技法（インタラクティブテクニック）が実行され得る。続いて、もしこの子メソッドのパフォーマンスデータによって保証される場合、または他の理由で、掘り下げ（ドリルダウン）が解析されている元のメソッドよりも２レベル低いレベル、つまり孫メソッド、若しくは前の子メソッドの子に対して実行され得る。この処理は、メソッドの階層内の下位レベルのメソッドを解析するために連続的に繰り返され得る。

【0073】

別のアプローチでは、最初の掘り下げ（ドリルダウン）は解析されている元のメソッドよりも２レベル以上低いレベル、例えば、子メソッドおよび孫メソッドの両方に行われてもよい。計測は、子メソッドおよび孫メソッドの両方に同時に付加され得る。この計測からのパフォーマンスデータは、さらなるレベルへの掘り下げ（ドリルダウン）が保証されるかどうか、さらなるレベルの計測が保証されるかどうかを示し得る。

【0074】

図１２は、一つまたはそれ以上の参照されたメソッドを報告および／または計測することに関する図６のステップ６４０の詳細を示す。ステップ１２００は、一つまたはそれ以上の参照メソッド、即ち解析中の少なくとも一つのメソッドによって呼び出し可能な新たに発見されたメソッドが計測されるべきではないということを示しているルールが設定されているかどうかを決定することを含む。場合によっては、図５Ａおよび５Ｂのルール５０５および５５５が特定のメソッドは計測されるべきではないことを示すこともある。これは、例えば、メソッドがネイティブでありそのためにバイトコードを有しない場合、メソッドが属するクラスがJava APIによって変換可能とされないようにマークされる場合、またはメソッド／クラスがエージェントのプルーブビルダーディレクティブ（ＰＢＤ）のインスツルメンテーション（計測）によって「スキップされた」とマークされた場合、に発生するが、それは破棄できない。

【0075】

ルールが一つまたはそれ以上の参照されたメソッドが計測されるべきではないということを示したことを示すユーザインタフェースを介して報告が作成され得る。ステップ１２０５は、一つまたはそれ以上の参照メソッドがすでに計測されているか否かを判断することを含む。例えば、ある場合においては、メソッドはアクティブにされていない計測を有し得るが、そのような場合、その計測をアクティブにさせることが可能である。また、メソッドがすでに計測されたことをユーザに示したい場合がある。それゆえ、もしそれに関する任意の情報をトランザクションコンポーネント内で見ないのであれば、それは呼び出されていないからである。ステップ１２１０は、一つまたはそれ以上の参照メソッドがインタフェースクラス内にあるか否かを判断することを含む。ユーザインタフェースは、この事実を報告することがあり、これにより、ユーザは、一つまたはそれ以上の参照メソッドが計測されるべきか否かを示すコマンドを入力することができる。この場合において、インスツルメンテーション（計測）は、すべての実装クラスを計測することに関与する。これは、いくつかの場合には望ましくないであろう計測が相当量になる可能性がある。

【0076】

ステップ１２００から１２１０の情報は、可能なメソッド呼び出しごとにリフレクションを使用してエージェントによって提供されることがある。この情報は、呼び出し可能なメソッドに計測を付加するか否かの判断に際してユーザをサポートする。情報は、例えば、Java 5 Instrument APIによって提供されることによってロードされたクラスの配列から検索したクラスのリフレクションを介して取得され得る。この情報は、情報を再決定する場合における計算上のリソースの消費を避けるために、後続のアクセスのためにキャッシュされ得る。

【0077】

図１３は、図１１のステップ１１２５の詳細を示す。図１３の処理は、図６のそれと類似しているが、それは一つまたはそれ以上の子メソッドに関しての説明である。ステップ１３００は、一つまたはそれ以上の参照メソッドが少なくとも一つのメソッドの一つまたはそれ以上の子メソッド、例えば、図６のステップ６００の解析するための少なくとも一つのメソッドであることを示す。ステップ１３０５は、図６のステップ６１５と同様であり、一つまたはそれ以上の子メソッドのクラスを決定する。ステップ１３１０は、図６のステップ６２０と同様であり、例えば、バイトコードが取得された元のリソース場所から、一つまたはそれ以上の子メソッドのクラスのバイトコード表現をロードすることを含む。ステップ１３１５は、図６のステップ６２５と同様であり、呼び出しバイトコードの一つまたはそれ以上のインスタンスを特定するためにステップ１３０５で得られる各クラスのバイトコード表現を構文解析することを含む。ステップ１３２０は、図６のステップ６３０と同様であり、一以上の子メソッドの呼び出しバイトコード（ステップ１３１５）の一以上のインスタンスに基づいて、一以上の子メソッドの一以上の孫の参照メソッドを特定する。ステップ１３２５は、図６のステップ６３５と同様であり、一以上の孫の参照メソッドを文字列としてキャッシュに格納する。ステップ１３３０は、図６のステップ６４０と同様であり、一以上の孫の参照メソッドを報告および／または計測することを含む。

【0078】

図１４は、図６のステップ６４０の詳細を示す。図１に関連して述べたように、複数のアプリケーションサーバはセントラルマネージャと通信しているエージェントをそれぞれ有することがある。したがって、エージェントは、アプリケーションのような同じコードで別々のインスタンス持つアプリケーションサーバで実行されているＪＶＭのクラスタ内に展開されていることがある。エージェントＡ１ １０８のような一つのエージェントは、アプリケーションにおける少なくとも一つのメソッドを解析し、一以上の参照メソッドを決定する。その一以上の参照の特定は、例えばマネージャ１２０を介して、一以上のエージェントが共有し得る。例えば、エージェントＡ１（１０８）は、呼び出し可能なメソッドなどのメソッド呼び出しの新しい規定が、指定されたクラスやメソッドに対して検索されたということを、マネージャ１２０に通知してもよい。マネージャ１２０は、エージェントＡ２（１１２）のようなクラスタ内の他のエージェントに重要である可能性のある情報をプッシュ（転送）することを決定することができる。これにより、他のエージェントにおけるメソッドの呼び出し検出ステップの繰り返しを避けることができ、発見された呼び出し可能なメソッドの異なるインスタンスからパフォーマンスデータをエージェントが収集できるようにすることができる。アプリケーションの別のインスタンスの同じメソッドのパフォーマンスデータを見ることによって、アプリケーションの動作をより詳細に把握することが可能となる。

【0079】

例示の処理では、ステップ１４００は、一以上の参照メソッドを、アプリケーションの最初のインスタンスに関連づけられている最初のエージェント（１０８）から、マネージャに報告する。ステップ１４０５では、マネージャは、アプリケーションの一以上の他のインスタンスに関連付けられている一以上の他のエージェント（１１２）に、一以上の参照メソッドの特定をプッシュ（転送）する。ステップ１４１０では、一以上の他のエージェントが、アプリケーションの一以上の他のインスタンスにおける一以上の参照メソッドの一以上の他のインスタンスを計測する。

【0080】

以上、本発明の具体例を詳細に説明したが、これらは例示に過ぎず、本発明の範囲を限定するものではない。上記した技術には、以上に例示した具体例を様々に変形、変更したものが含まれる。上記した実施形態は、本発明の原理をベストに説明するために選定されたものであり、その実用に際しては、本発明が最適にその有用性を発揮するように、その特定用途に適するように当業者が様々に変形し得る。発明の範囲は、ここに添付した特許請求の範囲によって定められることを意図している。

【図1】

【図2】

【図3】

【図4A】

【図4B】

【図4C】

【図5A】

【図5B】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】