JP2011238232A - 特定のトランザクションコンテキストにおけるソフトウェアによる条件付き動的計測 - Google Patents

Abstract

【課題】トレース対象とするコンポーネントを適切に選択する。
【解決手段】管理対象アプリケーション内に存在する既存のインスツルメンテーション（計測）から流入するパフォーマンスデータを監視するパフォーマンスモニタ１０１２は、閾値に基づいて、実行に時間がかかっているコンポーネントを発見する。ユーザインタフェース１００８は、発見されたコンポーネント１００６の中から計測対象とするコンポーネントを選択することができ、また静的リスト１０１０を変更することもできる。クラスローダ１００２が、発見されたコンポーネントおよび静的リストを用いて計測対象のコンポーネントのバイトコードをロードし、トランスフォーマ／プローブビルダ１０００がプローブを挿入する。
【選択図】図１０

Description

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

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

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

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

一実施形態では、アプリケーションを計測するためのコンピュータに実装される方法は、コンピュータに実装された複数のステップを含む。このステップは、アプリケーション内の計測されるメソッドからパフォーマンスデータを取得することを含む。例えば、これは各メソッドの開始および停止の回数を含み得る。この方法は、パフォーマンスデータに基づいて、さらに詳細に解析するための計測されるメソッドのうち少なくとも一つのメソッドを選択することを、さらに含み、この方法は、その選択に基づいて、少なくとも一つの選択されたメソッドにより呼び出されかつ未計測の少なくとも一つの呼び出し可能なメソッドを決定することを含む。この方法は、この決定に対応して、少なくとも一つの呼び出し可能なメソッドのための条件付き計測を提供することを、さらに含み、その中で、その条件付き計測が、その少なくとも一つの呼び出し可能なメソッドが呼び出されるコンテキストを特定する。

別の実施形態では、アプリケーションを計測するためのコンピュータに実装される方法は、アプリケーションの少なくとも一つの選択されたメソッドの計測から、その少なくとも一つの選択されたメソッドが実行を開始することを示す情報を受信することを含み、その受信に基づいて、その少なくとも一つの選択されたメソッドが実行されていることを示す指標をメモリリソースに格納することを含む。例えば、そのメモリリソースはスレッドローカルキャッシュであり得る。この方法は、その少なくとも一つの選択されたメソッドによって少なくとも一つの呼び出されたメソッドが呼び出されるときに、アプリケーションのその少なくとも一つの呼び出されたメソッドの条件付き計測からリクエストを受信することを、さらに含む。そのリクエストは、少なくとも一つの選択されたメソッドが実行されていることを示す指標に、メモリリソースからアクセスする。さらに、条件付きの計測は、アクセスされた指標の少なくとも一部に基づいてその少なくとも一つの呼び出されたメソッドの実行に関して報告するために実行する。

他の実施形態では、少なくとも一つのプロセッサを、アプリケーションの計測をするための方法を実行させるためにでプログラムするために具現化されたコンピュータ読み取り可能なソフトウェアを有しているコンピュータで読み取り可能な有体の記憶装置を提供する。実行されるその方法は、アプリケーション内の計測されたメソッドからパフォーマンスデータを取得すること、さらに詳細に解析するために計測されるメソッドの少なくとも一つのメソッドを特定すること、少なくとも一つの選択されたメソッドから呼ばれ得るメソッドであって未計測の少なくとも一つの呼び出し可能なメソッドを特定すること、少なくとも一つの呼び出し可能なメソッドが続いて呼び出される場合に条件が合致しているかどうかを決定する少なくとも一つの呼び出し可能なメソッドの条件付き計測を提供すること、を含む。その条件付き計測は、その条件が合致したという決定に基づいて少なくとも一つの呼び出し可能なメソッドを実行することに関してパフォーマンスデータを提供するために実行し、その条件付き計測は、条件が合致しなかったという決定に基づいて少なくとも一つの呼び出し可能なメソッドを実行することに関してパフォーマンスデータを提供するためには実行しない。

方法に対応して、本明細書にて提供される方法を実行する命令がエンコードされた記憶媒体を含むコンピュータましくはプロセッサ読み取り可能な記憶装置、及び、システムが、提供される。

管理されたアプリケーションを含むシステムを示す。 図１のネットワークのコンピュータシステムを示す。 計測されるコンポーネントの可能性のある呼び出しシーケンスの例を示す。 図３Ａで計測されるコンポーネントによって呼び出され得ることで発見されたコンポーネントの例を示す。 図３Ｂで発見されたコンポーネントの一つによって呼び出され得ることで発見されるコンポーネントの例を示す。 図３Ｂで発見されたコンポーネントで、コンポーネントがトランザクションデータのコンテキスト内に呼び出される場合を示す。 電子商取引のwebサイトで商品を買うトランザクションの例であり、計測されるコンポーネントおよび発見されたコンポーネントの呼び出しシーケンスを含む例を示す。 条件付き計測が発見されたコンポーネントに適用され、条件付き計測の条件が呼び出しシーケンス内の一つのコンポーネントに合致する場合において、図４Ａの呼び出しシーケンスに基づく、呼び出しスタックの位置に対する時間のグラフを示す。 条件付き計測が発見されたコンポーネントに適用され、条件付き計測の条件が呼び出しシーケンスに合致しない場合において、図４Ａの呼び出しシーケンスに基づく、呼び出しスタックの位置に対する時間のグラフを示す。 条件付き計測が発見されたコンポーネント適用され、条件付き計測の条件が呼び出しシーケンス内の一つのコンポーネントの組み合わせとトランザクションデータに合致する場合において、図４Ａの呼び出しシーケンスに基づく、呼び出しスタックの位置に対する時間のグラフを示す。 条件付き計測が発見されたコンポーネントに適用され、条件付き計測の条件が呼び出しシーケンス内の一つのコンポーネントには合致するが、トランザクションデータに合致しない場合において、図４Ａの呼び出しシーケンスに基づく、呼び出しのスタック位置に対する時間のグラフを示す。 電子商取引のwebサイトで商品を買うトランザクションの別の例で、計測されたコンポーネントおよび発見されたコンポーネントの呼び出しシーケンスを含むものを示す。 条件付き計測が発見されたコンポーネントに適用され、条件付き計測中の３つのコンポーネントに合致する場合において、図５Ａの呼び出しシーケンスに基づく、呼び出しスタックの位置に対する時間のグラフを示す。 条件付き計測が発見されたコンポーネントに適用され、条件付き計測の条件が呼び出しシーケンスに合致しない場合において、図５Ａの呼び出しシーケンスに基づく、呼び出しスタックの位置に対する時間のグラフを示す。 パフォーマンスデータに呼応したコンポーネント間の階層的関係を示すユーザインタフェース表示を示すもので、これにより、ユーザは、条件付きで計測するコンポーネントを手動により特定することや、条件付き計測を削除すること、条件付き計測のシーケンス長を特定すること、そしてトランザクションデータに基づいてパフォーマンスデータをフィルタリングすること、が可能となる。 Java（登録商標）実行環境を示す。 静的計測のための処理フローの例としてJavaベースのものを示す。 静的計測のための処理フローの例として.NETベースのものを示す。 呼び出し可能なメソッドを特定し、条件付き計測を適用することによりソフトウェアを解析するためのメソッドを示す。 図８Ａのステップ８００の詳細を示す。 図８Ａのステップ８０２の詳細を示す。 図８Ａのステップ８０４の詳細を示す。 図８Ａのステップ８０６の詳細を示す。 図８Ａのステップ８０８の詳細を示す。 図８Ａのステップ８１０の詳細を示す。 図８Ａのステップ８１０の他の実装の詳細を示す。 図８Ａのステップ８１２の詳細を示す。 スレッドローカルキャッシュに関連したアクティビティで、図５Ｂと図８Ｉに一致するものを示す。 図８Ａのメソッドに関連して使用され得るソフトウェアおよびハードウェアを示す。 ソフトウェアを計測するための処理フローの例を示す。

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

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

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

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

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

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

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

図３Ａは、計測されるコンポーネントの可能性のある呼び出しシーケンスの例を示す。図１のアプリケーションサーバ１０６、１１０などのアプリケーションサーバ上で実行されるアプリケーション内のコンポーネントが示されている。アプリケーションが計測されるときには、通常、そのアプリケーションの開発者の理解や興味の対象となるであろうコンポーネントの選択に基づいて、選択されたコンポーネントのみが計測されることに留意されたい。このように、少なくとも最初は、興味があるものとされていないため、多くのコンポーネントはアプリケーション内で起動され／呼び出されるが、計測されることはない。

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

特定の例に示されているように、コンポーネントＣ１ ３００およびＣ２ ３０２はコンポーネントＣ３ ３０４を呼び出すことができる。矢印は、実行開始時にはメソッドの呼び出しを、実行終了時にはメソッドのリターンを示している。コンポーネントＣ３ ３０４およびＣ４ ３０６は、コンポーネントＣ５ ３０８を呼び出すことができる。このように、可能性のある呼び出しシーケンスは、Ｃ１−Ｃ３−Ｃ５、Ｃ２−Ｃ３−Ｃ５およびＣ４−Ｃ５である。図示されている各コンポーネントは、実行時間を含むパフォーマンスデータが、それらから得られるように計測されると仮定する。ただし、現在は計測されていないが呼び出される追加のコンポーネントが存在する可能性がある。過度なアプリケーションの減速を避けるためには、すべてのコンポーネントを計測することはできない。また、追加のコンポーネントが、アプリケーションのパフォーマンス問題を診断するために一時的に計測できる場合でも、計測によって提供されるデータの量は、依然として包括的過ぎる可能性がある。効率を最適化するために、条件付き計測は、コンポーネントが実行されるコンテキスト内に条件付けられて提供することが可能である。そのコンテキストは、そこでパフォーマンス問題が発生しているコンテキスト、あるいは、一般的に解析することが望まれている特定のコンテキストに対応するように、設定できるようになっている。

