"アプリケーションを計測するためにコンピュータに実装される方法であり、該コンピュータに実装された以下のステップ:計測されるメソッドC1-C7を含んでいる計測されるコンポーネントのベースラインの規定により該アプリケーションのコードを構成すること、該アプリケーションの該コードは未計測のメソッドC4Aも含む;コンピュータシステムにおいて該アプリケーションの該コードを実行している最中に、該計測されるメソッドからパフォーマンスデータを取得すること;該パフォーマンスデータに基づいて、さらに詳細に解析するために該計測されるメソッドC4Aの少なくとも一つを選択すること;該選択に基づいて、該少なくとも一つの選択されて計測されるメソッドによって呼び出され得る未計測の少なくとも一つの呼び出し可能なメソッドC5を決定すること;および該決定に対応して、該少なくとも一つの呼び出し可能なメソッドのための該アプリケーションの該コードを、条件付き計測を伴うように構成すること、該少なくとも一つの呼び出し可能なメソッドが呼び出される場合に条件付き計測が起動される予定のコンテキストを該条件付き計測が特定すること、該コンテキストは、少なくとも一つの選択されて計測されるメソッドによって呼び出される該少なくとも一つの呼び出し可能なメソッドを含むこと;および該コンピュータシステムにおいて該条件付き計測を伴う該アプリケーションの該コードを実行している最中に、該少なくとも一つの呼び出し可能なメソッドが呼び出される場合、該少なくとも一つの呼び出し可能なメソッドが該コンテキスト内で呼び出されるかどうかを決定し、該少なくとも一つの呼び出し可能なメソッドが該コンテキスト内で呼び出される場合、該少なくとも一つの呼び出し可能なメソッドからパフォーマンスデータを取得するために該条件付き計測を起動すること;を有する方法。該少なくとも一つの呼び出し可能なメソッドが呼び出されるが該コンテキスト内では呼び出されない場合に、該条件付き計測を起動しないこと、をさらに有する請求項1に記載のコンピュータに実装される方法。スレッドローカルキャッシュが該アプリケーションの一つまたはそれ以上の実行しているメソッドを特定することができるように、該少なくとも一つの選択されて計測されるメソッドが実行を開始および停止する場合、該少なくとも一つの選択されて計測されるメソッドがスレッドローカルキャッシュに報告するために該少なくとも一つの選択されて計測されるメソッドの計測を変更すること、をさらに有する請求項2に記載のコンピュータに実装される方法。該条件付き計測は、該コンテキストを満たして実行されるために必要となる該少なくとも一つの選択されて計測されるメソッドを含む、一つまたはそれ以上のメソッドを特定し、該少なくとも一つの呼び出し可能なメソッドがコンテキスト内で呼び出されるか否かを決定することは、該一つまたはそれ以上のメソッドが実行中か否かを判断するためにスレッドローカルキャッシュにアクセスする該条件付き計測を含む請求項3に記載のコンピュータに実装される方法。該条件付き計測は、該コンテキストを満たして実行をするように要求されるメソッドのシーケンスを特定し、該メソッドのシーケンスは、少なくとも一つの選択されて計測されるメソッドおよび該少なくとも一つの選択されて計測されるメソッドの親メソッドを含み、該少なくとも一つの呼び出し可能なメソッドがコンテキスト内で呼び出されるか否かを決定することは、該メソッドのシーケンスが実行中か否かを判断するためにスレッドローカルキャッシュにアクセスする該条件付き計測を含む請求項4に記載のコンピュータに実装される方法。条件付き計測を伴う該アプリケーションの該コードは、ユーザに対するトランザクションを行うように実行され、該条件付き計測は、該コンテキストを満たすように要求される特定のトランザクションデータであって、発注する商品の種類、商品の製造元の特定、購入するユーザのクラス、該アプリケーションが特定のポータルサイトを介してアクセスしたか否か、該ユーザの地理的ロケーション、支払い方法、および商品出荷方法、のうちの少なくとも一つを含むものを特定する、請求項5に記載のコンピュータに実装される方法。該特定されたトランザクションデータは、内部コンポーネントのメッセージのヘッダーにデータオブジェクトの特定値を含む、請求項6に記載のコンピュータに実装される方法。該メソッドのシーケンスの長さをユーザが特定することを許容するユーザインタフェースディスプレィ250,500を提供すること、をさらに有する、請求項5から7のいずれか1項に記載のコンピュータに実装される方法。a該少なくとも一つの呼び出し可能なメソッドの条件付き計測を提供すること、および、b該少なくとも一つの呼び出し可能なメソッドの条件付き計測を削除すること、のうちの少なくとも一つのコマンドをユーザに提供することを許容するユーザインタフェースディスプレィを提供すること、をさらに有する請求項1から8のいずれか1項に記載のコンピュータに実装される方法。該計測されるコンポーネントの該ベースラインの規定により該アプリケーションのコードを設定することは、仮想マシンに該アプリケーションの該コードをロードすることと、該アプリケーションの該コードにプローブを追加すること、を有し、該少なくとも一つの呼び出し可能なメソッドの条件付き計測により該アプリケーションの該コードを設定することは、該仮想マシンに該少なくとも一つの呼び出し可能なメソッドの該アプリケーションの該コードをリロードすることと、該少なくとも一つの呼び出し可能なメソッドの該アプリケーションの該コードにプローブを追加すること、を有する請求項1から9のいずれか1項に記載のコンピュータに実装される方法。該仮想マシンは、オペレーティングシステム上に構築されている実行環境の一部であり、該オペレーティングシステムがハードウェア上で構築されている、請求項10のいずれか1項に記載のコンピュータに実装される方法。該少なくとも一つの呼び出し可能なメソッドの条件付き計測により該アプリケーションの該コードを設定することは、条件付き計測を含むための該少なくとも一つの呼び出し可能なメソッドの一つまたはそれ以上のクラスを再定義することと、該仮想マシンに一つまたはそれ以上の再定義されたクラスをロードすること、を有する請求項1から11のいずれか1項に記載の方法。該計測されるメソッドの該パフォーマンスデータは、該計測されるメソッドの開始および停止の回数を含み、該少なくとも一つの呼び出し可能なメソッドからのパフォーマンスデータは、少なくとも一つの呼び出し可能なメソッドの開始および停止の回数を含む、請求項1から12のいずれか1項に記載のコンピュータに実装される方法。少なくとも一つの選択されて計測されるメソッドおよび少なくとも一つの呼び出し可能なメソッドのパフォーマンスデータを図示するユーザインタフェースディスプレィを提供すること、をさらに有する請求項1から13のいずれか1項に記載のコンピュータに実装される方法。さらに詳細に解析するために該少なくとも一つのメソッドを選択することが自動的に行われる、請求項1からの14のいずれか1項に記載のコンピュータに実装される方法。さらに詳細に解析するために該少なくとも一つのメソッドを選択することは、ユーザインタフェース250,500を介するユーザコマンドに基づいて行われる、請求項1から15のいずれか1項に記載のコンピュータに実装される方法。該条件付き計測は、該アプリケーションの実行中に、該少なくとも一つの呼び出し可能なメソッドに対して動的に提供される、請求項1から16のいずれか1項に記載のコンピュータに実装される方法。少なくとも一つのプロセッサがアプリケーションの計測をするための方法を実行するようにプログラムするために具現化されたコンピュータで読み取り可能なソフトウェアを有しているコンピュータで読み取り可能な有体の記憶装置であり、該方法は、計測されるメソッドC1-C7を含んでいる計測されるコンポーネントのベースラインの規定により該アプリケーションのコードを構成すること、該アプリケーションの該コードは未計測のメソッドC4Aも含む;コンピュータシステムにおいて該アプリケーションの該コードを実行している最中に、該計測されるメソッドからパフォーマンスデータを取得すること;該パフォーマンスデータに基づいて、さらに詳細に解析するために該計測されるメソッドC4Aの少なくとも一つを選択すること;該選択に基づいて、該少なくとも一つの選択されて計測されるメソッドによって呼び出され得る未計測の少なくとも一つの呼び出し可能なメソッドC5を決定すること;該決定に対応して、該少なくとも一つの呼び出し可能なメソッドのための該アプリケーションの該コードを条件付き計測を伴うように構成すること、該少なくとも一つの呼び出し可能なメソッドが呼び出される場合、該条件付き計測が起動にされる予定のコンテキストを該条件付き計測が特定し、該コンテキストは少なくとも一つの選択されて計測されるメソッドによって呼び出される該少なくとも一つの呼び出し可能なメソッドを含むこと;および該コンピュータシステムにおいて該条件付き計測を伴う該アプリケーションの該コードを実行している最中に、該少なくとも一つの呼び出し可能なメソッドが呼び出される場合、該少なくとも一つの呼び出し可能なメソッドが該コンテキスト内で呼び出されるかどうかを決定し、該少なくとも一つの呼び出し可能なメソッドが該コンテキスト内で呼び出される場合、少なくとも一つの呼び出し可能なメソッドからパフォーマンスデータを取得するために該条件付き計測を起動すること、を含むことを特徴とする記憶装置。該条件付き計測は、該コンテキストを満たして実行をするように要求されるメソッドのシーケンスを特定し、該メソッドのシーケンスは、少なくとも一つの選択されて計測されるメソッドおよび該少なくとも一つの選択されて計測されるメソッドの親メソッドを含み、該少なくとも一つの呼び出し可能なメソッドがコンテキスト内で呼び出されるか否かを決定することは、該メソッドのシーケンスが実行中か否かを判断するためにスレッドローカルキャッシュにアクセスする該条件付き計測を含む、請求項18に記載のコンピュータで読み取り可能な有体の記憶装置。該メソッドのシーケンスの長さをユーザが特定することを許容するユーザインタフェースディスプレィ250,500を提供すること、をさらに有する、請求項19に記載のコンピュータで読み取り可能な有体の記憶装置。条件付計測を伴う該アプリケーションの該コードは、ユーザに対するトランザクションを行うように実行され、該条件付き計測は、該コンテキストを満たすように要求される特定のトランザクションデータであって、発注する商品の種類、商品の製造元の特定、購入するユーザのクラス、該アプリケーションが特定のポータルサイトを介してアクセスしたか否か、該ユーザの地理的ロケーション、支払い方法、および商品出荷方法、のうちの少なくとも一つを含むものを特定する、請求項18から20のいずれか1項に記載のコンピュータで読み取り可能な有体の記憶装置。ソフトウェアの命令を格納する記憶装置と、作業メモリであって、該ソフトウェアの命令が該記憶装置からロードされている作業メモリと、該ソフトウェアの命令を実行するプロセッサと、を備えており、該ソフトウエアの命令が、計測されるメソッドC1-C7を含んでいる計測されるコンポーネントのベースラインの規定によりアプリケーションのコードを設定すること、該アプリケーションの該コードは計測されていないメソッドC4Aも含む;該コンピュータシステムにおいて該アプリケーションの該コードを実行している最中に、該計測されるメソッドからパフォーマンスデータを取得すること;該パフォーマンスデータに基づいて、さらに詳細に解析するために少なくとも一つの該計測されるメソッドC4Aを選択すること;該選択に基づいて、該少なくとも一つの選択されたメソッドによって呼び出され得る未計測の少なくとも一つの呼び出し可能なメソッドC5を決定すること;該決定に対応して、該少なくとも一つの呼び出し可能なメソッドのための該アプリケーションの該コードを、条件付き計測を伴うように構成すること、その中で、該少なくとも一つの呼び出し可能なメソッドが呼び出される場合、該条件付き計測が起動される予定のコンテキストを該条件付き計測が特定し、該コンテキストは少なくとも一つの選択されて計測されるメソッドによって呼び出される該少なくとも一つの呼び出し可能なメソッドを含むこと、;および該コンピュータシステムにおいて該条件付き計測を伴う該アプリケーションの該コードが実行される最中に、該少なくとも一つの呼び出し可能なメソッドが呼び出される場合、該少なくとも一つの呼び出し可能なメソッドが該コンテキスト内で呼び出されるかどうかを決定し、該少なくとも一つの呼び出し可能なメソッドが該コンテキスト内で呼び出される場合、少なくとも一つの呼び出し可能なメソッドからパフォーマンスデータを取得するために該条件付き計測を起動すること、を含むことを特徴とするコンピュータシステム。該条件付き計測は、該コンテキストを満たして実行をするように要求されるメソッドのシーケンスを特定し、該メソッドのシーケンスは、少なくとも一つの選択されて計測されるメソッドおよび該少なくとも一つの選択されて計測されるメソッドの親メソッドを含み、該少なくとも一つの呼び出し可能なメソッドがコンテキスト内で呼び出されるか否かを決定することは、該メソッドのシーケンスが実行中か否かを判断するためにスレッドローカルキャッシュにアクセスする該条件付き計測を含む、請求項22に記載のコンピュータシステム。前記ソフトウエアの命令が、該メソッドのシーケンスの長さをユーザが特定することを許容するユーザインタフェースディスプレィ250,500を提供すること、をさらに含む、請求項23のコンピュータシステム。条件付計測を伴う該アプリケーションの該コードは、ユーザに対するトランザクションを行うように実行され、該条件付き計測は、該コンテキストを満たすように要求される特定のトランザクションデータであって、発注する商品の種類、商品の製造元の特定、購入するユーザのクラス、該アプリケーションが特定のポータルサイトを介してアクセスしたか否か、該ユーザの地理的ロケーション、支払い方法、および商品出荷方法、のうちの少なくとも一つを含むものを特定する、請求項22から24のいずれか1項に記載のコンピュータシステム。本発明は、上記課題および他の課題を解決する監視ソフトウェアのための技術を提供する。一実施形態では、アプリケーションを計測するためのコンピュータに実装される方法は、コンピュータに実装された複数のステップを含む。このステップは、アプリケーション内の計測されるメソッドからパフォーマンスデータを取得することを含む。例えば、これは各メソッドの開始および停止の回数を含み得る。この方法は、パフォーマンスデータに基づいて、さらに詳細に解析するための計測されるメソッドのうち少なくとも一つのメソッドを選択することを、さらに含み、この方法は、その選択に基づいて、少なくとも一つの選択されたメソッドにより呼び出されかつ未計測の少なくとも一つの呼び出し可能なメソッドを決定することを含む。この方法は、この決定に対応して、少なくとも一つの呼び出し可能なメソッドのための条件付き計測を提供することを、さらに含み、その中で、その条件付き計測が、その少なくとも一つの呼び出し可能なメソッドが呼び出されるコンテキストを特定する。別の実施形態では、アプリケーションを計測するためのコンピュータに実装される方法は、アプリケーションの少なくとも一つの選択されたメソッドの計測から、その少なくとも一つの選択されたメソッドが実行を開始することを示す情報を受信することを含み、その受信に基づいて、その少なくとも一つの選択されたメソッドが実行されていることを示す指標をメモリリソースに格納することを含む。例えば、そのメモリリソースはスレッドローカルキャッシュであり得る。この方法は、その少なくとも一つの選択されたメソッドによって少なくとも一つの呼び出されたメソッドが呼び出されるときに、アプリケーションのその少なくとも一つの呼び出されたメソッドの条件付き計測からリクエストを受信することを、さらに含む。そのリクエストは、少なくとも一つの選択されたメソッドが実行されていることを示す指標に、メモリリソースからアクセスする。さらに、条件付きの計測は、アクセスされた指標の少なくとも一部に基づいてその少なくとも一つの呼び出されたメソッドの実行に関して報告するために実行する。他の実施形態では、少なくとも一つのプロセッサを、アプリケーションの計測をするための方法を実行させるためにでプログラムするために具現化されたコンピュータ読み取り可能なソフトウェアを有しているコンピュータで読み取り可能な有体の記憶装置を提供する。実行されるその方法は、アプリケーション内の計測されたメソッドからパフォーマンスデータを取得すること、さらに詳細に解析するために計測されるメソッドの少なくとも一つのメソッドを特定すること、少なくとも一つの選択されたメソッドから呼ばれ得るメソッドであって未計測の少なくとも一つの呼び出し可能なメソッドを特定すること、少なくとも一つの呼び出し可能なメソッドが続いて呼び出される場合に条件が合致しているかどうかを決定する少なくとも一つの呼び出し可能なメソッドの条件付き計測を提供すること、を含む。その条件付き計測は、その条件が合致したという決定に基づいて少なくとも一つの呼び出し可能なメソッドを実行することに関してパフォーマンスデータを提供するために実行し、その条件付き計測は、条件が合致しなかったという決定に基づいて少なくとも一つの呼び出し可能なメソッドを実行することに関してパフォーマンスデータを提供するためには実行しない。方法に対応して、本明細書にて提供される方法を実行する命令がエンコードされた記憶媒体を含むコンピュータましくはプロセッサ読み取り可能な記憶装置、及び、システムが、提供される。本発明は、ソフトウエアの実行中に、条件付きで計測される、未計測のコンポーネントが発見され得る、ソフトウェアを解析する技術を提供する。最初に、アプリケーションのようなソフトウェアは、メソッドのような計測されるコンポーネントのベースラインの規定セットによって構成される。アプリケーションの実行により、計測からパフォーマンスデータが集められることで、いくつかのメソッドのパフォーマンスが期待値を下回っていること、またはそれ以外の問題があることがわかる。この問題を解析するため、問題の対象となっているメソッドから呼び出し可能な任意のメソッドを発見するために技術が用いられ得る。ある特定の実装では、呼び出し可能なメソッドは、Java登録商標仮想マシンJVMにロードされたクラスのバイトコードを検査することによって見つけ出される。そして、その発見されたメソッドを計測および/または報告する決定がされ得る。選択的に計測を追加することによって、初期の包括的過ぎる計測を必要とすることなく、パフォーマンス問題の深い診断をするために当該発見されたコンポーネントから追加のパフォーマンスデータを得ることが可能となる。さらに、当該計測が特定のコンテキストでのみ実行されるように、発見されたコンポーネントに追加された計測は条件付きとすることができる。そのコンテキストは、例えば、発見されたコンポーネントが呼び出されるコンポーネントの特定のシーケンス、および/または発見されたコンポーネントが呼び出されるトランザクションのデータ、を含むことができる。このように、必要なときには深い診断の能力を伴うことにより、効率的で軽い計測という目的が達成される。図1は、異なったコンピュータシステムがマネージャにデータを提供するネットワークを示す。例示のコンピュータシステムは、アプリケーションサーバ106および110、または所望の機能を実現するためにコードを実行するプロセッサを有する他の任意の種類のコンピュータシステムをも含み得る。アプリケーションサーバ群は、異なったアプリケーションを実行し、または同じアプリケーションの別々のインスタンスを実行することができる。アプリケーションサーバ群は、互いに離れて位置することができ、または同じ場所に位置することもできる。この例では、アプリケーションサーバ106および110は、ローカルマネージャコンピュータ120と通信している。マネージャコンピュータ120は、あるいは、アプリケーションサーバ106および110から離れていてもよく、そのような場合にはこれらの間の通信はネットワーククラウド104を介して行われる。例えば、webベースの電子商取引アプリケーションのようなエンタープライズアプリケーションを運営する会社は、負荷分散のために多くのアプリケーションサーバを一つの場所で使用する。ユーザからのリクエストは、ユーザのWebブラウザ102の例のように、インターネットのようなネットワーククラウド104経由で受信され、アプリケーションサーバ106および110のいずれかに送られる。Webブラウザ102は、通常、図示していないインターネットサービスプロバイダーを介してネットワーククラウド104にアクセスする。アプリケーションサーバ106および110上で実行するエージェントソフトウェアは、エージェントA1108およびエージェントA2112とそれぞれ表示されるが、それぞれアプリケーションサーバ106および110上で実行され、ある可能なアプローチで、アプリケーション、ミドルウェア、またはその他のソフトウェアからの情報を集める。例えば、そのような情報は、計測を用いることによって得ることができ、その一例は、バイトコード計測である。しかしながら、集められたデータは他の方法でも得ることができる。エージェント群は、監視されるコンピュータシステムに本質的に存在し、データの取得ポイントを提供する。エージェント群は、マネージャ120と通信してデータを編成し最適化する。ソフトウエアの実行を監視するためのソフトウエア計測について様々なアプローチが知られている。例えば、最初に述べたように、トレーシングはソフトウェアの実行を追跡するために用いられる。トレーシングの例が、2004年4月22日に公開された、TransactionTracerと題する米国特許出願公開No20040078691にて述べられており、それは参照により本明細書に組み込まれる。そこで述べられている一つのアプローチでは、監視されるべきアプリケーションのオブジェクトコードまたはバイトコードは、プローブにより計測、例えば変更、される。アプリケーションのジョブまたは他のロジックを変更することなくアプリケーションに関する特定の情報をそのプローブが測定する。一旦、そのプローブがアプリケーションのバイトコードにインストールされると、それは管理されたアプリケーションと呼ばれる。エージェントソフトウェアは、当該プローブからのパフォーマンスデータのような情報を受信し、その情報を、例えばマネージャ120において、別の処理へ通信する。エージェントソフトウエアは、あるいは、その情報が異常状況を示すか否かを判断するなど、情報を局所的に処理する。例えば、当該プローブからの情報は、トランザクションまたは他の実行フローの開始や停止の回数、またはトランザクション/実行フロー内の個々のコンポーネントの開始や停止の回数などのパフォーマンスデータを示す。この情報は、それが範囲内にあるかどうかを決定するために予め決められた基準と比較される。もし情報が範囲内にない場合には、エージェントは適切なトラブルシューティングが実行できるようにこの事実をマネージャに報告する。エージェント108、112および116は、それぞれが関連付けられているローカルアプリケーションサーバー106、110上でソフトウェアが実行中であるであることを通常認識している。マネージャ120は、エージェントから受信したデータに基づいて情報を表示するため、モニタのようなユーザインタフェース122と通信するワークステーションなどの別のコンピュータシステム上に提供される。図4B-Eおよび図5B-Dの例示を参照されたい。マネージャは、また、エージェントから受信したデータを格納するため、データベース118にアクセスすることができる。提示された例では、アプリケーションサーバは、ネットワーククラウド104にアクセスすることなく、マネージャ120と通信することができる。例えば、通信は、ローカルエリアネットワークを介して行われる。他の設計では、マネージャ120は、ネットワーククラウド104を介して複数のアプリケーションサーバのエージェントからデータを受信することが可能となる。例えば、大きな組織においては、セントラルネットワークオペレーションセンタを用いており、そこでは、一つまたはそれ以上のマネージャは、地理的に異なる場所に分散している複数のエージェントからデータを取得する。説明すると、Webベースの電子商取引企業では、顧客の注文を受ける地理的に異なる場所にあるサーバ群からエージェントのデータを取得する可能性がある。そのサーバ群は、支払いを処理するサーバ、倉庫で在庫を調べたり、受注を受けたりするサーバなどである。マネージャ120およびユーザインタフェースディスプレィ122は、企業の本社の場所で提供され得る。必ずしも、Webベースまたは小売、若しくはその他の販売に関する必要はなく、他のアプリケーションにおいてシステムを管理するために同様にエージェントとマネージャを利用することができる。例えば、銀行では、小切手の処理やクレジットの口座用にアプリケーションを使用する。また、上述した複数のコンピュータシステムに加えて、一つまたはそれ以上のエージェントによって単一のコンピュータシステムも同様に監視することができる。図2は、図1のネットワークのコンピュータシステムを示す。コンピュータシステム200は、図1に関して説明したように、Webブラウザ102、ホストアプリケーションサーバ106および110など、セントラルマネージャ120および/またはユーザインタフェース122として使われているシステムを簡略化して表したものである。コンピュータシステム200は、ハードディスクまたはポータブルメディアのような記憶装置210、他のコンピュータシステムと通信するためのネットワークインタフェース220、ソフトウェアの命令を実行するためのプロセッサ230、例えば、記憶装置210からロードされた後にソフトウェアの命令を格納するためのRAMのような作業メモリ240、および、ユーザインタフェースディスプレィ250を含む。記憶装置210は、ここで説明する機能を提供するためのメソッドを実行するようにプロセッサ230をプログラムするために具体化されているプロセッサの読み取り可能なコードを有する、プロセッサにより読み取り可能な記憶装置と考えることができる。ユーザインタフェースディスプレィ250は、一つまたはそれ以上のエージェントから受信したデータに基づいて、人間のオペレータに情報を提供することが可能である。ユーザインタフェースディスプレィ250は、グラフィカルまたは表形式のような既知の任意の表示方式を使用することができる。画面上の表示に加え、プリンタからのハードコピーなどの出力も提供することができる。また、本明細書で説明する機能は、ハードウェア、ソフトウェアまたはハードウェアとソフトウェアの両方の組み合わせを使用して実装されてもよい。ソフトウェアについては、一つまたはそれ以上のプロセッサをプログラムするために具体化されているプロセッサの読み取り可能なコードを有する、一つまたはそれ以上のプロセッサにより読み取り可能な有体の記憶装置を使用することができる。プロセッサにより読み取り可能な有体の記憶装置は、揮発性および不揮発性媒体、リムーバブルおよび非リムーバブルメディアなどのコンピュータ読み取り可能な媒体を含むことが可能である。例えば、コンピュータにより読み取り可能な有体の媒体には、コンピュータにより読み取り可能な命令、データ構造やプログラムモジュールまたは他のデータといった情報を記憶するために、任意の方法や技術でインプリメントされた揮発性、不揮発性、リムーバブル、非リムーバブルの媒体が含まれ得る。コンピュータにより読み取り可能な有体の媒体の例としては、RAM、ROM、EEPROM、フラッシュメモリ、または他のメモリ技術、CD-ROM、デジタルバーサタイルディスクDVD、または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、他の磁気記憶装置、または所望の情報を格納したり、コンピュータによってアクセスしたりすることに用いられる他の媒体などがある。他の実施形態においては、一部またはすべてのソフトウェアは、カスタムIC、ゲートアレイ、FPGA、PLDや特殊用途向けプロセッサなど、専用のハードウェアに置き換えることができる。一実施形態では、一つまたはそれ以上の実施形態を実装するソフトウェア記憶装置に格納されているは、一つまたはそれ以上のプロセッサをプログラムするために用いられる。一つまたはそれ以上のプロセッサは、一つまたはそれ以上のコンピュータにより読み取り可能な有体の媒体/記憶装置、周辺機器、および/または通信インタフェースと通信することができる。図3Aは、計測されるコンポーネントの可能性のある呼び出しシーケンスの例を示す。図1のアプリケーションサーバ106、110などのアプリケーションサーバ上で実行されるアプリケーション内のコンポーネントが示されている。アプリケーションが計測されるときには、通常、そのアプリケーションの開発者の理解や興味の対象となるであろうコンポーネントの選択に基づいて、選択されたコンポーネントのみが計測されることに留意されたい。このように、少なくとも最初は、興味があるものとされていないため、多くのコンポーネントはアプリケーション内で起動され/呼び出されるが、計測されることはない。コンポーネント指向のプログラムモジュールは、コンポーネントと呼ばれるブロックを組み立ててアプリケーションや他のプログラムをプログラマに組ませるのに役に立つ。各コンポーネントは、ソフトウェアの全体的機能に適合するよう特定の機能を実行することができる。さらに、コンポーネントは、再帰呼び出しによって自分自身を呼び出すことや他のコンポーネントを呼び出すことができ、これによって、コンポーネントのシーケンスがプログラム内に呼び出される。コンポーネントは、プログラムが実行される際に、消費されるコンピュータシステムの資源、あるいは実行されたワークの例である。コンポーネント指向のプログラミングモデルの一例は、J2EEであるが、JavaServerPage、EnterpriseJavaBean、サーブレットおよびJavaDatabaseConnectivityコンポーネントといったコンポーネントを用いることができる。しかしながら、その他のコンポーネント指向のプログラミングモデルもまた使用されており、例えば、マイクロソフト社のNETコンポーネントが使用される。さらに、プログラミングモデルはオブジェクト指向である必要はない。一つのアプローチでは、コンポーネントはメソッドである。特定の例に示されているように、コンポーネントC1300およびC2302はコンポーネントC3304を呼び出すことができる。矢印は、実行開始時にはメソッドの呼び出しを、実行終了時にはメソッドのリターンを示している。コンポーネントC3304およびC4306は、コンポーネントC5308を呼び出すことができる。このように、可能性のある呼び出しシーケンスは、C1-C3-C5、C2-C3-C5およびC4-C5である。図示されている各コンポーネントは、実行時間を含むパフォーマンスデータが、それらから得られるように計測されると仮定する。ただし、現在は計測されていないが呼び出される追加のコンポーネントが存在する可能性がある。過度なアプリケーションの減速を避けるためには、すべてのコンポーネントを計測することはできない。また、追加のコンポーネントが、アプリケーションのパフォーマンス問題を診断するために一時的に計測できる場合でも、計測によって提供されるデータの量は、依然として包括的過ぎる可能性がある。効率を最適化するために、条件付き計測は、コンポーネントが実行されるコンテキスト内に条件付けられて提供することが可能である。そのコンテキストは、そこでパフォーマンス問題が発生しているコンテキスト、あるいは、一般的に解析することが望まれている特定のコンテキストに対応するように、設定できるようになっている。例えば、過剰な実行時間などのパフォーマンス問題がC5にあると特定されていると仮定する。この場合、例えば、C5によって呼ばれ得るメソッド、即ち、C5の呼び出し可能なメソッドである未計測のメソッドを発見するため、処理が実装される。計測メソッドは、起動されていない計測コードを有するか、または計測コードが与えられていない。図3Bの例では、発見されたコンポーネントはC6310とC7312である。図3Bは、図3Aの計測されたコンポーネントによって呼び出され得るコンポーネントであって発見されたコンポーネントの例を示す。発見されたコンポーネントは、C5のパフォーマンス問題を解析するのに役立ち得るパフォーマンスデータを取得するために計測され得る。例えば、C6はC5により呼び出されて実行に時間がかかり過ぎると判断され、しかし、C5により呼び出されたC7は許容されるパフォーマンスを備えていると判断される。これは、C6を含んでいる追加の解析が保証され得ることを示している。コンテキストに関して、C6とC7の計測は、呼び出される一つのコンポーネントまたは特定の複数のコンポーネントのシーケンスによって条件付けられる可能性がある。例えば、C5がC1-C3-C5のシーケンスにおいて呼び出されるときは、C5はパフォーマンス問題を持っていると判断されるが、しかし、C2-C3-C5またはC4-C5のような別のシーケンスで呼び出されるときには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で発見されたコンポーネントの一つによって呼び出され得ることで発見されたコンポーネントの例を示す。具体的には、コンポーネントC8314、C9316およびC10318は、C6から呼び出され得る。これらの発見されたコンポーネントは、C6のパフォーマンス問題を解析するのに役立ち得るパフォーマンスデータを取得するために計測され得る。この例では、一度に、コンポーネントの1つのレベルの発見および計測が処理され、当該レベルが階層内のコンポーネントのレベルを参照していることに留意されたい。例えば、図3Cの階層においては、第1レベルはC1とC2を含み、第2レベルはC3とC4を含み、第3レベルはC5を含み、第4レベルはC6とC7を含み、第5レベルはC8、C9、C10を含んでいる。階層内にはさらに下位レベルが有る場合も無い場合もあり得る。他のアプローチとしては、一度にコンポーネントの2以上のレベルの発見と計測を実行する。例えば、図示されてはいないが、呼び出し可能なC7のコンポーネントを発見するのに加え、C6とC7が見つけ出され、その後にC8、C9、C10が発見されることが可能である。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で発見されたコンポーネントで、コンポーネントがトランザクションデータのコンテキスト内に呼び出されるものを示す。呼び出しコンテキストのもう一つの特徴は、コンポーネントが実行するトランザクションのデータに関与し得ることである。呼び出しシーケンスを発見されたコンポーネントの計測の条件付けは、解析するためのパフォーマンスデータの量を絞り込みに便利である一方、付加的または代替として、トランザクションデータベースのコンテキストに設定することで効率性を得ることが可能となる。例えば、ユーザがアイテムを注文して支払いを行うWebベースの電子商取引アプリケーションについて検討する。トランザクションデータは、特定の支払いタイプが使用されたときにパフォーマンス問題が生じたことを示す可能性がある。図3Dでは、データ1およびデータ2は、トランザクションデータとして可能なタイプを表している。例えば、データ1が問題の有る支払いタイプで、データ2が問題の無い支払いタイプを表していると仮定する。一般的に、トランザクションの様々なアスペクト側面は、個々のデータフィールドによって表される。C1がC3を呼び出すとき、例えばメッセージのヘッダなどに、C1はデータ1を含み、これにより、C3が必要に応じてこのデータにアクセスすることができる。このシーケンスでは、データ1はC3からC5へ渡され、C5からC6またはC7へ渡される。一方、C2がC3を呼び出すシーケンスでは、データ2データ1とは異なるがC2からC3、C3からC5、C5からC6またはC7へ渡される。この例の場合、C6またはC7に対する条件付き計測においては、データ1がC6に渡されるときに限ってパフォーマンスデータを報告することが実行される。図4Aは、電子商取引のwebサイトで商品を買うトランザクションの例で、計測されたコンポーネントおよび発見されたコンポーネントの呼び出しシーケンスを含むものを示す。これは、ユーザが関与するトランザクションの一例である。ここで用いられているコンポーネントを示す符号は、必ずしも図3A-3Dで示した前例に対応している必要はない。しかしながら、図4A-Eと図5A-5Dと図8Jでは、コンポーネントを示す符号は、一貫して使用されている。ユーザがアイテムを注文できるようにするWebベースの電子商取引アプリケーションを考える。コンポーネントは、アプリケーション内のビジネスロジックまたは電子商取引の手順に対応する。特に、コンポーネントC1400では、ユーザがアイテムを選び、購入し、クレジットカードの種類やクレジットカード番号といった支払い方法の情報、アイテムを発送する住所といった発送情報、陸送または翌朝配達の航空発送といった発送方法の情報を入力する、ショッピングカートを提供している。C1は、コンポーネントC2402を呼び出し、選択されたアイテムの在庫があるかどうかを決定するために在庫をチェックする。一旦、選択されたアイテムの在庫があると判断されると、C2は実行を完了し、制御フローがC1に戻る。C1は、コンポーネントC3A404またはC3B406を呼び出し、そこでトランザクションが保留にされている間、当該アイテムが他のユーザに販売されないように、アイテムを予約する。C3Aの場合、当該アイテムはユーザ自身のために予約される一方、C3Bの場合、当該アイテムは、ユーザ以外の人への贈答用にギフトレジトリまたはウッシュリストなどに予約される。C3AまたはC3Bは、支払いコンポーネントC4A410を呼び出し、そこで、現金払い、例えばデビットカードもしくは銀行振替またはPAYPAL登録商標のような第三者支払いの処理がされ、あるいはクレジット払いコンポーネントC4B412を呼び出し、ここで、特定のクレジットカードの発行会社のようなクレジットカード払いまたは支払いギフト券やクーポンによる支払いの処理がされる。コンポーネントC4AおよびC4Bは、外部サーバとの通信により購入の承認と認証が行われる。この例では、C4AまたはC4Bは、コンポーネントC5414を呼び出し、購入されたアイテム数を減算して在庫を合わせる。ところが、C5は、元来、計測を含んでいないため、C4AまたはC4Bの呼び出し可能なメソッドとして見つけ出される。例えば、もしパフォーマンスデータがC4Aの実行に非常に時間がかかることを示す一方で、C4Bのパフォーマンスデータが許容可能なものであることを示す場合には、C5は、C4Aの呼び出し可能なメソッドとして見つけ出されて、条件付き計測がC5に適用される。これは、C5のパフォーマンスデータがC4Aを診断するための試行中に得られるようにしている。C5は、またパフォーマンス問題を持ったC4AおよびC4Bの両方に基づいても見つけ出される可能性がある。C5およびC5以下で呼び出される図略の任意のコンポーネントが、一旦、実行を完了すると、C3AまたはC3Bの実行完了後、C4AまたはC4Bの実行が完了するように、実行フローがC1に戻る。そして、C1は、発注確認番号および追跡番号等を確認電子メールまたはWebページで提供するなどのユーザによる購入を確認する、発注完了コンポーネントC7408を呼び出す。コンポーネントは、非同期モードでマルチスレッドまたはマルチプロセスの実行を開始する別のコンポーネントを呼び出した後、実行を継続させることができ、または呼び出されたコンポーネントが同期モードでシングルスレッドまたはシングルプロセスの実行を終了するまで、コンポーネントを一時的に休止させることができる、ことに留意されたい。例えば、C4AもしくはC4BならびにC5のコンポーネントが実行している間、C3AまたはC3Bは休止する。さらに、任意のコンポーネントは、トランザクション内に複数回呼び出されることが可能である。図4Bは、条件付き計測が見つけ出されたコンポーネントに適応され、条件付き計測の条件が呼び出しシーケンス内の一つのコンポーネントによって合致する場合において、図4Aの呼び出しシーケンスに基づく、呼び出しスタックの位置に対する時間のグラフを示す。時間の増分は必ずしも等間隔でなくともよい。しかし、図4B-4Eと5Bと5Cのグラフの時間の増分は一致している。当該表現では、トランザクションのトレースは、一つまたはそれ以上のホストによって提供される実行パス情報の種類の一例である。これは、ユーザインタフェース上で報告として提供されグラフィカルに表示し得るもので、例えばメソッドのようなコンポーネントの実行時間の形式でパフォーマンスデータを表現したものである。実行パス情報では、アプリケーションのどのメソッドが呼び出されるか、および、呼び出された時間についても特定することができる。水平方向は時間を表し、垂直方向は呼び出しスタックの深さや位置を表す。呼び出しスタックは、一つまたはそれ以上のプログラムまたはスレッドの実行中に、呼び出されるまたは起動されるメソッドを特定する。実行パスは、通常、1秒から数秒のわずかの間、拡張される。事例の実行パスは、コンポーネントとそれぞれのグラフの領域と実行時間を、次のように示す;C1420t1-t25、C2422t2-t4、C3A424t5-t19、C4A428t6-t18、C5430t7-t17およびC7426t20-t24。この例は、自分使いアイテム予約C3Aと現金払いC4Aのオプションを含んでいる。ホストは、クライアントからのリクエストを受信して、C1がt1において実行を開始したことに気づく。当該シーケンス内における各トランザクションは、計測に基づいてエージェントによって気づかれる。t2においてC1が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において実行を完了するとき、ホストがクライアントにレスポンスを出す。ホストは、定期的にセントラルマネージャに時間とトランザクションデータを報告する。C5のための領域430は、C5が条件付きで計測されていることを示すために点線で表されている。さらに、この例では、その計測を起動するのに必要とされるコンテキストまたは条件は、C5がC4Aによって呼び出されることである。即ち、当該コンテキストは、スタック内の一つまたはそれ以上の特定呼び出しされた一連のメソッドに基づくものである。図示されているように、コンテキスト内におけるメソッドの開始と終了は、それぞれt6とt18である。C4Aは、C5が呼び出されるときには実行されているので、コンテキストは合致し、C5の条件付き計測が実行される。最初に、C5が条件付きで計測されないと仮定すると、図4Bのグラフは領域C5を含まない。このグラフは、グラフの背後にある対応するデータが自動的に処理され判断されて、C4Aの応答時間が長すぎて閾値レベルを超えることをユーザに示している。しかしながら、この時点では、C4Aによって呼び出される可能性のあるメソッドに関するユーザインタフェースから知らされている情報はない。この例では、本明細書に記載されている技術は、C5がC4Aから呼び出されることを見つけ出すために用いられる。呼び出し可能のコンポーネントは、必ずではないが、別のコンポーネントから呼び出される可能性がある。グラフにおいて1つ上位のレベルの別のメソッドによって直接呼び出される特定のメソッドは、その別のメソッドの子メソッドであると見なし得る。同様に、グラフにおいて次の一つ上位のメソッドは、特定のメソッドの親の親メソッドと見なすことができ、以降、同様である。一旦、呼び出し可能なメソッドが特定され、それが続いて呼び出されると、パフォーマンスデータを取得するために計測される。この場合、C5は見つけ出された後に計測され、そのアプリケーションは実行を継続し、新しいパフォーマンスデータが集められて領域430がグラフに表示される。図4Cは、条件付き計測が発見されたコンポーネントに適用され、条件付き計測の条件が呼び出しシーケンスによって合致しない場合において、図4Aの呼び出しシーケンスに基づく、呼び出しスタックの位置に対する時間のグラフを示す。図4Bでは、計測を起動するのに必要とされるコンテキストは、C5がC4Aによって呼び出されることである。しかしながら、この場合は、グラフの領域429に示されているように、C4BがC4Aの代わりに実行されている。その結果、C4Aのコンテキストが合致せず、条件付き計測が実行されないので、領域430はグラフには表れない。図4Dは、条件付き計測が発見されたコンポーネントに適用され、条件付き計測の条件が、呼び出しシーケンス内の一つのコンポーネントとトランザクションデータの組み合わせによって合致する場合において、図4Aの呼び出しシーケンスに基づく、呼び出しスタックの位置に対する時間のグラフを示す。上述したように、コンテキストまたは条件付き計測の条件には、呼び出されている一つまたはそれ以上の特定のメソッドおよび/または提示されている特定のトランザクションデータを含むことができる。特に、トランザクションによって運ばれるデータオブジェクトまたはデータエレメントを調べることができる。例えば、内部コンポーネントのメッセージのヘッダー内の特定値の存在は、コンテキストとして使用することが可能である。または、値がnullでない、またはnullであるデータフィールドの単なる存在もコンテキストとして使用することができる。トランザクションデータは様々なアイテム:発注する商品の種類、商品の製造元の身元、購入するユーザのクラス例えば、特別な権限がユーザに与えられる会員であるプレミアムユーザ、これに対しそのような特権のないレギュラーユーザ、電子商取引のアプリケーションが特定のポータルサイトを介してアクセスしたか否か、ユーザの地理的ロケーション、支払い方法、商品出荷方法、等々、を含むことができる。このような場合、計測は、トランザクションデータが示すコンテキスト、例えば、問題のある商品の種類および/または製造元が含まれているかなどに基づいて条件付けられる。計測は、このようにユーザが参加するトランザクションの一つまたはそれ以上のアスペクト、あるいは一般的に任意のトランザクションのアスペクトに関するコンテキストに条件付けられる。また、本明細書における概念は、Webベースの電子商取引のアプリケーションに限定されることなく、他のWebベースのアプリケーションやWebベースではないアプリケーションをも含めることができる。この例は、C4AからC5に渡されるトランザクションデータがコンテキストと一致することの追加を除いて図4Bと同じである。その結果、コンテキストの2つのアスペクトが合致する。1番目のアスペクトは、C5が呼び出される、例えばC5がC4Aによって呼び出される、ときにC4Aが実行されていること、そして、2番目のアスペクトは、C4AによってC5に特定のデータが渡されること、である。そのデータは、C4AおよびC5が呼び出されたトランザクションのデータオブジェクトである。コンテキストが合致するので、C5の条件付きの計測が実行される。図4Eは、条件付き計測が発見されたコンポーネントに適用され、条件付き計測の条件が呼び出しシーケンス内の一つのコンポーネントよっては合致するが、トランザクションデータによっては合致しない場合において、図4Aの呼び出しシーケンスに基づく、呼び出しのスタック位置に対する時間のグラフを示す。この例では、C4Aによって呼び出されるC5のコンテキストは合致するが、トランザクションデータはコンテキストには合致しない。その結果、コンテキストは合致せず、条件付き計測は実行されないため、領域430はグラフには表れない。図5Aは、電子商取引のwebサイトで商品を買うトランザクションの別の例で、計測されたコンポーネントおよび発見されたコンポーネントの呼び出しシーケンスを含むものを示す。この例は、図4Aの例に類似しており、C5414の呼び出し可能コンポーネントであるコンポーネントC6A416およびC6B418と、C6Aの呼び出し可能なコンポーネントとして発見されたコンポーネントC6A1440、C6A2442およびC6A3444と、を加えたものである。C6AとC6Bは、それぞれ、荷送り人Aまたは荷送り人Bを介して商品を出荷するメソッドを表している。C6A1、C6A2およびC6A3は、出荷部門A1、A2またはA3を介して、それぞれ荷送り人Aに商品を出荷することを表している。この例は、条件付き計測がC6A1、C6A2およびC6A3に提供され、静的計測がC5、C6A、C6Bに提供されることを示している。図5Bは、条件付き計測が発見されたコンポーネントに適用され、条件付き計測の条件が呼び出しシーケンス内の3つのコンポーネントによって合致する場合において、図5Aの呼び出しシーケンスに基づく、呼び出しスタックの位置に対する時間のグラフを示す。このグラフは、この例ではC5の領域430が静的に計測されているため実線で示されているという点を除いて、図4Bのグラフに類似している。また、領域450は、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は、t20においてC7を呼び出し、C7はt24において実行を完了する。C1がt25において実行を完了するとき、ホストがクライアントにレスポンスを出す。C6A1、C6A2またはC6A3の条件付き計測のためのコンテキストは、C6A1、C6A2またはC6A3が呼び出される前のC4A-C5-C6Aのシーケンスを必要とする。そのコンテキストは、また、条件付きで計測されるコンポーネント、すなわち、C6A1、C6A2またはC6A3が、そのシーケンス内の最後のコンポーネント、すなわちC6Aによって呼び出されることを必要とする。この例では条件が合致し、条件付き計測が実行される。具体的には、C4A、即ちコンテキスト内の1番目のメソッドは、t6において実行を開始する。C5、即ちコンテキストの2番目のメソッドは、t7において実行を開始する。C6A、即ちコンテキストの3番目のメソッドは、t8において実行を開始する。このように、C6A1、C6A2またはC6A3が呼び出されるとき、シーケンスにおける各コンポーネントが実行する。続いて、コンテキストの3番目、2番目および1番目のメソッドは、t16、t17,t18においてそれぞれ実行を終了する。図5Cは、条件付き計測が発見されたコンポーネントに適用され、条件付き計測の条件が呼び出しシーケンスに合致しない場合において、図5Aの呼び出しシーケンスに基づく、呼び出しスタックの位置に対する時間のグラフを示す。ここで、領域429で表されているC4Bは、C4Aの代わりに呼び出され、C4A-C5-C6Aのシーケンスを必要とするコンテキストが合致せず、C6A1、C6A2、またはC6A3の条件付き計測が実行されない。図5Dは、パフォーマンスデータに呼応したコンポーネント間の階層的関係を示すユーザインタフェース表示を示すもので、これにより、ユーザは、条件付きで計測すべきコンポーネントを手動により特定することや、条件付き計測を削除すること、条件付き計測のシーケンス長を特定すること、そしてトランザクションデータに基づいてパフォーマンスデータをフィルタリングすること、が可能となる。当該ユーザインタフェース表示500は、図5Aおよび5Bの例と一致している。領域502の部分504は、発見されたコンポーネント、例えば、C6A1、C6A2およびC6A3の一つまたはそれ以上の名前を特定する。他のコンポーネントの名前も提供することができる。コンポーネントの名称/符号の横にあるチェックボックスは、条件付き計測がコンポーネントに適用されるようにユーザがチェックを付けることができる。ユーザは、例えば、コンポーネントがエラーに関与しているか否か、コンポーネント自身がエラーを起こしていないか、以前のトラブルシューティングの経験やその他の要因の観測に基づいて、ある発見されたコンポーネントに計測を追加すべきかどうかを指示することができる。または、計測は、発見されたコンポーネントに自動的に適用されるようにすることができる。条件付き計測がコンポーネントに適用されている場合、チェックボックスは、その後、ユーザが計測を削除するために、チェックを外すことができる。領域502の部分506は、ユーザがドロップダウンウィジェットを使用して条件付き計測のためコンテキスト内のシーケンス長を設定することができる。これは、例えば、発見されたコンポーネントの前に呼び出される連続したコンポーネントの数を表すことができる。一つのアプローチでは、シーケンスの最後のコンポーネントが発見されたコンポーネントを呼び出す。この例では、その長さは、C4A-C5-C6Aのシーケンスに対応してそれぞれ発見されたコンポーネントに対し、3である。異なるコンポーネントに異なるシーケンス長を与えることができる。シーケンス長を既定レベルに事前設定することも可能である。一般的に、提供されるパフォーマンスデータの量は、シーケンス長を増加させることによって低減することができる。表示領域502の一部分507は、例えば、表示領域510内の計測に基づいたコンポーネントに対するトレースなどのデータを表示するためユーザが表示領域508の一つまたはそれ以上のコンポーネントを選択できること、領域508内のコンポーネント名がイタリック体であるものには使用可能なデータがないこと、をユーザに通知する。表示領域508は、コンポーネントが別のコンポーネントの下に示されるツリーのような階層構造を使って、または別のコンポーネントに呼び出されて、アプリケーション内の各コンポーネントが自動的に追加される。この例では、C6A1はC6Aによって呼び出され、C6A1の条件付き計測のコンテキストが合致する。その結果、C6A1のためのパフォーマンスデータ516は、マウスまたは他のポインティングデバイスによって領域508のツリー内のC6A1がクリックされたとき、使用可能になる。これに対して、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実行環境は、JavaAPIクラス602とJVM604を含むいくつかの仮想部品を含んでいる。JVMは、レジスタ606、オペランドスタック608、ヒープ610およびメソッド領域612を含んでいる。JVMは、命令のシーケンスとして一連のバイトコードを処理する。JVMの命令は、動作上での具体化する値のゼロまたはそれ以上のオペランドがその後に続く、実行されるべきオペレーションを特定するオペコードからなる。オペランドスタック、ヒープおよびメソッド領域は、指定可能なメモリ内にある。アドレスのサイズは32ビットであり、各メモリロケーションは1バイトを含み、各レジスタが一個の32ビットアドレスを格納する。メソッド領域は、バイトコードを含んでバイトバウンダリに配置され、オペランドスタックとヒープは、ワード32ビットバウンダリに配置される。レジスタは、実行すべき命令がメモリ内のどこにあるかの記録を付けるものであるプログラムカウンタPCを含む。プログラムカウンタは、実行すべき次のバイトコードを特定する。フレームレジスタは、オペランドスタック内のカレントメソッドの実行環境に対するポインタを含む。オペランドトップoptopレジスタは、オペランドスタックの先頭へのポインタを含み、算術式を評価するのに用いられる。変数varsレジスタは、ローカル変数へのポインタを含む。オペランドスタックは、メソッドとオペレーションへパラメータを供給し、それらから結果を得る。すべてのバイトコード命令は、スタックからオペランドを取得してそれらに対して動作して、スタックへ結果を戻す。オペランドスタックは、実行中のメソッドのスタックフレームを含む。スタックフレームは、例えば、ローカル変数、計算の中間結果など、メソッドの特定呼び出しのために、その状態を保持する。具体的には、各JVMスレッドは、そのスレッドと同時に生成された、専用のJVMスタックを有する。JVMスタックは、フレームを格納し、ローカル変数と部分的な結果を保持し、メソッド呼び出しとリターンの役割を果たす。このようにフレームは、動的リンクを実行したり、メソッドのための値を戻したり、例外処理をディスパッチしたりするために、部分的な結果とデータを格納するため使用される。新しいフレームは、メソッドが呼び出されるたびに生成される。フレームは、メソッドの呼び出しが完了すると破棄され、その完了とは、正常か、あるいは、中途中断受け取れない例外処理を放棄したである。フレームは、フレームを生成するスレッドのJVMスタックから割り当てられる。各フレームは、ローカル変数の独自の配列、独自のオペランドスタック、および、カレントメソッドのクラスの実行時定数プールへのリファレンスを持っている。ヒープまたはメモリ割り当てプールは、ガーベジコレクトされる。ヒープは、すべてのクラスのインスタンスに対するメモリと配列がそこから割り当てられる実行データ領域である。ヒープは、起動した仮想マシン上に生成され、オブジェクトのためのヒープ記憶域は、ガーベジコレクタとして知られている自動記憶装置管理システムにより再生される。具体的には、Java実行環境で実行中の各プログラムが、それに割り当てられたガーベジコレクトされたヒープを持っている。また、ヒープ内の各クラスには、それに関連付けられた定数プールがある。定数は、変更されることはないから、通常、コンパイル時に生成される。定数プール内のアイテムは、特定のクラス内の任意のメソッドで使用されるすべての名前をエンコードする。クラスは、いくつの定数が存在するかのカウントを含み、クラスの記述内における定数の特定リストの始まりを特定するオフセットを含む。メソッド領域は、コンパイルされたコード内でメソッドと関連付けられたバイトコード命令、および、動的リンクのために実行環境が必要とするシンボルテーブルを格納する。メソッドと関連付けられる必要がある可能性があるデバッグや追加情報も、またこの領域内に格納される。プログラムカウンタは、常にメソッド領域の数バイトのアドレスを示し、例えば、メソッド領域の数バイトのアドレスが入る。プログラムカウンタは、通常、スレッドの実行を追跡するために使用される。バイトコード命令が実行された後、プログラムカウンタは、次に実行する命令のアドレスを保持する。メソッド領域は、すべてのJVMスレッド間で共有され、例えば、実行時定数プール、フィールドおよびメソッドデータ、およびメソッドやコンストラクタのためのコードのようなクラスごとの構造体などを格納しており、クラスおよびインスタンスの初期化やインタフェースタイプの初期化で使用される特別のメソッドを含んでいる。メソッド領域は、起動した仮想マシン上に生成される。実行時定数プールは、クラスファイル内の定数プールテーブルの実行時間をクラスごとに、またはインタフェースごとに、表現したものである。これには、コンパイル時に知られている数値リテラルから実行時に解決されるべきメソッドやフィールドリファレンスに至るまでの範囲で、定数のいくつかの種類が含まれている。各実行時定数プールは、JVMのメソッド領域から割り当てられる。クラスまたはインタフェースの実行時定数プールは、JVMによってクラスまたはインタフェースが生成されるときに構築される。図7は、静的計測のための処理フローの例としてJavaベースのものを示す。この処理は、一つの可能なアプローチとしては、例えば、図1のエージェント108または112のようなエージェント700によって実装される。計測に対する一つのアプローチは、メソッドのような、どのコンポーネントが計測されるべきかを決める静的なルールを提供するものである。そのルールは、コンポーネントがアプリケーションにロードされる時にアクセスされる。そのようなアプローチでは、クラスローダ720は、トランスフォーマ715にアプリケーションのバイトコードの生のデータバイトを提供するのに使用され、トランスフォーマ715は、例えば、その生のデータバイトをクラスに変換する。例えば、Javaにおいては、このことは、クラスのロードに関与するClassLoaderオブジェクトのdefineClassメソッドを使用する。ClassLoaderクラスは、抽象クラスである。クラスの名前を付与すると、クラスローダは、クラスの定義を構成するデータを配置したり生成したりしようとする。代表的な手順は、名前をファイル名に変換し、ファイルシステムからその名前のクラスファイルを読み込むことである。defineClassメソッドは、バイトの配列をClassクラスのインスタンスに変換する。Classクラスのインスタンスは、Javaアプリケーションを実行中にクラスおよびインタフェースを表す。トランスフォーマ715は、したがって、このようなクラスを変換することによって計測を追加するためにバイトコードを変換することができるソフトウェアである。一つのアプローチでは、トランスフォーマ715の最小処理単位をクラスファイルおよびそのバイト配列とすることができる。アプリケーションのバイトコードが、判断ブロック710においてルール指令705に一致する場合、トランスフォーマ715はトレーサーのバイトコードの形式でプローブを追加する。アプリケーションのバイトコードが、判断ブロック710においてルール705に一致しない場合、トランスフォーマ715はそのバイトコードに計測を追加しない。トランスフォーマ715と判断ブロック710は、プローブビルダ725の一部と考えることができる。この実装では、ルール705は、計測されるべき管理されたアプリケーションの一部を特定する典型的な静的ルールの規定である。このルールは、通常、最初に仮想マシン内でクラスが定義されるときに実装される。クラスは、定義はたった一回であるが、複数回ロードすることができる。例えば、同じクラスをロードする複数のクラスローダが存在し得る。また、クラスなどのコンポーネントは、特定の方法で名前付けられるかどうか、特定のインタフェースで実装されるかどうか、特定の下位クラスまたは上位クラスを拡張するかどうか、等々に基づいて、計測され得る。そのようなコンポーネントは、有用あるいは興味深いパフォーマンスデータを提供する可能性があると考えられるので、計測されるべきものとして選択される。例えば、ルールは、少なくともいくつかのサーブレットは興味深いデータを提供し得ると考えられているので、すべてのサーブレットが計測されるべきであることを示すことがある。この場合、ルール705は、JavaクラスのHttpServletのサブクラスのすべてのコンポーネントを計測すべきであるとするものであってよい。HttpServletは、すべてのサーブレットが依存する抽象クラスである。しかしながら、すべてのコンポーネントが計測され得るわけではなく、包括的過ぎる計測は過度にオーバーヘッドコストがかかる結果となり、アプリケーションの動作性が損なわれる可能性があるという不安がある。その一方で、包括的でなさ過ぎる計測は、重要なパフォーマンスデータの欠落という結果に繋がるおそれがある。図7Bは、静的計測のための処理フローの例としてNETベースのものを示す。別の可能性のあるアプローチでは、管理されたアプリケーションのコンポーネントは、マイクロソフト社のNETフレームワークにより提供されている。Javaとは異なりNETフレームワークはクラスローダを使用しない。代わりに、NETは、フレームワーク用に特別に書かれたプログラムの実行を管理する仮想マシンを含む。NETフレームワークの実行環境は、共通言語ランタイムCLRとして知られている。CLRは、アプリケーション仮想マシンの外観を呈しており、プログラマは、プログラムを実行する特定のCPUの能力を考慮する必要がない。CLRは、セキュリティ、メモリ管理および例外処理などの他のサービスの提供もする。予めコード化されたソリューションのクラスライブラリとCLRは、共にNETフレームワークを構成している。また、CLRは、アプリケーションの開発および実行のための言語に中立的なプラットフォームを提供する共通言語基盤CLIの実装であり、例外処理、ガーベッジコレクション、セキュリティおよび相互運用のための各機能を果たしている。CLIは、コアクラスライブラリ、コモンタイプシステム、および、共通中間言語CILを含む。Javaバイトコードと同様に、CILは中間バイトコードの他の例である。JavaとNETは、実装の一例にすぎず、他の実装もまた可能である。ここでは、一つの可能なアプローチとして、処理がエージェント750によって実装される。一つの可能性のある状況では、NETフレームワーク内のいくつかの処理は、名前によってクラスを参照し、CLR770がクラスを発見し、トランスフォーマ765もしあればにそれを示し、その結果CILを使用する。特に、判断ブロック760にてそのクラスがルール755に一致する場合、計測が追加される。判断ブロック760においてそのクラスがルール755と一致しない場合は、計測は追加されない。トランスフォーマ765と判断ブロック760は、プローブビルダ775の一部であると考えることができる。図8Aは、呼び出し可能なメソッドを特定し、条件付き計測を適用することによりソフトウェアを解析するためのメソッドを示す。一つのアプローチでは、当該ソフトウェアに関連付けられているエージェントは、一部またはすべてのステップを実行する。上述したように、過度のオーバーヘッドを避けるために計測量は制限すべきであり、そのため、アプリケーションの動作を把握をする能力が制限される。時として、アプリケーションを診断しようとする際にソースコードが利用可能であればソースコードを見直す可能性はあるが、ソースコードは、通常、利用可能ではなく、殆どのユーザに対して容易に理解され得るものではない。その結果、ユーザは、アプリケーションを診断するための関連情報を得るのに、どの追加されたメソッドを計測するべきかをわからない。代わりに、その中で呼び出し可能なメソッドが呼び出されるコンテキストを特定することに加えて、現在は計測されておらずそれゆえ着目していない呼び出し可能なメソッドを選択的に発見することによって、アプリケーションのより深い理解と診断が可能となる。これらの追加メソッドは、診断セッション中に計測され、その後、この計測は削除することが可能である。ここで提供される技術もまた、カスタムソフトウェアに計測を追加するのに有用ではあるが、標準的な計測パッケージは、計測することが望ましいコードの一部を見落とす可能性がある。一般的に、特定のユーザトランザクションの実行を介してそのユーザトランザクションをフォローすることにより、また、シーケンス、期間、及び、メソッドの実行の順番を報告することにより、トレースはユーザにコードの問題の深い診断を実施させる。しかしながら、現在のアプローチは、メソッドの実行についてトランザクションスコープの内側と外側の区別をしないため、オーバーヘッドやノイズの多い情報をもたらす。さらに、コンテキストを使用することなく、異なるトランザクションに対する報告されたパフォーマンス基準メトリクスの軽重を決定することはできない。通常、ユーザは、トランザクショントレースを開始し、トレースされたメソッドの呼び出しから開始して、特定の種類のトランザクションにはパフォーマンスに問題があることを検出する。問題についてのさらなる情報を得るため、ユーザはトレースされたメソッドに条件付きトレーシングを適用することもできる。ステップ800は、アプリケーションの実行中に計測されたメソッドからパフォーマンスデータを取得することを含む。ここでは、例えば、図7Aおよび図7Bに関して記載した通り、アプリケーションにロードされたときにどのメソッドが計測されるべきかを決定する静的ルールなどに基づいて既に計測されたメソッドを含めることができる。別のアプローチでは、アプリケーションにロードされた後にメソッドが計測される。詳細は、図8Bに記載されている。ステップ802は、パフォーマンスデータに基づき、アプリケーション内における解析するための少なくとも一つの選択されたメソッドを特定することを含む。例えば、図4Aの例では、解析するメソッドはC4AまたはC4Bである。図5Aの例では、解析するメソッドはC6Aである。詳細は、図8Cに記載されている。ステップ804は、解析する少なくとも一つのメソッドの、一つまたはそれ以上の呼び出し可能なメソッドを特定することを含む。詳細は、図8Dに記載されている。ステップ806は、一つまたはそれ以上の呼び出し可能なメソッドのコンテキストを特定することを含む。詳細は、図8Eに記載されている。ステップ808は、解析する少なくとも一つのメソッド、および/または、解析する少なくとも一つのメソッドを含むコンポーネントのシーケンスの再計測を含む。詳細は、図8Gに記載されている。ステップ810は、コンテキストに基づいて、一つまたはそれ以上の呼び出し可能な条件付き計測を有するメソッドを計測することを含む。詳細は、図8Hに記載されている。ステップ812は、一つまたはそれ以上の呼び出し可能なメソッドがアプリケーションの実行中に引き続き呼び出され、コンテキストが合致したときに、その一つまたはそれ以上の呼び出し可能なメソッドからパフォーマンスデータを取得することを含む。そのパフォーマンスデータは、条件付き計測を実行することによって取得される。詳細は、図8Iに記載されている。図8Bは、図8Aのステップ800の詳細を示す。ステップ814は、呼び出されたときに、計測されたメソッドがエージェントにパフォーマンスデータを提供することを含む。ステップ816は、エージェントがマネージャにパフォーマンスデータを提供することを含む。ユーザインタフェース表示は、前述のように、ステップ817で更新される。図8Cは、図8Aのステップ802の詳細を示す。ステップ818では、パフォーマンスデータを許容可能なパフォーマンスレベルの範囲と比較する。ステップ816では、許容されないパフォーマンスの少なくとも一つのメソッドを特定する。このように、解析する少なくとも一つのメソッドは、パフォーマンスデータに基づき特定される。パフォーマンスデータは、例えば、その少なくとも一つのメソッドのパフォーマンの問題を示している。この特定は、例えば、継続的に、パフォーマンスデータを監視し、ユーザインターフェース上でユーザに報告を提供することによって、実行される。範囲外のパフォーマンスデータには、予め定められた範囲との比較に基づいて、自動的にフラグが設定される。ユーザは、次に、計測すべき一つまたはそれ以上のメソッドを手動により選択する。他の可能なアプローチでは、処理は完全に自動化されており、ユーザの介入を必要としない。それゆえ、特定されたメソッドは、そのパフォーマンスデータが、パフォーマンスが特定のパフォーマンスレベルを下回っていることや、あるいは重要なものであることを示すときに、自動的に計測される。図8Dは、図8Aのステップ804の詳細を示す。最初に、ステップ821にて、解析する少なくとも一つのメソッドのメソッド呼び出しが存在しているか否かを判断するためにキャッシュが確認される。キャッシュは、例えば、アプリケーションが実行中のアプリケーションサーバのエージェントの仮想マシン内に存在し得る。一般的に、キャッシュは実行性能のために提供され得る。アプリケーションが実行を開始するとき、キャッシュは空である。解析する少なくとも一つのメソッドがdoSomethingメソッドと呼ばれると仮定する。呼び出し可能なメソッドを検索する処理を開始する。最初にすることは、キャッシュの中を見ることである。呼び出し可能なメソッドがキャッシュにないときには、図8Dのステップ822-840が実行され、呼び出し可能なメソッドを特定し、それらをキャッシュに格納する。ステップ840では、doSomethingのために検索されるメソッド呼び出しを、以下の疑似コードを使用してキャッシュするcacheputメソッドが定義されているクラスdoSomething呼び出し可能なメソッド1呼び出し可能なメソッド2ここで、メソッドが定義されているクラスdoSomethingは、明確にdoSomethingメソッドを特定するためのキーであり、呼び出し可能なメソッドは、doSomethingのために特定された呼び出し可能なメソッドである。次に、プロシージャがdoSomethingメソッドのために起動され、キャッシュは以前に検索した情報を含む。キャッシュ内に呼び出されたメソッドに関する情報を持っているので、ステップ822-838を実行する必要はない。上述したように情報をキーによって検索する。ステップ822は、解析する少なくとも一つのメソッドのクラスをリフレクションを介して決定する。一つの可能性ある実装では、このことはJavaアプリケーションプログラミングインタフェースAPI、javalanginstrumentステップ824の使用を含む。解析する少なくとも一つのメソッドは、それが一つまたはそれ以上の呼び出し可能なメソッドを起動したり呼び出したりすることから、呼び出しメソッドであると考えられる。ステップ822には、メモリ内、例えばJVM内のすべてのロードされたクラスの中からJavaクラスをフェッチすることを含めてもよい。ステップ826は、例えば、バイトコードが取得された元のリソース場所から、クラスのバイトコード表現をロードすることを含む。実装例では、可能な場合には、JavaクラスのClassLoaderが使用されるステップ828。自動的に生成された非常に大きなクラスがメモリをいっぱいにしないように、安全のための予防策がメモリにロードされるコードの量を制限することに留意されたい。ステップ830は、呼び出しバイトコードの一つまたはそれ以上のインスタンスを特定するために取得された各クラスのバイトコード表現の構文解析を含む。特定の実装においては、このことは、クラスのバイトコード表現内の特定のオペコードオペレーションコードを特定することを含むステップ832。例えば、Java言語の4つのオペコードが、別のメソッドを呼び出すバイトコードを特定する。具体的には、仮想呼び出しのためのオペコードは10進値182または16進値0xb6またはb6であり、特定呼び出しのオペコードは10進値183または16進値0xb7またはb7であり、静的呼び出しのオペコードは10進値184または16進値0xb8またはb8であり、および、インタフェース呼び出しのオペコードは10進値185または16進値0xb9またはb9である。これらのオペコードのいずれかが存在することが、呼び出し可能なメソッドを特定する。ステップ832を、すべての可能なオペコードよりも少ない、一つまたはそれ以上の特定のオペコードを検出することに制限することも可能である。例えば、インタフェースメソッドが重要でない場合、オペコードが、仮想呼び出し、特殊呼び出しおよび静的呼び出しの場合は検知し、インタフェース呼び出しの場合は検出しないように決定することができる。ステップ834では、一つまたはそれ以上の呼び出しバイトコードのインスタンスに基づいて、一つまたはそれ以上の呼び出し可能なメソッドを特定する。実装例では、一つまたはそれ以上の呼び出し可能なメソッドは、ステップ822で決定されるクラスの定数プールから抽出される。特に、ステップ836では、オペコードに基づき定数プールテーブル内のエントリに対するインデックスを特定し、ステップ838では、その一つまたはそれ以上のインデックスに基づき、参照されるメソッドを特定する。ステップ840では、一つまたはそれ以上の呼び出し可能なメソッドを、文字列としてキャシュに格納する。そのメソッドは、一つまたはそれ以上の参照されるメソッドであって、例えばdoSomethingのために呼び出されるメソッドである。図8Dの処理は、同時に、または、異なる時間に、複数の異なるメソッドに対して個別に実行可能であることに留意されたい。図8Eは、図8Aのステップ806の詳細を示す。ステップ842は、解析する少なくとも一つのメソッドおよび/または解析する少なくとも一つのメソッドを含むシーケンスといったメソッドのシーケンスを特定することを含む。このことは、図5Dのユーザインタフェース表示500の領域508においてユーザへの報告に使用されるのと同じパフォーマンスデータを使用して行なわれることが可能である。基本的に、各メソッドは、解析する少なくとも一つのメソッドを呼び出すようにつながるメソッドのシーケンスにおけるインスツルメンテーション計測から知られている。例えば、図5Dにおいて、もしC6Aが解析するメソッドであれば、次の低いレベルにツリーを辿ることで、C6A1、C6A2およびC6A3を条件付き計測が追加されたメソッドであることが判明する。さらに、それぞれの高いレベルへツリーを辿ると、シーケンス長が2コンポーネント/メソッドのときは解析する少なくとも一つのメソッドを含むメソッドのシーケンスはC5-C6Aであり、シーケンス長が3コンポーネント/メソッドのときはC4A-C5-C6Aであり、シーケンス長が4コンポーネント/メソッドのときはC3A-C4A-C5-C6Aである、等々が判明する。ステップ844は、解析する少なくとも一つのメソッドに関連付けられている、および/または、解析する少なくとも一つのメソッドを含むシーケンスといったメソッドのシーケンスに関連付けられているトランザクションデータを特定することを含む。上記の例では、当該トランザクションデータがユーザの分類を示すことがある。また、多くの別の種類のトランザクションデータが可能である。一つの可能な実装において、トランザクションデータは、特定のデータフィールド内にあり、それは一つまたはそれ以上のアプリケーション内のメソッドの間で渡されたものである。例えば、ユーザからのリクエストは、UserClasspremiumというデータフィールドおよび値を有することができる。UserClasspremiumは、条件付き計測によって解析されるトランザクションデータとすることができる。UserClasspremiumの場合、コンテキストが合致する。UserClassmediumまたはUserClassregularの場合、コンテキストは合致しない。図8Fは、図8Aのステップ808の詳細を示す。ステップ846は、解析する少なくとも一つのメソッドのクラス、および/または、解析する少なくとも一つのメソッドを含むシーケンスのようなメソッドのシーケンスに、各メソッドの開始と終了での条件付きアンカーを有するように再定義することを含む。クラスの再定義は、図10にて詳しく説明される。条件付きアンカーは、図8Iおよび図8Jにて詳しく説明される。ステップ848は、一つまたはそれ以上の再定義されたクラスをロードすることを含む図10も参照のこと。ステップ850は、一つまたはそれ以上の再定義されたクラスに基づくバイトコード計測を提供することを含む図10も参照のこと。図8Gは、図8Aのステップ810の詳細を示す。ステップ852は、条件が一致するかどうかを決定するためにスレッドローカルキャッシュのようなメモリリソースをチェックする条件付き計測を含むように、一つまたはそれ以上の呼び出し可能なメソッドを再定義することを含む。ステップ854は、一つまたはそれ以上の再定義されたクラスをロードすることを含む。ステップ856は、一つまたはそれ以上の再定義されたクラスに基づくバイトコード計測を提供することを含む。図8Hは、図8Aのステップ810の他の実装の詳細であり、図8Gの処理に加えて実行され得るものである。図1に関連して述べたように、複数のアプリケーションサーバはセントラルマネージャと通信するエージェントをそれぞれ有することがある。したがって、エージェントは、アプリケーションのような同じコードで別々のインスタンスを含んでいる実行中のアプリケーションサーバであるJVMのクラスタに展開され得る。エージェントA1108のような一つのエージェントが、アプリケーションにおける少なくとも一つのメソッドを解析し、一つまたはそれ以上の参照されたメソッドを決定する場合、一またはそれ以上の関連するメソッドの特定は、一またはそれ以上の他のエージェントによって、例えばマネージャ120を介して、共有され得る。例えば、エージェントA1108は、呼び出し可能なメソッドなど、メソッド呼び出しの新しい規定が指定されたクラスやメソッドに対して抽出されたことを、マネージャ120に通知しても良い。マネージャ120は、次に、興味を持っているクラスタ内の他のエージェント、例えばエージェントA2112に、情報をプッシュ転送することを決定する。これにより、他のエージェントにおけるメソッドの呼び出し検出ステップの繰り返しを避けることができ、エージェントが、発見された呼び出し可能なメソッドの異なるインスタンスからパフォーマンスデータを収集できるようになる。アプリケーションの別のインスタンスの同じメソッドのパフォーマンスデータを見ることによって、アプリケーションの動作をより詳細に把握することが可能となる。例示の処理では、ステップ858では、一つまたはそれ以上の呼び出し可能なメソッドをアプリケーションの最初のインスタンスに関連づけられている最初のエージェント108からマネージャに報告する。ステップ860では、マネージャは、一つまたはそれ以上のアプリケーションのインスタンスに関連付けられている一つまたはそれ以上の他のエージェント112に、一つまたはそれ以上の呼び出し可能なメソッドの特定をプッシュ転送する。ステップ862では、一つまたはそれ以上の他のエージェントが、アプリケーションの一つまたはそれ以上の他のインスタンスにおける一つまたはそれ以上の呼び出し可能なメソッドの一つまたはそれ以上の他のインスタンスを計測する。図8Iは、図8Aのステップ812の詳細を示す。ステップ864では、コンテキストの最初のメソッドが呼び出される。いくつかのケースでは、コンテキストが、解析されているメソッドが条件付き計測を伴うメソッドを呼び出すことを要求するだけの場合のように、コンテキスト内にはたった一つのメソッドのみが存在する場合がある。他のケースでは、コンテキストは、条件付きの計測を伴うメソッドが呼び出される前に、特定のシーケンスまたは一連のメソッドの呼び出しを要求する。ステップ866では、コンテキストの最初のメソッドの開始時の条件付きのアンカーが実行され、そのメソッドが実行を開始したことをスレッドローカルキャッシュに通知する。その最初のメソッドは、必ずしもコンテキスト内でのメソッドのシーケンスにおけるその位置を示す必要はない例えば、1番目、2番目...。詳細については、図8Jを参照されたい。条件付きアンカーは、メソッドの計測におけるコードによって提供され得る。メソッドは、その計測を通して、エージェントにパフォーマンスデータも提供する。パフォーマンスデータは、単にそのメソッドが実行開始したことを示すだけの場合がある。判断ステップ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の計測の条件付きのアンカー/コードはメッセージをスレッドローカルキャッシュへ送る。そのメッセージは、当該メソッドの識別子/名前、例えばMethodNameC4A、及び、実行ステータス、例えば、ExecutionStatusExecuting、を含む。この情報は、そのメソッドが実行中であることの指標としてスレッドローカルキャッシュに格納される。同様に、t7において、C5は実行を開始し、C5の計測の条件付きのアンカー/コードはメッセージをスレッドローカルキャッシュへ送る。そのメッセージは、当該メソッドの識別子/名前、例えばMethodNameC5、及び、実行ステータス、例えばExecutionStatusExecuting、を含む。この情報は、スレッドローカルキャッシュに格納される。t8において、C6Aは実行を開始し、C6Aの計測の条件付きのアンカー/コードはメッセージをスレッドローカルキャッシュへ送る。そのメッセージは、当該メソッドの識別子/名前、例えばMethodNameC6A、及び、実行ステータス、例えばExecutionStatusExecuting、を含む。この情報は、スレッドローカルキャッシュに格納される。t9において、C6A1がC6Aによって呼び出されるとき、C6A1の条件付き計測はスレッドローカルキャッシュにリクエストを送り、一つまたはそれ以上の特定のメソッドの実行ステータスを読み出す。これは、一つまたはそれ以上のメソッドが実行中であることの一つまたはそれ以上の指標にアクセスするためのメモリリソースからのリクエストである。このリクエストは、MethodNameC4AC5andC6Aに対する疑似コード:RetrieveExecutionStatusによって表される。C6A1の条件付き計測は、この情報にアクセスし、それを使ってコンテキストが一致しているか否かを判断する。上述したように、付加的にまたは代替として、コンテキストが一致しているか否かを判断するのにトランザクションデータがC6A1の条件付き計測によって使用されることもある。一つの可能性のある実装において、トランザクションデータはC6AによってC6A1の条件付き計測に渡され、これによって、C6A1の条件付き計測がスレッドローカルキャッシュからトランザクションデータにアクセスしないようにすることができる。しかしながら、トランザクションデータが、コンテキスト内のメソッドによって提供され、コンテキストに合致しているかどうかを決定するのに条件付き計測によってアクセスされるようにすることも可能である。コンテキストは一致しているとC6A1の条件付き計測が判断するとき、C6A1の条件付き計測は、少なくとも一つの呼び出し可能なメソッドの実行に関する報告を行う。この実行は、C4A、C5およびC6Aからアクセスされた一つまたはそれ以上の指標の少なくとも一部に基づいている。続いて、コンテキスト内のメソッドが続けて実行を停止する。t16において、C6Aは実行を停止し、C6Aの計測の2番目の条件付きアンカー/コードはスレッドローカルキャッシュへメッセージを送信する。そのメッセージは、当該メソッドの識別子/名前、例えばMethodNameC6A、及び、実行ステータスを削除/消去するリクエスト、例えばRemoveExecutionStatus、を含む。または、リクエストは、ExecutionStatusNotExecutingという実行ステータスを設定するために送られるものであってもよい。t17において、C5は実行を停止し、C5の計測の2番目の条件付きアンカー/コードはスレッドローカルキャッシュへメッセージを送信する。そのメッセージは、当該メソッドの識別子/名前、例えばMethodNameC5、及び、リクエストRemoveExecutionStatus、を含む。t18において、C4Aは実行を停止し、C4Aの計測の2番目の条件付きアンカー/コードは、スレッドローカルキャッシュへメッセージを送信する。そのメッセージは、当該メソッドの識別子/名前、例えばMethodNameC4A、及び、リクエストRemoveExecutionStatus、を含む。条件付きアンカーは、メソッドの開始と終了にて、コンテキスト内でトレースされるメソッドのバイトコードに付加されるトレーサーである。トレーサーは2つの動作を実行する。即ち、メソッドが呼び出されて実行を開始したときに呼ばれたという事実を、例えばマップのようなデータ構造で、スレッドローカルキャッシュに格納することと、そのメソッドの終了時にその情報を削除することである。条件付きアンカーの使用によって発生するオーバーヘッドは最小限である。一つの可能なアプローチでは、条件付きアンカーのトレーサーは一定のアクセス時間でマップ構造を更新する。そのマップは、スレッドローカルキャッシュ内にあるので競合がない。同様に、条件付き計測の使用によって発生するオーバーヘッドは最小限である。スレッドローカルキャッシュに代わるものとして、メソッドの条件付き計測は、コンテキストが一致するかどうかを判断するのに、メソッドの呼び出し時に、呼び出しスタックを解析することもよい。上述したように、呼び出しスタックは、一つまたはそれ以上のプログラムまたはスレッドの実行中に呼び出された、又は起動されたメソッドを特定する。このアプローチでは、そのメソッドは、呼び出しスタックが、コンテキストが一致していることを示しているかどうかを判断する。スレッドローカルキャッシュの使用は、スタックの深さに応じて大幅にアクセス時間が長くなってしまうスタック調査が必要ないので、より効率的である。図9は、900でまとめて示しているが、図8Dのメソッドに関連して使用されるソフトウェアおよびハードウェアを示す。ハードウェアは、メモリリソースである、動的計測キャッシュ902およびスレッドローカルキャッシュ904図8Jを参照と、その他のメモリリソース915を含む。スレッドローカルキャッシュは、スレッドに専用の静的またはグローバルなメモリリソースである。Javaでは、スレッドローカル変数はThreadLocalクラスにて実装される。ThreadLocalオブジェクトは、オブジェクトのgetメソッドまたはsetメソッドを呼び出すスレッドごとに、変数の別々のインスタンスを保持する。動的計測キャッシュは、解析されているメソッドに対して特定された呼び出し可能なメソッドを格納する。その呼び出し可能なメソッドは、同じメソッドの解析が続けて行われる場合、キャッシュから直ちに特定することができ、これにより、コンピューティングリソースの消費量の削減が可能となる。リソース915は、アプリケーションが実行され計測されるときにメモリにロードされるアプリケーションの異なるクラスのバイトコードを格納するのに使用される記憶場所となり得る。一つの可能性のある実装において、動的計測キャッシュ902およびリソース915は、アプリケーションサーバ内の図2のメモリ240内に用意される。図8Dのステップ822および824に対応して、JavalanginstrumentAPI910は、ロードされたすべてのクラス905へのアクセスに使用され、解析されている少なくとも一つのメソッドの特定のクラス925を特定する。一つのアプローチでは、ロードされたすべてのクラスは配列で提供される。図8Dのステップ826および828に対応して、クラスローダ920は、リソース915へのアクセスに使用され、クラス925に対するバイトコード930をロードする。図8Dのステップ830および832に対応して、クラスバイトコード930は構文解析され、オペコード935、940、945および950の一つまたはそれ以上のインスタンスが特定される。図8Dのステップ834、836および838に対応して、各オペコードは、定数プール955からメソッド呼び出しの文字列をフェッチするために使用されるインデックスバイトをそれぞれ持つことができる。図10は、ソフトウェアを計測するための処理フローの例を示す。図5Aに対応して、計測されたバイトコードを提供するためのトランスフォーマ/プローブビルダ1000による使用のためのバイトコードをロードするクラスローダ1002にコンポーネントの静的リスト1010が用意される。そのバイトコードは、任意で機械語にコンパイルされる。例えば、defineClassメソッドがバイト配列をClassクラスのインスタンスに変換する。さらに、図8Aの処理によって発見されたメソッドのような発見されたコンポーネント1006は、計測され得る。一つのアプローチでは、図5Dに示されているように、ユーザインタフェース1008は、計測すべきものとして、発見されたコンポーネントをユーザに指定させることができる。ユーザもまた静的リスト1010を変更することができる。ユーザインタフェースは、管理されたアプリケーション内に存在する既存のインスツルメンテーション計測から流入するパフォーマンスデータを監視するパフォーマンスモニタ1012に応答することができ、例えば、あるコンポーネントがトランザクションにおいて実行に時間がかかっているというような問題を起こしている事実を特定することができる。パフォーマンスデータは、範囲外にあるかどうかを判定するために上側および下側の閾値と比較される。発見されたコンポーネントは、計測されるべきクラスの動的更新可能なリストを含み得る。このリストは、診断が行われる限られた期間内に特定のメソッドが計測されるように随時変更することができる。ユーザインタフェース1008によって時間期間を指定することができるし、既定の時間期間が使われてもよい。したがって、コンポーネントは、例えば、インスツルメンテーション計測を有しないある時点からインスツルメンテーション計測を有する別の時点まで変換するように、再定義され得る。種類またはレベルが異なる計測を提供することが可能で、例えば、高いレベルの計測では、コンポーネントのパフォーマンスの多くの側面が追跡され、低いレベルの計測では、コンポーネントのパフォーマンスの少ない側面が追跡される。コンポーネントを再定義することは、種類の異なる計測へのトランザクションを含み得る。計測は、多くの種類のパフォーマンス基準メトリクス/データを生成することができ、それらには、コンポーネントの平均実行または応答時間、毎秒または間隔ごとの呼び出し率、呼び出し回数、開始したが終了していない間隔ごとの呼び出しの回数を示す同時実行のメトリック、呼び出しを開始した間隔ごとのメソッド呼び出しの回数が特定の閾値を超えた呼び出し回数を示すストール状態のメトリックが含まれる。また、そのデータは、ガーベジコレクションのヒープサイズ、ファイルやソケットのアクティビティを示すバンド幅メトリック、スレッドの数、システムログ、例外処理、メモリリークおよびコンポーネントの相互作用、を特定する。そのデータは、どのコンポーネントが計測されたコンポーネントによって呼び出されたか、またはどれが計測されたコンポーネントを呼び出すか、を特定することもできる。例えば、コントローラのアーキテクチャにおいては、コンポーネントを管理するコントローラコンポーネント内の制御フローは、次に実行されて、どのくらいの頻度で実行され、どのように実行されるかを知っている。コントローラコンポーネントは、計測を介して、計測されていないどのコンポーネントが頻繁に呼び出され、その結果、おそらく重要で計測を付加するために再定義される必要があることを報告する。上述のように、計測の種類を変更するためにコンポーネントを再定義することが可能である。例えば、既存の計測が問題を検出しているときには、例えば、一つまたはそれ以上のパラメータが範囲外に存在する結果、より多くの計測が付加される可能性がある。また、付加された計測は、計測が通常の状態に戻った場合、その後に削除されることがある。削除は、ユーザのコマンドに基づいて、あるいは、ユーザの介入なしに自動的に行われる。発見されたコンポーネント1006、ユーザインタフェース1008、コンポーネントの静的リスト1010、および、パフォーマンスモニタ1012は、同じ場所または異なる場所に提供されることに留意されたい。例えば、ユーザインタフェース1008は、ユーザインタフェースホスト122図1に提供されることが可能であり、発見されたコンポーネント1006およびコンポーネントの静的リスト1010は、アプリケーションサーバ106または110に提供されることが可能であり、そして、パフォーマンスモニタ1012は、エージェント108および112からのパフォーマンスデータをアプリケーションサーバ106、110でそれぞれ受信するマネージャ120に、関連付けられることが可能である。パフォーマンスモニタ1012は、呼び出されたどのコンポーネントが問題のトランザクションに関与しているかの見解を提供し、これらのコンポーネントに問題があるのか、問題を起こすのかを判断し、ユーザインタフェース1008上でこの情報を特定することができる。ユーザインタフェース1008は、例えば、発見されたコンポーネントを含み、どのコンポーネントを計測させるべきであるか、あるいは、計測しないのかを、ユーザに手動で選択させることができる。異なった種類が利用可能であるときは、計測の種類は、ユーザインタフェースを介して指定され得る。コンポーネントの静的リスト1010は、アプリケーションの実行開始時に計測されるべきクラスまたは他のコンポーネントを含んでよい。このことは、重要なデータを生成すると予期されているコンポーネントのベースラインリストにすることができる。一つのアプローチでは、発見されたコンポーネント1006のリストは、次回、システムが起動したときに同じコンポーネントが計測されるように、存続させることもできる。このことは、ユーザが一定のデータ、レポートやコンポーネントからのパフォーマンスデータを持つことができるようにし、ユーザに環境をセットアップさせる良い方法を提供する。コンポーネントは、そのコンポーネントがアプリケーションの実行時に既に組み込まれているかどうかに応じて異なる方法で再定義されることができる。コンポーネントがアプリケーションにまだ組み込まれていない場合には、一つの可能な実装として、JMVなどのクラスローダ1002によって、正常に組み込まれることが可能である。例えば、NETフレームワークを使用するような他の実装においては、クラスローダは使用されない。コンポーネントがロードされる場合には、例えば、命令があると、ユーザインタフェース1008、発見されたコンポーネント1006、コンポーネントの静的リスト1010およびパフォーマンスモニタ1012、に応答して、トランスフォーマ/プローブビルダ1000がコンポーネントを計測する。アプリケーションにすでに組み込まれているが未計測のコンポーネントは、計測によりアプリケーションに再組み込みされることができる。例えば、コンポーネントは、アプリケーションから削除することができ、仮想マシンを再起動することなく実行中にリロードすることが可能である。これを達成するためには、JavaのredefineClassコマンドが当該コンポーネントとともにクラスローダ1002に提供される。Java開発キットJDKバージョン1.5またはそれ以降のバージョンがこのコマンドを使用した再定義機能を備えている。このコマンドは、提供されたクラスファイルを使用して提供されたクラスのセットを再定義する。それは、同時に1つ以上のクラスの変更を連動させるためにセットで動作する。また、再定義されたメソッドがスタックフレームを起動している場合には、これらの動作中のフレームが元のメソッドのバイトコードの実行を続行し、再定義されたメソッドが新しい呼び出しで使用される。コンポーネントを例えばクラスのように再定義することは、クラスに対してのみではあるが仮想マシンを再起動することに類似している。クラスが再定義されると、そのクラスは、既存のメソッドがスタックに既に存在する場合には、そこにとどまる。しかし、すべての新しいメソッドが呼び出される場合には、新しいクラスが使用される。つまり、一旦、再定義されると、新しいバージョンがピックアップされる。トランスフォーマ/プローブビルダ1000は、再定義されたコンポーネントを受信する場合、もしそうするように命令されていたのであれば、そのコンポーネントを計測する。トランスフォーマ/プローブビルダ1000は、特定の種類の計測をコンポーネントに追加することも可能である。発見されたコンポーネントは、計測された後、アプリケーションに再組み込みされて、計測が診断のために必要ではなくなると、そのコンポーネントは、計測は行われることなく、再度、アプリケーションに再組み込みされる。この計測の削除は、特定された診断期間または他のいくつかの他のイベントの後、ユーザコマンド、タイムアウトに基づいて行われる。例えば、パフォーマンスモニタ1012は、発見されたコンポーネントのパフォーマンスデータが、特定の期間に対して、または、コンポーネントの呼び出し数に対して許容されているかを判断してもよい。つまり、パフォーマンスモニタ1012は、計測されたメソッドの少なくとも一つのメソッドのパフォーマンスデータがもはやパフォーマンスレベルの閾値に合致しそうもないということを判断する。応答においては、パフォーマンスモニタ1012は、例えば、インスツルメンテーション計測を削除するためにredefineClassのようなコマンドを発行することができる。計測の付加および削除は実行時に動的に行われ、それによって、バイトコードが実行されている仮想マシンはダウンさせられる必要はなく、計測されたコンポーネントからのデータは直ちにアクセスされ得る計測を付加する場合。以上、本発明の具体例を詳細に説明したが、これらは例示に過ぎず、本発明の範囲を限定するものではない。上記した技術には、以上に例示した具体例を様々に変形、変更したものが含まれる。上記した実施形態は、本発明の原理をベストに説明するために選定されたものであり、その実用に際しては、本発明が最適にその有用性を発揮するように、その特定用途に適するように当業者が様々に変形し得る。発明の範囲は、ここに添付した特許請求の範囲によって定められることを意図している。"