例えば、過剰な実行時間などのパフォーマンス問題がＣ５にあると特定されていると仮定する。この場合、例えば、Ｃ５によって呼ばれ得るメソッド、即ち、Ｃ５の呼び出し可能なメソッドである未計測のメソッドを発見するため、処理が実装される。計測メソッドは、起動されていない計測コードを有するか、または計測コードが与えられていない。図３Ｂの例では、発見されたコンポーネントはＣ６ ３１０とＣ７ ３１２である。

図３Ｂは、図３Ａの計測されたコンポーネントによって呼び出され得るコンポーネントであって発見されたコンポーネントの例を示す。発見されたコンポーネントは、Ｃ５のパフォーマンス問題を解析するのに役立ち得るパフォーマンスデータを取得するために計測され得る。例えば、Ｃ６はＣ５により呼び出されて実行に時間がかかり過ぎると判断され、しかし、Ｃ５により呼び出されたＣ７は許容されるパフォーマンスを備えていると判断される。これは、Ｃ６を含んでいる追加の解析が保証され得ることを示している。

コンテキストに関して、Ｃ６とＣ７の計測は、呼び出される一つのコンポーネントまたは特定の複数のコンポーネントのシーケンスによって条件付けられる可能性がある。例えば、Ｃ５がＣ１−Ｃ３−Ｃ５のシーケンスにおいて呼び出されるときは、Ｃ５はパフォーマンス問題を持っていると判断されるが、しかし、Ｃ２−Ｃ３−Ｃ５またはＣ４−Ｃ５のような別のシーケンスで呼び出されるときにはＣ５はパフォーマンス問題を持っていないと判断されることもある。このように、Ｃ６とＣ７の計測は、Ｃ１−Ｃ３−Ｃ５のシーケンスによって呼び出されることに対してＣ６またはＣ７に条件付けられる可能性がある。もしＣ６またはＣ７がこのシーケンスで呼び出される場合、特定されたコンテキストが合致するのであれば、Ｃ６またはＣ７の条件付き計測は、Ｃ６またはＣ７の実行または呼び出しを、例えば、エージェントに報告することを実行する。同様に、Ｃ６またはＣ７が別のシーケンスで呼び出される場合、特定されたコンテキストが合致しないのであれば、Ｃ６またはＣ７の計測は、Ｃ６またはＣ７の実行または呼び出しを報告することは実行しない。

一つ以上のコンテキストも、任意の呼び出し可能なコンポーネントのために同様に実装され得ることに留意されたい。例えば、Ｃ６は、Ｃ１−Ｃ３−Ｃ５およびＣ２−Ｃ３−Ｃ５のコンテキストに基づいて計測される可能性がある。

一旦、呼び出し可能なコンポーネントが見つけ出されると、コンポーネントの階層のさらに下にある呼び出し可能なコンポーネントのレベルを発見して計測する処理が繰り返される。例えば、図３Ｃは、図３Ｂで発見されたコンポーネントの一つによって呼び出され得ることで発見されたコンポーネントの例を示す。具体的には、コンポーネントＣ８ ３１４、Ｃ９ ３１６およびＣ１０ ３１８は、Ｃ６から呼び出され得る。これらの発見されたコンポーネントは、Ｃ６のパフォーマンス問題を解析するのに役立ち得るパフォーマンスデータを取得するために計測され得る。この例では、一度に、コンポーネントの１つのレベルの発見および計測が処理され、当該レベルが階層内のコンポーネントのレベルを参照していることに留意されたい。例えば、図３Ｃの階層においては、第１レベルはＣ１とＣ２を含み、第２レベルはＣ３とＣ４を含み、第３レベルはＣ５を含み、第４レベルはＣ６とＣ７を含み、第５レベルはＣ８、Ｃ９、Ｃ１０を含んでいる。階層内にはさらに下位レベルが有る場合も無い場合もあり得る。他のアプローチとしては、一度にコンポーネントの２以上のレベルの発見と計測を実行する。例えば、図示されてはいないが、呼び出し可能なＣ７のコンポーネントを発見するのに加え、Ｃ６とＣ７が見つけ出され、その後にＣ８、Ｃ９、Ｃ１０が発見されることが可能である。Ｃ６からＣ１０のコンポーネントとＣ７の呼び出し可能なコンポーネントは、一緒に計測することが可能である。

コンテキストに関して、Ｃ８、Ｃ９およびＣ１０の計測は、呼び出される特定のコンポーネントのシーケンスに基づいて条件付けが行われる可能性がある。例えば、Ｃ６は、Ｃ１−Ｃ３−Ｃ５−Ｃ６のシーケンスにおいて呼び出された場合にパフォーマンス問題を持っていると判断され、別のシーケンスにおいて呼び出された場合にはそうではないと判断される、ということがある。このように、Ｃ８、Ｃ９およびＣ１０の計測は、Ｃ１−Ｃ３−Ｃ５−Ｃ６のシーケンスによって呼び出されたた場合にＣ８、Ｃ９またはＣ１０に条件付けされることがある。もしＣ８、Ｃ９またはＣ１０がこのシーケンスで呼び出される場合、特定されたコンテキストが合致し、Ｃ８、Ｃ９またはＣ１０の計測は、Ｃ８、Ｃ９またはＣ１０の実行／呼び出しを報告することを実行する。同様に、Ｃ８、Ｃ９またはＣ１０が別のシーケンスで呼び出される場合、特定されたコンテキストは合致せず、Ｃ８、Ｃ９またはＣ１０の当該計測は、Ｃ８、Ｃ９またはＣ１０の実行／呼び出しを報告することを実行しない。

図３Ｄは、図３Ｂで発見されたコンポーネントで、コンポーネントがトランザクションデータのコンテキスト内に呼び出されるものを示す。呼び出しコンテキストのもう一つの特徴は、コンポーネントが実行するトランザクションのデータに関与し得ることである。呼び出しシーケンスを発見されたコンポーネントの計測の条件付けは、解析するためのパフォーマンスデータの量を絞り込みに便利である一方、付加的または代替として、トランザクションデータベースのコンテキストに設定することで効率性を得ることが可能となる。例えば、ユーザがアイテムを注文して支払いを行うWebベースの電子商取引アプリケーションについて検討する。トランザクションデータは、特定の支払いタイプが使用されたときにパフォーマンス問題が生じたことを示す可能性がある。

図３Ｄでは、データ１およびデータ２は、トランザクションデータとして可能なタイプを表している。例えば、データ１が問題の有る支払いタイプで、データ２が問題の無い支払いタイプを表していると仮定する。一般的に、トランザクションの様々なアスペクト（側面）は、個々のデータフィールドによって表される。Ｃ１がＣ３を呼び出すとき、例えばメッセージのヘッダなどに、Ｃ１はデータ１を含み、これにより、Ｃ３が必要に応じてこのデータにアクセスすることができる。このシーケンスでは、データ１はＣ３からＣ５へ渡され、Ｃ５からＣ６またはＣ７へ渡される。一方、Ｃ２がＣ３を呼び出すシーケンスでは、データ２（データ１とは異なる）がＣ２からＣ３、Ｃ３からＣ５、Ｃ５からＣ６またはＣ７へ渡される。この例の場合、Ｃ６またはＣ７に対する条件付き計測においては、データ１がＣ６に渡されるときに限ってパフォーマンスデータを報告することが実行される。

図４Ａは、電子商取引のwebサイトで商品を買うトランザクションの例で、計測されたコンポーネントおよび発見されたコンポーネントの呼び出しシーケンスを含むものを示す。これは、ユーザが関与するトランザクションの一例である。ここで用いられているコンポーネントを示す符号は、必ずしも図３Ａ−３Ｄで示した前例に対応している必要はない。しかしながら、図４Ａ−Ｅと図５Ａ−５Ｄと図８Ｊでは、コンポーネントを示す符号は、一貫して使用されている。ユーザがアイテムを注文できるようにするWebベースの電子商取引アプリケーションを考える。コンポーネントは、アプリケーション内のビジネスロジックまたは電子商取引の手順に対応する。特に、コンポーネントＣ１ ４００では、ユーザがアイテムを選び、購入し、クレジットカードの種類やクレジットカード番号といった支払い方法の情報、アイテムを発送する住所といった発送情報、陸送または翌朝配達の航空発送といった発送方法の情報を入力する、ショッピングカートを提供している。Ｃ１は、コンポーネントＣ２ ４０２を呼び出し、選択されたアイテムの在庫があるかどうかを決定するために在庫をチェックする。一旦、選択されたアイテムの在庫があると判断されると、Ｃ２は実行を完了し、制御フローがＣ１に戻る。Ｃ１は、コンポーネントＣ３Ａ ４０４またはＣ３Ｂ ４０６を呼び出し、そこでトランザクションが保留にされている間、当該アイテムが他のユーザに販売されないように、アイテムを予約する。Ｃ３Ａの場合、当該アイテムはユーザ自身のために予約される一方、Ｃ３Ｂの場合、当該アイテムは、ユーザ以外の人への贈答用にギフトレジトリまたはウッシュリストなどに予約される。Ｃ３ＡまたはＣ３Ｂは、支払いコンポーネントＣ４Ａ ４１０を呼び出し、そこで、現金払い、例えばデビットカードもしくは銀行振替またはPAYPAL（登録商標）のような第三者支払いの処理がされ、あるいはクレジット払いコンポーネントＣ４Ｂ ４１２を呼び出し、ここで、特定のクレジットカードの発行会社のようなクレジットカード払いまたは支払いギフト券やクーポンによる支払いの処理がされる。コンポーネントＣ４ＡおよびＣ４Ｂは、外部サーバとの通信により購入の承認と認証が行われる。

この例では、Ｃ４ＡまたはＣ４Ｂは、コンポーネントＣ５ ４１４を呼び出し、購入されたアイテム数を減算して在庫を合わせる。ところが、Ｃ５は、元来、計測を含んでいないため、Ｃ４ＡまたはＣ４Ｂの呼び出し可能なメソッドとして見つけ出される。例えば、もしパフォーマンスデータがＣ４Ａの実行に非常に時間がかかることを示す一方で、Ｃ４Ｂのパフォーマンスデータが許容可能なものであることを示す場合には、Ｃ５は、Ｃ４Ａの呼び出し可能なメソッドとして見つけ出されて、条件付き計測がＣ５に適用される。これは、Ｃ５のパフォーマンスデータがＣ４Ａを診断するための試行中に得られるようにしている。Ｃ５は、またパフォーマンス問題を持ったＣ４ＡおよびＣ４Ｂの両方に基づいても見つけ出される可能性がある。

Ｃ５およびＣ５以下で呼び出される図略の任意のコンポーネントが、一旦、実行を完了すると、Ｃ３ＡまたはＣ３Ｂの実行完了後、Ｃ４ＡまたはＣ４Ｂの実行が完了するように、実行フローがＣ１に戻る。そして、Ｃ１は、発注確認番号および追跡番号等を確認電子メールまたはWebページで提供するなどのユーザによる購入を確認する、発注完了コンポーネントＣ７ ４０８を呼び出す。

コンポーネントは、非同期モードでマルチスレッドまたはマルチプロセスの実行を開始する別のコンポーネントを呼び出した後、実行を継続させることができ、または呼び出されたコンポーネントが同期モードでシングルスレッドまたはシングルプロセスの実行を終了するまで、コンポーネントを一時的に休止させることができる、ことに留意されたい。例えば、Ｃ４ＡもしくはＣ４ＢならびにＣ５のコンポーネントが実行している間、Ｃ３ＡまたはＣ３Ｂは休止する。さらに、任意のコンポーネントは、トランザクション内に複数回呼び出されることが可能である。

図４Ｂは、条件付き計測が見つけ出されたコンポーネントに適応され、条件付き計測の条件が呼び出しシーケンス内の一つのコンポーネントによって合致する場合において、図４Ａの呼び出しシーケンスに基づく、呼び出しスタックの位置に対する時間のグラフを示す。時間の増分は必ずしも等間隔でなくともよい。しかし、図４Ｂ−４Ｅと５Ｂと５Ｃのグラフの時間の増分は一致している。

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

事例の実行パスは、コンポーネントとそれぞれのグラフの領域と実行時間を、次のように示す；Ｃ１ ４２０（ｔ１−ｔ２５）、Ｃ２ ４２２（ｔ２−ｔ４）、Ｃ３Ａ ４２４（ｔ５−ｔ１９）、Ｃ４Ａ ４２８（ｔ６−ｔ１８）、Ｃ５ ４３０（ｔ７−ｔ１７） およびＣ７ ４２６（ｔ２０−ｔ２４）。この例は、自分使いアイテム予約（Ｃ３Ａ）と現金払い（Ｃ４Ａ）のオプションを含んでいる。ホストは、クライアントからのリクエストを受信して、Ｃ１がｔ１において実行を開始したことに気づく。当該シーケンス内における各トランザクションは、計測に基づいてエージェントによって気づかれる。ｔ２においてＣ１がＣ２を呼び出し、Ｃ２はｔ４において実行を完了する。Ｃ１がｔ５においてＣ３Ａを呼び出す。Ｃ３Ａがｔ６においてＣ４Ａを呼び出す。Ｃ４Ａがｔ７においてＣ５を呼び出す。Ｃ５がｔ１７において実行を完了する。Ｃ４Ａがｔ１８において実行を完了する。Ｃ３Ａがｔ１９において実行を完了する。Ｃ１がｔ２０においてＣ７を呼び出し、Ｃ７がｔ２４において実行を完了する。Ｃ１がｔ２５において実行を完了するとき、ホストがクライアントにレスポンスを出す。ホストは、定期的にセントラルマネージャに時間とトランザクションデータを報告する。

Ｃ５のための領域４３０は、Ｃ５が条件付きで計測されていることを示すために点線で表されている。さらに、この例では、その計測を起動するのに必要とされるコンテキストまたは条件は、Ｃ５がＣ４Ａによって呼び出されることである。即ち、当該コンテキストは、スタック内の一つまたはそれ以上の特定呼び出しされた一連のメソッドに基づくものである。図示されているように、コンテキスト内におけるメソッドの開始と終了は、それぞれｔ６とｔ１８である。Ｃ４Ａは、Ｃ５が呼び出されるときには実行されているので、コンテキストは合致し、Ｃ５の条件付き計測が実行される。

最初に、Ｃ５が条件付きで計測されないと仮定すると、図４Ｂのグラフは領域Ｃ５を含まない。このグラフは、グラフの背後にある対応するデータが自動的に処理され判断されて、Ｃ４Ａの応答時間が長すぎて閾値レベルを超えることをユーザに示している。しかしながら、この時点では、Ｃ４Ａによって呼び出される可能性のあるメソッドに関するユーザインタフェースから知らされている情報はない。この例では、本明細書に記載されている技術は、Ｃ５がＣ４Ａから呼び出されることを見つけ出すために用いられる。呼び出し可能のコンポーネントは、必ずではないが、別のコンポーネントから呼び出される可能性がある。グラフにおいて１つ上位のレベルの別のメソッドによって直接呼び出される特定のメソッドは、その別のメソッドの子メソッドであると見なし得る。同様に、グラフにおいて次の一つ上位のメソッドは、特定のメソッドの親の親メソッドと見なすことができ、以降、同様である。一旦、呼び出し可能なメソッドが特定され、それが続いて呼び出されると、パフォーマンスデータを取得するために計測される。この場合、Ｃ５は見つけ出された後に計測され、そのアプリケーションは実行を継続し、新しいパフォーマンスデータが集められて領域４３０がグラフに表示される。

図４Ｃは、条件付き計測が発見されたコンポーネントに適用され、条件付き計測の条件が呼び出しシーケンスによって合致しない場合において、図４Ａの呼び出しシーケンスに基づく、呼び出しスタックの位置に対する時間のグラフを示す。図４Ｂでは、計測を起動するのに必要とされるコンテキストは、Ｃ５がＣ４Ａによって呼び出されることである。しかしながら、この場合は、グラフの領域４２９に示されているように、Ｃ４ＢがＣ４Ａの代わりに実行されている。その結果、Ｃ４Ａのコンテキストが合致せず、条件付き計測が実行されないので、領域４３０はグラフには表れない。

図４Ｄは、条件付き計測が発見されたコンポーネントに適用され、条件付き計測の条件が、呼び出しシーケンス内の一つのコンポーネントとトランザクションデータの組み合わせによって合致する場合において、図４Ａの呼び出しシーケンスに基づく、呼び出しスタックの位置に対する時間のグラフを示す。上述したように、コンテキストまたは条件付き計測の条件には、呼び出されている一つまたはそれ以上の特定のメソッドおよび／または提示されている特定のトランザクションデータを含むことができる。特に、トランザクションによって運ばれるデータオブジェクトまたはデータエレメントを調べることができる。例えば、内部コンポーネントのメッセージのヘッダー内の特定値の存在は、コンテキストとして使用することが可能である。または、値がnullでない、またはnullであるデータフィールドの単なる存在もコンテキストとして使用することができる。

トランザクションデータは様々なアイテム：発注する商品の種類、商品の製造元の身元、購入するユーザのクラス（例えば、特別な権限がユーザに与えられる会員である「プレミアム」ユーザ、これに対しそのような特権のない「レギュラー」ユーザ）、電子商取引のアプリケーションが特定のポータルサイトを介してアクセスしたか否か、ユーザの地理的ロケーション、支払い方法、商品出荷方法、等々、を含むことができる。このような場合、計測は、トランザクションデータが示すコンテキスト、例えば、問題のある商品の種類および／または製造元が含まれているかなどに基づいて条件付けられる。計測は、このようにユーザが参加するトランザクションの一つまたはそれ以上のアスペクト、あるいは一般的に任意のトランザクションのアスペクトに関するコンテキストに条件付けられる。また、本明細書における概念は、Webベースの電子商取引のアプリケーションに限定されることなく、他のWebベースのアプリケーションやWebベースではないアプリケーションをも含めることができる。

この例は、Ｃ４ＡからＣ５に渡されるトランザクションデータがコンテキストと一致することの追加を除いて図４Ｂと同じである。その結果、コンテキストの２つのアスペクトが合致する。１番目のアスペクトは、Ｃ５が呼び出される、例えばＣ５がＣ４Ａによって呼び出される、ときにＣ４Ａが実行されていること、そして、２番目のアスペクトは、Ｃ４ＡによってＣ５に特定のデータが渡されること、である。そのデータは、Ｃ４ＡおよびＣ５が呼び出されたトランザクションのデータオブジェクトである。コンテキストが合致するので、Ｃ５の条件付きの計測が実行される。

図４Ｅは、条件付き計測が発見されたコンポーネントに適用され、条件付き計測の条件が呼び出しシーケンス内の一つのコンポーネントよっては合致するが、トランザクションデータによっては合致しない場合において、図４Ａの呼び出しシーケンスに基づく、呼び出しのスタック位置に対する時間のグラフを示す。この例では、Ｃ４Ａによって呼び出されるＣ５のコンテキストは合致するが、トランザクションデータはコンテキストには合致しない。その結果、コンテキストは合致せず、条件付き計測は実行されないため、領域４３０はグラフには表れない。

図５Ａは、電子商取引のwebサイトで商品を買うトランザクションの別の例で、計測されたコンポーネントおよび発見されたコンポーネントの呼び出しシーケンスを含むものを示す。この例は、図４Ａの例に類似しており、Ｃ５ ４１４の呼び出し可能コンポーネントであるコンポーネントＣ６Ａ ４１６およびＣ６Ｂ ４１８と、Ｃ６Ａの呼び出し可能なコンポーネントとして発見されたコンポーネントＣ６Ａ１ ４４０、Ｃ６Ａ２ ４４２およびＣ６Ａ３ ４４４と、を加えたものである。Ｃ６ＡとＣ６Ｂは、それぞれ、荷送り人Ａまたは荷送り人Ｂを介して商品を出荷するメソッドを表している。Ｃ６Ａ１、Ｃ６Ａ２およびＣ６Ａ３は、出荷部門Ａ１、Ａ２またはＡ３を介して、それぞれ荷送り人Ａに商品を出荷することを表している。この例は、条件付き計測がＣ６Ａ１、Ｃ６Ａ２およびＣ６Ａ３に提供され、静的計測がＣ５、Ｃ６Ａ、Ｃ６Ｂに提供されることを示している。

図５Ｂは、条件付き計測が発見されたコンポーネントに適用され、条件付き計測の条件が呼び出しシーケンス内の３つのコンポーネントによって合致する場合において、図５Ａの呼び出しシーケンスに基づく、呼び出しスタックの位置に対する時間のグラフを示す。このグラフは、この例ではＣ５の領域４３０が静的に計測されているため実線で示されているという点を除いて、図４Ｂのグラフに類似している。また、領域４５０は、Ｃ５によって呼び出されるＣ６Ａを表しており、破線の領域４５２は、Ｃ６Ａから呼び出されるＣ６Ａ１、Ｃ６Ａ２またはＣ６Ａ３を表している。

Ｃ１は、ｔ２においてＣ２を呼び出し、Ｃ２がｔ４において実行を完了する。Ｃ１は、ｔ５においてＣ３Ａを呼び出す。Ｃ３Ａは、ｔ６においてＣ４Ａを呼び出す。Ｃ４Ａは、ｔ７においてＣ５を呼び出す。Ｃ５は、ｔ８においてＣ６Ａを呼び出す。Ｃ６Ａは、ｔ９においてＣ６Ａ１、Ｃ６Ａ２またはＣ６Ａ３を呼び出し、Ｃ６Ａ１、Ｃ６Ａ２またはＣ６Ａ３は、ｔ１５において実行を完了する。Ｃ６Ａは、ｔ１６において実行を完了する。Ｃ５は、ｔ１７において実行を完了する。Ｃ４Ａは、ｔ１８において実行を完了する。Ｃ３Ａは、ｔ１９において実行を完了する。Ｃ１は、ｔ２０においてＣ７を呼び出し、Ｃ７はｔ２４において実行を完了する。Ｃ１がｔ２５において実行を完了するとき、ホストがクライアントにレスポンスを出す。

Ｃ６Ａ１、Ｃ６Ａ２またはＣ６Ａ３の条件付き計測のためのコンテキストは、Ｃ６Ａ１、Ｃ６Ａ２またはＣ６Ａ３が呼び出される前のＣ４Ａ−Ｃ５−Ｃ６Ａのシーケンスを必要とする。そのコンテキストは、また、条件付きで計測されるコンポーネント、すなわち、Ｃ６Ａ１、Ｃ６Ａ２またはＣ６Ａ３が、そのシーケンス内の最後のコンポーネント、すなわちＣ６Ａによって呼び出されることを必要とする。この例では条件が合致し、条件付き計測が実行される。具体的には、Ｃ４Ａ、即ちコンテキスト内の１番目のメソッドは、ｔ６において実行を開始する。Ｃ５、即ちコンテキストの２番目のメソッドは、ｔ７において実行を開始する。Ｃ６Ａ、即ちコンテキストの３番目のメソッドは、ｔ８において実行を開始する。このように、Ｃ６Ａ１、Ｃ６Ａ２またはＣ６Ａ３が呼び出されるとき、シーケンスにおける各コンポーネントが実行する。続いて、コンテキストの３番目、２番目および１番目のメソッドは、ｔ１６、ｔ１７，ｔ１８においてそれぞれ実行を終了する。

図５Ｃは、条件付き計測が発見されたコンポーネントに適用され、条件付き計測の条件が呼び出しシーケンスに合致しない場合において、図５Ａの呼び出しシーケンスに基づく、呼び出しスタックの位置に対する時間のグラフを示す。ここで、領域４２９で表されているＣ４Ｂは、Ｃ４Ａの代わりに呼び出され、Ｃ４Ａ−Ｃ５−Ｃ６Ａのシーケンスを必要とするコンテキストが合致せず、Ｃ６Ａ１、Ｃ６Ａ２、またはＣ６Ａ３の条件付き計測が実行されない。

図５Ｄは、パフォーマンスデータに呼応したコンポーネント間の階層的関係を示すユーザインタフェース表示を示すもので、これにより、ユーザは、条件付きで計測すべきコンポーネントを手動により特定することや、条件付き計測を削除すること、条件付き計測のシーケンス長を特定すること、そしてトランザクションデータに基づいてパフォーマンスデータをフィルタリングすること、が可能となる。当該ユーザインタフェース表示５００は、図５Ａおよび５Ｂの例と一致している。領域５０２の部分５０４は、発見されたコンポーネント、例えば、Ｃ６Ａ１、Ｃ６Ａ２およびＣ６Ａ３の一つまたはそれ以上の名前を特定する。他のコンポーネントの名前も提供することができる。コンポーネントの名称／符号の横にあるチェックボックスは、条件付き計測がコンポーネントに適用されるようにユーザがチェックを付けることができる。ユーザは、例えば、コンポーネントがエラーに関与しているか否か、コンポーネント自身がエラーを起こしていないか、以前のトラブルシューティングの経験やその他の要因の観測に基づいて、ある発見されたコンポーネントに計測を追加すべきかどうかを指示することができる。または、計測は、発見されたコンポーネントに自動的に適用されるようにすることができる。

条件付き計測がコンポーネントに適用されている場合、チェックボックスは、その後、ユーザが計測を削除するために、チェックを外すことができる。領域５０２の部分５０６は、ユーザがドロップダウンウィジェットを使用して条件付き計測のためコンテキスト内のシーケンス長を設定することができる。これは、例えば、発見されたコンポーネントの前に呼び出される連続したコンポーネントの数を表すことができる。一つのアプローチでは、シーケンスの最後のコンポーネントが発見されたコンポーネントを呼び出す。この例では、その長さは、Ｃ４Ａ−Ｃ５−Ｃ６Ａのシーケンスに対応してそれぞれ発見されたコンポーネントに対し、３である。異なるコンポーネントに異なるシーケンス長を与えることができる。シーケンス長を既定レベルに事前設定することも可能である。一般的に、提供されるパフォーマンスデータの量は、シーケンス長を増加させることによって低減することができる。

表示領域５０２の一部分５０７は、例えば、表示領域５１０内の計測に基づいたコンポーネントに対するトレースなどのデータを表示するためユーザが表示領域５０８の一つまたはそれ以上のコンポーネントを選択できること、領域５０８内のコンポーネント名がイタリック体であるものには使用可能なデータがないこと、をユーザに通知する。

表示領域５０８は、コンポーネントが別のコンポーネントの下に示されるツリーのような階層構造を使って、または別のコンポーネントに呼び出されて、アプリケーション内の各コンポーネントが自動的に追加される。この例では、Ｃ６Ａ１はＣ６Ａによって呼び出され、Ｃ６Ａ１の条件付き計測のコンテキストが合致する。その結果、Ｃ６Ａ１のためのパフォーマンスデータ５１６は、マウスまたは他のポインティングデバイスによって領域５０８のツリー内の「Ｃ６Ａ１」がクリックされたとき、使用可能になる。これに対して、Ｃ６Ａにおける他の２つの発見されたコンポーネント、即ちＣ６Ａ２およびＣ６Ａ３はＣ６Ａによって呼び出されない。「Ｃ６Ａ２」および「Ｃ６Ａ３」の名前は、ツリー内にイタリック体で表示され、現在使用可能なパフォーマンスデータがないことが示される。このように、Ｃ６Ａ２およびＣ６Ａ３は、領域５１０内の対応するパフォーマンスデータを見るために、マウスによってクリックするなどしても、ユーザにより選択されることはできない。

表示領域５１０は、領域５０８内のコンポーネントうち選択された一つについて、計測に基づく計測されたコンポーネントのトランザクショントレースなどのパフォーマンスデータを表示している。例えば、コンポーネントＣ１、Ｃ６ＡおよびＣ６Ａ１は、領域５０８においてコンポーネント名がアンダーラインを付して示されているように、現在、ユーザによって選択されており、そして、対応するパフォーマンスデータ、例えば、トランザクショントレースが領域５１０における曲線５１２、５１４、および５１６によって提供される。領域５１０には、エージェントからセントラルマネージャに提供されるパフォーマンスデータを付加することができる。

該当する場合には、領域５１０の一部分５１１では、トランザクションデータによるパフォーマンスデータをユーザにフィルタリングさせることができ、例えば、チェックボックスのチェックを付けたり外したりすることにより、特定のトランザクションデータをそれぞれ含めたり含めなかったりできる。例えば、トランザクションデータ１が現在チェックされているので、曲線５１２、５１４および５１６は、トランザクションデータ１で発生するＣ１、Ｃ６ＡおよびＣ６Ａ１のそれぞれの呼び出しに対してのみ提供される。例として、トランザクションデータは、異なるユーザクラスに関連付けられてもよい。例えば、トランザクションデータ１が「プレミアム」ユーザに関するトランザクションを示し、トランザクションデータ２が「中レベル」（プレミアムとレギュラーの間）のユーザに関するトランザクションを示し、トランザクションデータ３が「レギュラー」ユーザを表す。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一般的に、特定のユーザトランザクションの実行を介してそのユーザトランザクションをフォローすることにより、また、シーケンス、期間、及び、メソッドの実行の順番を報告することにより、トレースはユーザにコードの問題の深い診断を実施させる。しかしながら、現在のアプローチは、メソッドの実行についてトランザクションスコープの内側と外側の区別をしないため、オーバーヘッドやノイズの多い情報をもたらす。さらに、コンテキストを使用することなく、異なるトランザクションに対する報告されたパフォーマンス基準（メトリクス）の軽重を決定することはできない。通常、ユーザは、トランザクショントレースを開始し、トレースされたメソッドの呼び出しから開始して、特定の種類のトランザクションにはパフォーマンスに問題があることを検出する。問題についてのさらなる情報を得るため、ユーザはトレースされたメソッドに条件付きトレーシングを適用することもできる。

ステップ８００は、アプリケーションの実行中に計測されたメソッドからパフォーマンスデータを取得することを含む。ここでは、例えば、図７Ａおよび図７Ｂに関して記載した通り、アプリケーションにロードされたときにどのメソッドが計測されるべきかを決定する静的ルールなどに基づいて既に計測されたメソッドを含めることができる。別のアプローチでは、アプリケーションにロードされた後にメソッドが計測される。詳細は、図８Ｂに記載されている。

ステップ８０２は、パフォーマンスデータに基づき、アプリケーション内における解析するための少なくとも一つの選択されたメソッドを特定することを含む。例えば、図４Ａの例では、解析するメソッドはＣ４ＡまたはＣ４Ｂである。図５Ａの例では、解析するメソッドはＣ６Ａである。詳細は、図８Ｃに記載されている。

ステップ８０４は、解析する少なくとも一つのメソッドの、一つまたはそれ以上の呼び出し可能なメソッドを特定することを含む。詳細は、図８Ｄに記載されている。

ステップ８０６は、一つまたはそれ以上の呼び出し可能なメソッドのコンテキストを特定することを含む。詳細は、図８Ｅに記載されている。

ステップ８０８は、解析する少なくとも一つのメソッド、および／または、解析する少なくとも一つのメソッドを含むコンポーネントのシーケンスの再計測を含む。詳細は、図８Ｇに記載されている。

ステップ８１０は、コンテキストに基づいて、一つまたはそれ以上の呼び出し可能な条件付き計測を有するメソッドを計測することを含む。詳細は、図８Ｈに記載されている。

ステップ８１２は、一つまたはそれ以上の呼び出し可能なメソッドがアプリケーションの実行中に引き続き呼び出され、コンテキストが合致したときに、その一つまたはそれ以上の呼び出し可能なメソッドからパフォーマンスデータを取得することを含む。そのパフォーマンスデータは、条件付き計測を実行することによって取得される。詳細は、図８Ｉに記載されている。

図８Ｂは、図８Ａのステップ８００の詳細を示す。ステップ８１４は、呼び出されたときに、計測されたメソッドがエージェントにパフォーマンスデータを提供することを含む。ステップ８１６は、エージェントがマネージャにパフォーマンスデータを提供することを含む。ユーザインタフェース表示は、前述のように、ステップ８１７で更新される。

図８Ｃは、図８Ａのステップ８０２の詳細を示す。ステップ８１８では、パフォーマンスデータを許容可能なパフォーマンスレベルの範囲と比較する。ステップ８１６では、許容されないパフォーマンスの少なくとも一つのメソッドを特定する。このように、解析する少なくとも一つのメソッドは、パフォーマンスデータに基づき特定される。パフォーマンスデータは、例えば、その少なくとも一つのメソッドのパフォーマンの問題を示している。この特定は、例えば、継続的に、パフォーマンスデータを監視し、ユーザインターフェース上でユーザに報告を提供することによって、実行される。範囲外のパフォーマンスデータには、予め定められた範囲との比較に基づいて、自動的にフラグが設定される。ユーザは、次に、計測すべき一つまたはそれ以上のメソッドを手動により選択する。他の可能なアプローチでは、処理は完全に自動化されており、ユーザの介入を必要としない。それゆえ、特定されたメソッドは、そのパフォーマンスデータが、パフォーマンスが特定のパフォーマンスレベルを下回っていることや、あるいは重要なものであることを示すときに、自動的に計測される。

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

ステップ８２２は、解析する少なくとも一つのメソッドのクラスをリフレクションを介して決定する。一つの可能性ある実装では、このことはJavaアプリケーションプログラミングインタフェース（ＡＰＩ）、java.lang.instrument（ステップ８２４）の使用を含む。解析する少なくとも一つのメソッドは、それが一つまたはそれ以上の呼び出し可能なメソッドを起動したり呼び出したりすることから、呼び出しメソッドであると考えられる。ステップ８２２には、メモリ内、例えばＪＶＭ内のすべてのロードされたクラスの中からJavaクラスをフェッチすることを含めてもよい。

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

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

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

ステップ８３４では、一つまたはそれ以上の呼び出しバイトコードのインスタンスに基づいて、一つまたはそれ以上の呼び出し可能なメソッドを特定する。実装例では、一つまたはそれ以上の呼び出し可能なメソッドは、ステップ８２２で決定されるクラスの定数プールから抽出される。特に、ステップ８３６では、オペコードに基づき定数プールテーブル内のエントリに対するインデックスを特定し、ステップ８３８では、その一つまたはそれ以上のインデックスに基づき、参照されるメソッドを特定する。ステップ８４０では、一つまたはそれ以上の呼び出し可能なメソッドを、文字列としてキャシュに格納する。そのメソッドは、一つまたはそれ以上の参照されるメソッドであって、例えばdoSomething()のために呼び出されるメソッドである。図８Ｄの処理は、同時に、または、異なる時間に、複数の異なるメソッドに対して個別に実行可能であることに留意されたい。

図８Ｅは、図８Ａのステップ８０６の詳細を示す。ステップ８４２は、解析する少なくとも一つのメソッドおよび／または解析する少なくとも一つのメソッドを含むシーケンスといったメソッドのシーケンスを特定することを含む。このことは、図５Ｄのユーザインタフェース表示５００の領域５０８においてユーザへの報告に使用されるのと同じパフォーマンスデータを使用して行なわれることが可能である。基本的に、各メソッドは、解析する少なくとも一つのメソッドを呼び出すようにつながるメソッドのシーケンスにおけるインスツルメンテーション（計測）から知られている。例えば、図５Ｄにおいて、もしＣ６Ａが解析するメソッドであれば、次の低いレベルにツリーを辿ることで、Ｃ６Ａ１、Ｃ６Ａ２およびＣ６Ａ３を条件付き計測が追加されたメソッドであることが判明する。さらに、それぞれの高いレベルへツリーを辿ると、シーケンス長が２コンポーネント／メソッドのときは解析する少なくとも一つのメソッドを含むメソッドのシーケンスはＣ５−Ｃ６Ａであり、シーケンス長が３コンポーネント／メソッドのときはＣ４Ａ−Ｃ５−Ｃ６Ａであり、シーケンス長が４コンポーネント／メソッドのときはＣ３Ａ−Ｃ４Ａ−Ｃ５−Ｃ６Ａである、等々が判明する。ステップ８４４は、解析する少なくとも一つのメソッドに関連付けられている、および／または、解析する少なくとも一つのメソッドを含むシーケンスといったメソッドのシーケンスに関連付けられているトランザクションデータを特定することを含む。上記の例では、当該トランザクションデータがユーザの分類を示すことがある。また、多くの別の種類のトランザクションデータが可能である。一つの可能な実装において、トランザクションデータは、特定のデータフィールド内にあり、それは一つまたはそれ以上のアプリケーション内のメソッドの間で渡されたものである。例えば、ユーザからのリクエストは、UserClass=premiumというデータフィールドおよび値を有することができる。UserClass=premiumは、条件付き計測によって解析されるトランザクションデータとすることができる。UserClass=premiumの場合、コンテキストが合致する。UserClass=mediumまたはUserClass=regularの場合、コンテキストは合致しない。

図８Ｆは、図８Ａのステップ８０８の詳細を示す。ステップ８４６は、解析する少なくとも一つのメソッドのクラス、および／または、解析する少なくとも一つのメソッドを含むシーケンスのようなメソッドのシーケンスに、各メソッドの開始と終了での条件付きアンカーを有するように再定義することを含む。クラスの再定義は、図１０にて詳しく説明される。条件付きアンカーは、図８Ｉおよび図８Ｊにて詳しく説明される。ステップ８４８は、一つまたはそれ以上の再定義されたクラスをロードすることを含む（図１０も参照のこと）。ステップ８５０は、一つまたはそれ以上の再定義されたクラスに基づくバイトコード計測を提供することを含む（図１０も参照のこと）。

図８Ｇは、図８Ａのステップ８１０の詳細を示す。ステップ８５２は、条件が一致するかどうかを決定するためにスレッドローカルキャッシュのようなメモリリソースをチェックする条件付き計測を含むように、一つまたはそれ以上の呼び出し可能なメソッドを再定義することを含む。ステップ８５４は、一つまたはそれ以上の再定義されたクラスをロードすることを含む。ステップ８５６は、一つまたはそれ以上の再定義されたクラスに基づくバイトコード計測を提供することを含む。

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

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

図８Ｉは、図８Ａのステップ８１２の詳細を示す。ステップ８６４では、コンテキストの最初のメソッドが呼び出される。いくつかのケースでは、コンテキストが、解析されているメソッドが条件付き計測を伴うメソッドを呼び出すことを要求するだけの場合のように、コンテキスト内にはたった一つのメソッドのみが存在する場合がある。他のケースでは、コンテキストは、条件付きの計測を伴うメソッドが呼び出される前に、特定のシーケンスまたは一連のメソッドの呼び出しを要求する。ステップ８６６では、コンテキストの最初のメソッドの開始時の条件付きのアンカーが実行され、そのメソッドが実行を開始したことをスレッドローカルキャッシュに通知する。その最初のメソッドは、必ずしもコンテキスト内でのメソッドのシーケンスにおけるその位置を示す必要はない（例えば、１番目、２番目…）。詳細については、図８Ｊを参照されたい。条件付きアンカーは、メソッドの計測におけるコードによって提供され得る。メソッドは、その計測を通して、エージェントにパフォーマンスデータも提供する。パフォーマンスデータは、単にそのメソッドが実行開始したことを示すだけの場合がある。判断ステップ８６８では、コンテキスト内に次のメソッドがある場合、次のメソッドがステップ８７０にて呼び出される。コンテキストの次のメソッドの開始時における条件付きアンカーが実行され、そのメソッドが実行を開始したことをスレッドローカルキャッシュに通知する。判断ステップ８６８にて、コンテキスト内に次のステップがない場合には、ステップ８７２にて、一つまたはそれ以上の呼び出し可能メソッドが呼び出される。解析されているメソッドは、条件付き計測を伴う一つまたは複数のメソッドを呼び出すことができることに留意されたい。

ステップ８７６では、そのコンテキストにないメソッドが実行されたときに、ステップ８７２に代替パスを提供する。

ステップ８７４では、ステップ８７２にて呼び出された一つまたはそれ以上の呼び出し可能なメソッドの条件付き計測がスレッドローカルキャッシュをチェックし、コンテキストが一致しているか否かを決定する。図８Ｊも参照されたい。

コンテキストが一致しない場合、例えば、ステップ８７６がステップ８８０の判断ステップで呼び出されるとき、一つまたはそれ以上の呼び出し可能なメソッドの条件付き計測は実行されない（ステップ８７８）。判断ステップ８８０でコンテキストが一致する場合、一つまたはそれ以上の呼び出し可能メソッドの条件付き計測はステップ８８２において実行され、パフォーマンスデータがエージェントに提供される。このように、条件付き計測がコンテキスト内で少なくとも一つの呼び出し可能メソッドが呼び出されると判断する場合、その条件付き計測は、その少なくとも一つの呼び出し可能なメソッドの実行について報告する。同様に、条件付き計測がコンテキスト内で少なくとも一つの呼び出し可能メソッドが呼び出されないと判断する場合、その条件付き計測は、その少なくとも一つの呼び出し可能なメソッドの実行についての報告を行わない。

ステップ８８４では、コンテキスト内の最後のメソッドの終了時の条件付きアンカーが実行され、そのメソッドが実行を停止したことをスレッドローカルキャッシュに通知する。判断ステップ８８６において、コンテキスト内に別のメソッドがあるときには、ステップ８８８にてコンテキスト内の次のメソッドの終了時の条件付きアンカーが実行され、そのメソッドが実行を停止したことをスレッドローカルキャッシュに通知する。判断ステップ８８６にてコンテキスト内に次のメソッドがないときには、ステップ８９０において、コンテキスト外でアプリケーションの実行が継続する。このことは、例えば、マネージャにパフォーマンスデータを提供するエージェント、または、ステップ８９２にて更新されたユーザインタフェース表示を含むことが可能であるが、これらのアクティビティも同様にコンテキスト内での実行中に発生する可能性がある。

図８Ｊは、スレッドローカルキャッシュに関連したアクティビティで、図５Ｂと図８Ｉに関するものを示す。 スレッドローカルキャッシュは、アプリケーションにて使用可能なメモリリソースであってよく、より高速なアクセスのためにそのアプリケーションでのみ使えるものとしてよい。スレッドローカルキャッシュは、コンテキスト内のメソッドの計測によって提供された情報を格納することができ、リクエストに応じて情報を条件付き計測へ提供する。図５Ｂも参照すると、Ｃ６Ａ１の条件付き計測に対してＣ４Ａ−Ｃ５−Ｃ６Ａのシーケンスを必要とするコンテキストの例が挙げられている。ｔ６において、Ｃ４Ａは実行を開始し、Ｃ４Ａの計測の条件付きのアンカー／コードはメッセージをスレッドローカルキャッシュへ送る。そのメッセージは、当該メソッドの識別子／名前、例えばMethodName=C4A、及び、実行ステータス、例えば、Execution Status=Executing、を含む。この情報は、そのメソッドが実行中であることの指標としてスレッドローカルキャッシュに格納される。同様に、ｔ７において、Ｃ５は実行を開始し、Ｃ５の計測の条件付きのアンカー／コードはメッセージをスレッドローカルキャッシュへ送る。そのメッセージは、当該メソッドの識別子／名前、例えばMethodName=C5、及び、実行ステータス、例えばExecution Status=Executing、を含む。この情報は、スレッドローカルキャッシュに格納される。ｔ８において、Ｃ６Ａは実行を開始し、Ｃ６Ａの計測の条件付きのアンカー／コードはメッセージをスレッドローカルキャッシュへ送る。そのメッセージは、当該メソッドの識別子／名前、例えばMethodName=C6A、及び、実行ステータス、例えばExecution Status=Executing、を含む。この情報は、スレッドローカルキャッシュに格納される。

ｔ９において、Ｃ６Ａ１がＣ６Ａによって呼び出されるとき、Ｃ６Ａ１の条件付き計測はスレッドローカルキャッシュにリクエストを送り、一つまたはそれ以上の特定のメソッドの実行ステータスを読み出す。これは、一つまたはそれ以上のメソッドが実行中であることの一つまたはそれ以上の指標にアクセスするためのメモリリソースからのリクエストである。このリクエストは、MethodName=C4A, C5 and C6A に対する疑似コード：RetrieveExecutionStatusによって表される。Ｃ６Ａ１の条件付き計測は、この情報にアクセスし、それを使ってコンテキストが一致しているか否かを判断する。上述したように、付加的にまたは代替として、コンテキストが一致しているか否かを判断するのにトランザクションデータがＣ６Ａ１の条件付き計測によって使用されることもある。一つの可能性のある実装において、トランザクションデータはＣ６ＡによってＣ６Ａ１の条件付き計測に渡され、これによって、Ｃ６Ａ１の条件付き計測がスレッドローカルキャッシュからトランザクションデータにアクセスしないようにすることができる。しかしながら、トランザクションデータが、コンテキスト内のメソッドによって提供され、コンテキストに合致しているかどうかを決定するのに条件付き計測によってアクセスされるようにすることも可能である。コンテキストは一致しているとＣ６Ａ１の条件付き計測が判断するとき、Ｃ６Ａ１の条件付き計測は、少なくとも一つの呼び出し可能なメソッドの実行に関する報告を行う。この実行は、Ｃ４Ａ、Ｃ５およびＣ６Ａからアクセスされた一つまたはそれ以上の指標の少なくとも一部に基づいている。

続いて、コンテキスト内のメソッドが続けて実行を停止する。ｔ１６において、Ｃ６Ａは実行を停止し、Ｃ６Ａの計測の２番目の条件付きアンカー／コードはスレッドローカルキャッシュへメッセージを送信する。そのメッセージは、当該メソッドの識別子／名前、例えばMethodName=C6A、及び、実行ステータスを削除／消去するリクエスト、例えばRemove ExecutionStatus、を含む。または、リクエストは、ExecutionStatus=NotExecutingという実行ステータスを設定するために送られるものであってもよい。ｔ１７において、Ｃ５は実行を停止し、Ｃ５の計測の２番目の条件付きアンカー／コードはスレッドローカルキャッシュへメッセージを送信する。そのメッセージは、当該メソッドの識別子／名前、例えばMethodName=C5、及び、リクエストRemove ExecutionStatus、を含む。ｔ１８において、Ｃ４Ａは実行を停止し、Ｃ４Ａの計測の２番目の条件付きアンカー／コードは、スレッドローカルキャッシュへメッセージを送信する。そのメッセージは、当該メソッドの識別子／名前、例えばMethodName=C4A、及び、リクエストRemove ExecutionStatus、を含む。

条件付きアンカーは、メソッドの開始と終了にて、コンテキスト内でトレースされるメソッドのバイトコードに付加されるトレーサーである。トレーサーは２つの動作を実行する。即ち、メソッドが呼び出されて実行を開始したときに呼ばれたという事実を、例えばマップのようなデータ構造で、スレッドローカルキャッシュに格納することと、そのメソッドの終了時にその情報を削除することである。条件付きアンカーの使用によって発生するオーバーヘッドは最小限である。一つの可能なアプローチでは、条件付きアンカーのトレーサーは一定のアクセス時間でマップ構造を更新する。そのマップは、スレッドローカルキャッシュ内にあるので競合がない。同様に、条件付き計測の使用によって発生するオーバーヘッドは最小限である。

スレッドローカルキャッシュに代わるものとして、メソッドの条件付き計測は、コンテキストが一致するかどうかを判断するのに、メソッドの呼び出し時に、呼び出しスタックを解析することもよい。上述したように、呼び出しスタックは、一つまたはそれ以上のプログラムまたはスレッドの実行中に呼び出された、又は起動されたメソッドを特定する。このアプローチでは、そのメソッドは、呼び出しスタックが、コンテキストが一致していることを示しているかどうかを判断する。スレッドローカルキャッシュの使用は、スタックの深さに応じて大幅にアクセス時間が長くなってしまうスタック調査が必要ないので、より効率的である。

図９は、９００でまとめて示しているが、図８Ｄのメソッドに関連して使用されるソフトウェアおよびハードウェアを示す。ハードウェアは、メモリリソースである、動的計測キャッシュ９０２およびスレッドローカルキャッシュ９０４（図８Ｊを参照）と、その他のメモリリソース９１５を含む。スレッドローカルキャッシュは、スレッドに専用の静的またはグローバルなメモリリソースである。Javaでは、スレッドローカル変数はThreadLocalクラスにて実装される。ThreadLocalオブジェクトは、オブジェクトのgetメソッドまたはsetメソッドを呼び出すスレッドごとに、変数の別々のインスタンスを保持する。

動的計測キャッシュは、解析されているメソッドに対して特定された呼び出し可能なメソッドを格納する。その呼び出し可能なメソッドは、同じメソッドの解析が続けて行われる場合、キャッシュから直ちに特定することができ、これにより、コンピューティングリソースの消費量の削減が可能となる。リソース９１５は、アプリケーションが実行され計測されるときにメモリにロードされるアプリケーションの異なるクラスのバイトコードを格納するのに使用される記憶場所となり得る。一つの可能性のある実装において、動的計測キャッシュ９０２およびリソース９１５は、アプリケーションサーバ内の図２のメモリ２４０内に用意される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims (25)

1. アプリケーションを計測するためにコンピュータに実装される方法であり、該コンピュータに実装された以下のステップ：
   計測されるメソッド（Ｃ１−Ｃ７）を含んでいる計測されるコンポーネントのベースラインの規定により該アプリケーションのコードを構成すること、該アプリケーションの該コードは未計測のメソッド（Ｃ４Ａ）も含む；
   コンピュータシステムにおいて該アプリケーションの該コードを実行している最中に、該計測されるメソッドからパフォーマンスデータを取得すること；
   該パフォーマンスデータに基づいて、さらに詳細に解析するために該計測されるメソッド（Ｃ４Ａ）の少なくとも一つを選択すること；
   該選択に基づいて、該少なくとも一つの選択されて計測されるメソッドによって呼び出され得る未計測の少なくとも一つの呼び出し可能なメソッド（Ｃ５）を決定すること；および
   該決定に対応して、該少なくとも一つの呼び出し可能なメソッドのための該アプリケーションの該コードを、条件付き計測を伴うように構成すること、該少なくとも一つの呼び出し可能なメソッドが呼び出される場合に条件付き計測が起動される予定のコンテキストを該条件付き計測が特定すること、該コンテキストは、少なくとも一つの選択されて計測されるメソッドによって呼び出される該少なくとも一つの呼び出し可能なメソッドを含むこと；および
   該コンピュータシステムにおいて該条件付き計測を伴う該アプリケーションの該コードを実行している最中に、該少なくとも一つの呼び出し可能なメソッドが呼び出される場合、該少なくとも一つの呼び出し可能なメソッドが該コンテキスト内で呼び出されるかどうかを決定し、該少なくとも一つの呼び出し可能なメソッドが該コンテキスト内で呼び出される場合、該少なくとも一つの呼び出し可能なメソッドからパフォーマンスデータを取得するために該条件付き計測を起動すること；
   を有する方法。
2. 該少なくとも一つの呼び出し可能なメソッドが呼び出されるが該コンテキスト内では呼び出されない場合に、該条件付き計測を起動しないこと、をさらに有する請求項１に記載のコンピュータに実装される方法。
3. スレッドローカルキャッシュが該アプリケーションの一つまたはそれ以上の実行しているメソッドを特定することができるように、該少なくとも一つの選択されて計測されるメソッドが実行を開始および停止する場合、該少なくとも一つの選択されて計測されるメソッドがスレッドローカルキャッシュに報告するために該少なくとも一つの選択されて計測されるメソッドの計測を変更すること、をさらに有する請求項２に記載のコンピュータに実装される方法。
4. 該条件付き計測は、該コンテキストを満たして実行されるために必要となる該少なくとも一つの選択されて計測されるメソッドを含む、一つまたはそれ以上のメソッドを特定し、
   該少なくとも一つの呼び出し可能なメソッドがコンテキスト内で呼び出されるか否かを決定することは、該一つまたはそれ以上のメソッドが実行中か否かを判断するためにスレッドローカルキャッシュにアクセスする該条件付き計測を含む請求項３に記載のコンピュータに実装される方法。
5. 該条件付き計測は、該コンテキストを満たして実行をするように要求されるメソッドのシーケンスを特定し、該メソッドのシーケンスは、少なくとも一つの選択されて計測されるメソッドおよび該少なくとも一つの選択されて計測されるメソッドの親メソッドを含み、
   該少なくとも一つの呼び出し可能なメソッドがコンテキスト内で呼び出されるか否かを決定することは、該メソッドのシーケンスが実行中か否かを判断するためにスレッドローカルキャッシュにアクセスする該条件付き計測を含む請求項４に記載のコンピュータに実装される方法。
6. 条件付き計測を伴う該アプリケーションの該コードは、ユーザに対するトランザクションを行うように実行され、該条件付き計測は、該コンテキストを満たすように要求される特定のトランザクションデータであって、発注する商品の種類、商品の製造元の特定、購入するユーザのクラス、該アプリケーションが特定のポータルサイトを介してアクセスしたか否か、該ユーザの地理的ロケーション、支払い方法、および商品出荷方法、のうちの少なくとも一つを含むものを特定する、請求項５に記載のコンピュータに実装される方法。
7. 該特定されたトランザクションデータは、内部コンポーネントのメッセージのヘッダーにデータオブジェクトの特定値を含む、請求項６に記載のコンピュータに実装される方法。
8. 該メソッドのシーケンスの長さをユーザが特定することを許容するユーザインタフェースディスプレィ（２５０，５００）を提供すること、をさらに有する、請求項５から７のいずれか１項に記載のコンピュータに実装される方法。
9. （ａ）該少なくとも一つの呼び出し可能なメソッドの条件付き計測を提供すること、および、（ｂ）該少なくとも一つの呼び出し可能なメソッドの条件付き計測を削除すること、のうちの少なくとも一つのコマンドをユーザに提供することを許容するユーザインタフェースディスプレィを提供すること、をさらに有する請求項１から８のいずれか１項に記載のコンピュータに実装される方法。
10. 該計測されるコンポーネントの該ベースラインの規定により該アプリケーションのコードを設定することは、仮想マシンに該アプリケーションの該コードをロードすることと、該アプリケーションの該コードにプローブを追加すること、を有し、
    該少なくとも一つの呼び出し可能なメソッドの条件付き計測により該アプリケーションの該コードを設定することは、該仮想マシンに該少なくとも一つの呼び出し可能なメソッドの該アプリケーションの該コードをリロードすることと、該少なくとも一つの呼び出し可能なメソッドの該アプリケーションの該コードにプローブを追加すること、を有する請求項１から９のいずれか１項に記載のコンピュータに実装される方法。
11. 該仮想マシンは、オペレーティングシステム上に構築されている実行環境の一部であり、該オペレーティングシステムがハードウェア上で構築されている、請求項１０のいずれか１項に記載のコンピュータに実装される方法。
12. 該少なくとも一つの呼び出し可能なメソッドの条件付き計測により該アプリケーションの該コードを設定することは、条件付き計測を含むための該少なくとも一つの呼び出し可能なメソッドの一つまたはそれ以上のクラスを再定義することと、該仮想マシンに一つまたはそれ以上の再定義されたクラスをロードすること、を有する請求項１から１１のいずれか１項に記載の方法。
13. 該計測されるメソッドの該パフォーマンスデータは、該計測されるメソッドの開始および停止の回数を含み、
    該少なくとも一つの呼び出し可能なメソッドからのパフォーマンスデータは、少なくとも一つの呼び出し可能なメソッドの開始および停止の回数を含む、請求項１から１２のいずれか１項に記載のコンピュータに実装される方法。
14. 少なくとも一つの選択されて計測されるメソッドおよび少なくとも一つの呼び出し可能なメソッドのパフォーマンスデータを図示するユーザインタフェースディスプレィを提供すること、をさらに有する請求項１から１３のいずれか１項に記載のコンピュータに実装される方法。
15. さらに詳細に解析するために該少なくとも一つのメソッドを選択することが自動的に行われる、請求項１からの１４のいずれか１項に記載のコンピュータに実装される方法。
16. さらに詳細に解析するために該少なくとも一つのメソッドを選択することは、ユーザインタフェース（２５０，５００）を介するユーザコマンドに基づいて行われる、請求項１から１５のいずれか１項に記載のコンピュータに実装される方法。
17. 該条件付き計測は、該アプリケーションの実行中に、該少なくとも一つの呼び出し可能なメソッドに対して動的に提供される、請求項１から１６のいずれか１項に記載のコンピュータに実装される方法。
18. 少なくとも一つのプロセッサがアプリケーションの計測をするための方法を実行するようにプログラムするために具現化されたコンピュータで読み取り可能なソフトウェアを有しているコンピュータで読み取り可能な有体の記憶装置であり、該方法は、
    計測されるメソッド（Ｃ１−Ｃ７）を含んでいる計測されるコンポーネントのベースラインの規定により該アプリケーションのコードを構成すること、該アプリケーションの該コードは未計測のメソッド（Ｃ４Ａ）も含む；
    コンピュータシステムにおいて該アプリケーションの該コードを実行している最中に、該計測されるメソッドからパフォーマンスデータを取得すること；
    該パフォーマンスデータに基づいて、さらに詳細に解析するために該計測されるメソッド（Ｃ４Ａ）の少なくとも一つを選択すること；
    該選択に基づいて、該少なくとも一つの選択されて計測されるメソッドによって呼び出され得る未計測の少なくとも一つの呼び出し可能なメソッド（Ｃ５）を決定すること；
    該決定に対応して、該少なくとも一つの呼び出し可能なメソッドのための該アプリケーションの該コードを条件付き計測を伴うように構成すること、該少なくとも一つの呼び出し可能なメソッドが呼び出される場合、該条件付き計測が起動にされる予定のコンテキストを該条件付き計測が特定し、該コンテキストは少なくとも一つの選択されて計測されるメソッドによって呼び出される該少なくとも一つの呼び出し可能なメソッドを含むこと；および
    該コンピュータシステムにおいて該条件付き計測を伴う該アプリケーションの該コードを実行している最中に、該少なくとも一つの呼び出し可能なメソッドが呼び出される場合、該少なくとも一つの呼び出し可能なメソッドが該コンテキスト内で呼び出されるかどうかを決定し、該少なくとも一つの呼び出し可能なメソッドが該コンテキスト内で呼び出される場合、少なくとも一つの呼び出し可能なメソッドからパフォーマンスデータを取得するために該条件付き計測を起動すること、
    を含むことを特徴とする記憶装置。
19. 該条件付き計測は、該コンテキストを満たして実行をするように要求されるメソッドのシーケンスを特定し、該メソッドのシーケンスは、少なくとも一つの選択されて計測されるメソッドおよび該少なくとも一つの選択されて計測されるメソッドの親メソッドを含み、
    該少なくとも一つの呼び出し可能なメソッドがコンテキスト内で呼び出されるか否かを決定することは、該メソッドのシーケンスが実行中か否かを判断するためにスレッドローカルキャッシュにアクセスする該条件付き計測を含む、請求項１８に記載のコンピュータで読み取り可能な有体の記憶装置。
20. 該メソッドのシーケンスの長さをユーザが特定することを許容するユーザインタフェースディスプレィ（２５０，５００）を提供すること、をさらに有する、請求項１９に記載のコンピュータで読み取り可能な有体の記憶装置。
21. 条件付計測を伴う該アプリケーションの該コードは、ユーザに対するトランザクションを行うように実行され、該条件付き計測は、該コンテキストを満たすように要求される特定のトランザクションデータであって、発注する商品の種類、商品の製造元の特定、購入するユーザのクラス、該アプリケーションが特定のポータルサイトを介してアクセスしたか否か、該ユーザの地理的ロケーション、支払い方法、および商品出荷方法、のうちの少なくとも一つを含むものを特定する、請求項１８から２０のいずれか１項に記載のコンピュータで読み取り可能な有体の記憶装置。
22. ソフトウェアの命令を格納する記憶装置と、
    作業メモリであって、該ソフトウェアの命令が該記憶装置からロードされている作業メモリと、
    該ソフトウェアの命令を実行するプロセッサと、を備えており、該ソフトウエアの命令が、
    計測されるメソッド（Ｃ１−Ｃ７）を含んでいる計測されるコンポーネントのベースラインの規定によりアプリケーションのコードを設定すること、該アプリケーションの該コードは計測されていないメソッド（Ｃ４Ａ）も含む；
    該コンピュータシステムにおいて該アプリケーションの該コードを実行している最中に、該計測されるメソッドからパフォーマンスデータを取得すること；
    該パフォーマンスデータに基づいて、さらに詳細に解析するために少なくとも一つの該計測されるメソッド（Ｃ４Ａ）を選択すること；
    該選択に基づいて、該少なくとも一つの選択されたメソッドによって呼び出され得る未計測の少なくとも一つの呼び出し可能なメソッド（Ｃ５）を決定すること；
    該決定に対応して、該少なくとも一つの呼び出し可能なメソッドのための該アプリケーションの該コードを、条件付き計測を伴うように構成すること、その中で、該少なくとも一つの呼び出し可能なメソッドが呼び出される場合、該条件付き計測が起動される予定のコンテキストを該条件付き計測が特定し、該コンテキストは少なくとも一つの選択されて計測されるメソッドによって呼び出される該少なくとも一つの呼び出し可能なメソッドを含むこと、；および
    該コンピュータシステムにおいて該条件付き計測を伴う該アプリケーションの該コードが実行される最中に、該少なくとも一つの呼び出し可能なメソッドが呼び出される場合、該少なくとも一つの呼び出し可能なメソッドが該コンテキスト内で呼び出されるかどうかを決定し、該少なくとも一つの呼び出し可能なメソッドが該コンテキスト内で呼び出される場合、少なくとも一つの呼び出し可能なメソッドからパフォーマンスデータを取得するために該条件付き計測を起動すること、
    を含むことを特徴とするコンピュータシステム。
23. 該条件付き計測は、該コンテキストを満たして実行をするように要求されるメソッドのシーケンスを特定し、該メソッドのシーケンスは、少なくとも一つの選択されて計測されるメソッドおよび該少なくとも一つの選択されて計測されるメソッドの親メソッドを含み、
    該少なくとも一つの呼び出し可能なメソッドがコンテキスト内で呼び出されるか否かを決定することは、該メソッドのシーケンスが実行中か否かを判断するためにスレッドローカルキャッシュにアクセスする該条件付き計測を含む、請求項２２に記載のコンピュータシステム。
24. 前記ソフトウエアの命令が、
    該メソッドのシーケンスの長さをユーザが特定することを許容するユーザインタフェースディスプレィ（２５０，５００）を提供すること、をさらに含む、請求項２３のコンピュータシステム。
25. 条件付計測を伴う該アプリケーションの該コードは、ユーザに対するトランザクションを行うように実行され、該条件付き計測は、該コンテキストを満たすように要求される特定のトランザクションデータであって、発注する商品の種類、商品の製造元の特定、購入するユーザのクラス、該アプリケーションが特定のポータルサイトを介してアクセスしたか否か、該ユーザの地理的ロケーション、支払い方法、および商品出荷方法、のうちの少なくとも一つを含むものを特定する、請求項２２から２４のいずれか１項に記載のコンピュータシステム。

Images