JP2009064124A - 性能データ収集・表示システム、性能データ表示装置、そのプログラム - Google Patents

Abstract

【課題】効率的且つ的確な性能ボトルネック分析を可能とする。
【解決手段】第１の性能データ収集プログラム１６は所定のログ出力を行うと共に、セッションＩＤ、リクエストＩＤをスレッド固有変数領域３１に格納する。第２の性能データ収集プログラム１７は、アプリケーションプログラム（Javaクラス１２）からの呼び出しに応じて、スレッド固有変数領域３１から取得したセッションＩＤ、リクエストＩＤに対応付けて関数の性能データをログ出力する。ログ記録内容に基づいて、例えば各セッション・リクエスト毎の関数の性能データの表示を行う。
【選択図】図５

Description

本発明は、クライアントとサーバからなるシステムにおいて、クライアントからの要求に応じてサーバ上で実行されるアプリケーションプログラムの、関数単位の性能データ収集方式に関する。

クライアントとサーバからなるシステムにおいて、サーバ上で動作するアプリケーションプログラムの応答が遅いなど性能に問題がある場合に、アプリケーションプログラムの性能（例えば、どの関数の処理に時間がかかっているのか等）を調べる方法としては、アプリケーションプログラムのソースプログラムに性能データ（上記関数の処理時間等）を収集する仕組みを組み込む方法が一般的であった。

図２２に、従来のシステム構成及び性能データ収集方式を示す。
図２２において、クライアント１００は、例えば一般ユーザが所有するパソコン等の汎用コンピュータであり、一般的なＯＳ１０２環境上でブラウザ等のクライアントプログラム１０１を実行することにより、不図示のＬＡＮ、インターネット等のネットワークを介してＷｅｂ／Ａｐサーバ８０にアクセスして任意の処理を要求する。例えばホームページ等を表示する。

Ｗｅｂ／Ａｐサーバ８０は、Ｗｅｂサーバ／Ａｐ（アプリケーション）サーバであり、各種アプリケーションプログラムを実装し、クライアント１００からの要求に応じたアプリケーション実行を行い、例えばクライアント１００側のディスプレイにホームページの表示等を行わせる。

この各種アプリケーションは、ＪＳＰ／Ｓｅｒｖｌｅｔ８１、Ｊａｖａクラス８２より成る。尚、これら各種アプリケーションは、図示の通り、一般的なＪａｖａ実行環境上（ＯＳ８５、ＪａｖａＶＭ（Ｊａｖａ仮想マシン）８４、Ｓｅｒｖｌｅｔコンテナ８３）で実行されることになる。また、ＪＳＰは、Java Server Pagesの略である。

各種アプリケーションは、概略的には、ＪＳＰ／Ｓｅｒｖｌｅｔ８１が基本動作を行い、ＪＳＰ／Ｓｅｒｖｌｅｔ８１が必要なＪａｖａクラス８２を随時呼び出し、呼び出されたＪａｖａクラス８２のメソッド（関数）の処理が実行される。

上記ＪＳＰ／Ｓｅｒｖｌｅｔ８１、Ｊａｖａクラス８２より成る各種アプリケーションのうち任意のアプリケーション（特にＪａｖａクラス８２の各メソッド（関数））について、その性能データ（例えば各関数の処理時間等）収集を行いたい場合、開発用ＰＣ（パソコン）９０上で、まず、当該性能データ収集対象のアプリケーションのソースコードファイルを開いて、オペレータ等が手作業で、このソースプログラムに性能データ収集処理を追加・記述する（図２２上に示す（１））。

続いて、この新たなソースコード９１（性能データ収集処理が追加記述されたソースコード）をコンパイルして実行モジュール９２（性能データ収集機能付き）を生成する（図２２上に示す（２））。そして、Ｗｅｂ／ＡＰサーバ８０において、上記性能データ収集対象のアプリケーション（実行モジュール）を、上記性能データ収集機能付きの実行モジュール９２に入れ替える（図２２上に示す（３））。

その後は、実行モジュール９２を実行することで、性能データ（各関数の処理時間等）
収集処理も行われることになる。
例えばサーバ上で動作するアプリケーションプログラムの応答が遅い等、性能に問題があるときに、原因を特定する為に、ＯＳ、ミドルウェア、アプリケーションプログラムの性能データ（各関数の処理時間等）を収集して、該収集した性能データを分析してグラフ表示を行うことは、従来から、よく行われていることである。

そして、従来では、上記のように、各アプリケーションプログラム（Ｊａｖａクラス８２等）に性能データ収集処理を埋め込み、各関数の処理時間等を収集して分析することで、例えば図２３（ａ）に示すように関数別に処理時間をグラフ表示する。また、ＯＳ、ミドルウェアの性能データは、例えばWindows（登録商標）のパフォーマンスモニタなどの既存の機能により収集でき、収集したデータを例えば図２３（ｂ）に示すようにグラフ表示していた。

尚、よく知られているように、Ｊａｖａにおけるメソッドは“関数”に相当するものであり、上記の通り関数と呼ぶ場合もある。
また、特許文献１に記載の従来技術は、ログ情報採取解析装置に関し、プログラム実行時の動作状況を示すチャートの表示部分とソースプログラムとの対応をとるようにすることを目的としている。この発明では、利用者が指定したチャート上の位置情報からその位置に対応するソースプログラム上の関数名および行番号を知ることが出来る。その逆に、利用者が指定した関数名および行番号から、チャート上の表示位置を知ることができる。
特開平９−２５９０１１号公報

上述した従来技術では、以下の課題が発生していた。
（１）アプリケーションプログラムの性能データの収集・集計結果には、各関数毎にこの関数が呼ばれたときのクライアント（ブラウザ）やリクエストを識別する情報が無いので、クライアント／リクエストに対応した関数の処理時間が把握できないため、クライアントやリクエスト固有の問題があった場合に特定が困難であった。

（２）ＯＳ／ミドルウェアの性能データとアプリケーションの性能データをそれぞれ別々に表示することしかできない為、アプリケーションの動きとＯＳ／ミドルウェアの状態との相関関係が掴み難く、効率的な原因分析が行えない。

本発明の課題は、各関数毎にその関数実行に係るクライアント／リクエストを識別できる性能データ収集が行えることで、クライアントやリクエスト固有の問題があった場合に特定が容易となり、更にアプリケーションプログラムの関数単位の処理時間と、ＯＳ／ミドルウェアのリソース状況を重ね合わせて可視化表示（表、バー、グラフ等による表示）することで、効率的且つ的確な性能ボトルネック分析が可能となる性能データ収集・表示システム、性能データ表示装置、そのプログラムなどを提供することである。

本発明の性能データ収集・表示システムは、任意のクライアントから任意のリクエストを受け付ける毎に、このリクエストに応じたセッションＩＤ、リクエストＩＤを所定の記憶領域に記憶すると共に、該セッションＩＤとリクエストＩＤとに対応付けて所定のログ情報を記録する第１の性能データ収集手段と、前記リクエストに応じて所定の１以上の関数の処理を実行するアプリケーション実行手段と、前記アプリケーション実行手段による前記各関数の処理実行時に、前記所定の記憶領域から前記セッションＩＤ、リクエストＩＤを取得して、該セッションＩＤとリクエストＩＤとに対応付けて前記各関数の処理実行に係る所定の性能データを前記ログ情報に追加記録する第２の性能データ収集手段と、
ＯＳ／ミドルウェアのリソース状況を示すデータを収集するリソース状況データ収集手段と、前記記録されたログ情報に基づいて、任意の前記各リクエストに応じた処理全体の開始日時、終了日時、処理時間を求め、又は前記各関数毎にその関数の処理の開始日時、終了日時、該関数の処理実行に掛かった時間である実行時間を求めて、該求めた情報を前記セッションＩＤ及びリクエストＩＤに対応付けて成る内部データを生成・記憶する内部データ生成・記憶手段と、前記内部データに基づいて、任意の前記各リクエスト毎の処理全体の処理時間又は該処理全体中の各関数の前記実行時間を示す可視化表示を行うと共に、これと同一時間軸上に前記リソース状況データに基づく可視化表示を重ね合わせて表示する表示手段とを有する。

上記性能データ収集・表示システムでは、上記任意のクライアントからの任意のリクエストに応じたセッションＩＤとリクエストＩＤとに対応付けて、各関数の性能データ等が記録される。よって、この記録を参照／分析すれば、例えば各セッション・リクエスト毎の処理全体の処理時間やこの処理全体中の各関数の実行時間等が求められ、これとリソース状況データとに基づいて表示を行うことで、問題がある箇所（例えばリソース状況が悪化する時間帯におけるセッション・リクエストの処理等）が、容易に把握できるようになる。あるいは、例えば同じ関数であっても、特定のセッション・リクエストに対応するものの性能データのみが悪ければ（実行時間が長い等）、この特定のセッション・リクエストに固有の何らかの問題があることが推測できる。

また、上記性能データ収集・表示システムにおいて、例えば、前記第２の性能データ収集手段と前記アプリケーション実行手段を実現させるプログラムは、所定のログ出力処理と任意の各ログ出力対象／ログ出力箇所とが記述されたアスペクトソースファイルと、前記関数の処理に係るアプリケーションプログラムとをアスペクトコンパイルすることで生成される。

これにより、各アプリケーションプログラム毎に逐一必要な箇所にログ出力処理を追加するような手間が掛かることは必要なく、１つのアスペクトソースファイルを作成すれば済む。

本発明の性能データ収集・表示システム、性能データ表示装置、そのプログラムなどによれば、特に各関数毎にその関数実行に係るクライアント／リクエストを識別できる性能データ収集が行えることで、クライアントやリクエスト固有の問題があった場合に特定が容易となり、更にアプリケーションプログラムの関数単位の処理時間と、ＯＳ／ミドルウェアのリソース状況を重ね合わせて可視化表示（表、バー、グラフ等による表示）することで、効率的且つ的確な性能ボトルネック分析が可能となる。更に、性能データ収集の為の処理を容易に追加可能となる。

以下、図面を参照して本発明の実施の形態について説明する。
図１に、本例のクライアントとサーバからなるシステムのシステム構成図を示す。
図１において、クライアント１００は、上記従来のクライアント１００と同じであってよく（ブラウザ搭載の一般ユーザのパソコン等）、同一符号を付し、説明は省略する。

図示のＷｅｂ／Ａｐサーバ１０は、上記従来のＷｅｂ／Ａｐサーバ８０と同様に、一般的なＪａｖａ実行環境上（ＯＳ１５、ＪａｖａＶＭ（Ｊａｖａ仮想マシン）１４、Ｓｅｒｖｌｅｔコンテナ１３）で、各種アプリケーションが実行されることになる。各種アプリケーションは、ＪＳＰ／Ｓｅｒｖｌｅｔ１１、Ｊａｖａクラス１２等より成る。従来で説明したように、ＪＳＰ／Ｓｅｒｖｌｅｔ１１が各Ｊａｖａクラス１２を呼び出すものであ
り、各Ｊａｖａクラス１２は１以上のメソッド（関数）を実行するものであり、概略的にはＪａｖａクラス１２をメソッド（関数）と見做してもよい。

そして、本例の構成では、Ｗｅｂ／Ａｐサーバ１０は、更に、第１の性能データ収集プログラム（Servletフィルタ）１６と第２の性能データ収集プログラム１７を有する。
尚、第１の性能データ収集プログラム（Servletフィルタ）１６と第２の性能データ収集プログラム１７（その他、ＪＳＰ／Ｓｅｒｖｌｅｔ１１、Ｊａｖａクラス１２等の他の各種プログラムも）は、例えば後述する図２１に示す記憶部７５に格納されており、これをＣＰＵ７１が読み出し・実行することにより、所定の機能・動作を実現するものであり、以下、特に逐一断らないが、当然、以下の説明における各種プログラムに係る機能・動作の説明は、これら各種プログラムがＣＰＵ７１等の演算プロセッサにより実行されることにより実現される機能・動作を説明しているものである。

第１の性能データ収集プログラム（Servletフィルタ）１６は、Javaのサーバアプリケーション形態の一つであるServletフィルタプログラムであり、Servlet やJSPの実行環境であるServletコンテナ１３上で動作する。本プログラムは、アプリケーションプログラムとは別物であり、アプリケーションプログラムの実行環境に配備して利用する。

そして、第１の性能データ収集プログラム（Servletフィルタ）１６は、詳しくは後述するように、任意のクライアント１００からの任意のリクエストが受信される毎に（更に、その応答毎に）、セッションID、リクエストID、スレッド名、日付時刻情報等を取得して、ログファイルに記録する。また、リクエスト受信時に、上記セッションID、リクエストIDを、所定の記憶領域に記憶して、この記憶領域を介することで、第２の性能データ収集プログラム（Javaクラス）１７に渡す。

第２の性能データ収集プログラム（Javaクラス）１７は、当該プログラム実行毎に、上記所定の記憶領域を参照する等して上記セッションID、リクエストIDを取得し、更にスレッド名、日付時刻情報、メソッド名（関数名）等を取得して、これらをログファイルに記録する。

第２の性能データ収集プログラム（Javaクラス）１７は、例えば後述する図５のように、実行中のアプリケーションプログラム（Ｊａｖａクラス１２）から任意のタイミングで呼び出されることで実行される。この呼び出しタイミングは、例えば任意のログ出力対象のメソッド（関数）の実行時（例えばその開始／終了時等）等となっている。これにより、例えば、実行された関数の日付時刻情報（関数の実行開始／終了時刻等）等に、この関数実行に係るクライアントやリクエストを示すセッションID、リクエストIDが対応付けられて、ログファイルに記録されることになる。

上記のように、アプリケーションプログラム（Ｊａｖａクラス１２）には任意のタイミングでの呼び出し処理が含まれているが、これは最初から存在するわけでなく、必要に応じて追加される。つまり、呼び出し処理を有するアプリケーションプログラム（Ｊａｖａクラス１２）は、必要に応じて、第２の性能データ収集プログラム（Javaクラス）１７と共に生成される。この生成処理は、従来のように手間が掛かるものではなく、以下に説明するように容易に生成できる。尚、後述するように、アプリケーションプログラム（Ｊａｖａクラス１２）内に第２の性能データ収集プログラム（Javaクラス）１７が含まれる形態であってもよい。

以下、上記アプリケーションプログラム（Ｊａｖａクラス１２）及び第２の性能データ収集プログラム（Javaクラス）１７の生成処理について説明する。
アプリケーションプログラム（Ｊａｖａクラス１２）及び第２の性能データ収集プログ
ラム（Javaクラス）１７は、アプリケーションプログラムのバイトコードと、当該アプリケーションプログラム内の任意のログ出力対象関数、当該関数内のログ出力箇所（例：関数開始点、関数終了点）、およびログ出力処理を記述したアスペクトプログラムのソースファイルとを、アスペクトコンパイラによりコンパイルすることで生成される。

尚、アスペクトプログラムとは、所謂“アスペクト指向プログラミング”（略してＡＯＰと呼ばれる）手法に係るプログラムである。ＡＯＰとは、端的に言えば、システムに渡って横断的に要求される機能を、一箇所に「アスペクト」としてまとめておくプログラミング手法のことである。よって、上記アスペクトプログラムは、複数の各アプリケーションプログラムに共通的な処理（例：ログ出力処理等）が記述されたものである。

以下、図２を参照して、上記第２の性能データ収集プログラム（Javaクラス：アスペクトプログラム）１７等の生成方法について説明する。
上記第２の性能データ収集プログラム（Javaクラス）１７（及びＪａｖａクラス１２）は、図２に示すアプリケーションプログラムのバイトコード（.classファイル）２２（以下、アプリケーションプログラム２２と記す）と、アスペクトプログラムのソースファイル（.ajファイル）２１（以下、アスペクトソースファイル２１と記す）とを、アスペクトコンパイラ２０によりコンパイルする（以下、アスペクトコンパイルという）ことで生成される。アスペクトソースファイル２１には、アプリケーションプログラム２２のログ出力対象関数、関数内のログ出力箇所（例：関数開始点、関数終了点）、およびログ出力処理が、プログラマ等によって記述されている。

そして、アスペクトコンパイラ２０によるコンパイルの結果として、図２に示す（３）アスペクトプログラム（.classファイル）２３と（４）アプリケーションプログラム（.classファイル）２４とが生成される。このアスペクトプログラム（.classファイル）２３が上記図１に示す第２の性能データ収集プログラム（Javaクラス）１７に相当し、アプリケーションプログラム（.classファイル）２４がＪａｖａクラス１２に相当する。

尚、アプリケーションプログラム２２はアスペクトコンパイル前のアプリケーションプログラム（Ｊａｖａクラス１２）であり、上記アスペクトコンパイルによって、アスペクトソースファイル２１に記述されている各ログ出力対象関数の各ログ出力箇所に、第２の性能データ収集プログラム（Javaクラス）１７の呼び出し処理が挿入されることになり、これが上記アプリケーションプログラム（.classファイル）２４である。

上記アスペクトコンパイラ２０によるコンパイル前後のソースファイル／プログラムに関して、以下にまとめて説明する。
（１）アスペクトソースファイル（.ajファイル）２１；
アプリケーションプログラム２２の各関数のうちの特定のログ出力対象関数、このログ出力対象関数に係るログ出力箇所（例：関数開始点、関数終了点）、およびログ出力処理を記述したソースファイル。Javaに似た言語にて記述する。

（２）アプリケーションプログラム（.classファイル）２２；
アプリケーションソースファイルをJavaコンパイラでコンパイルしたバイトコード。従来のJavaクラス８２（但し、処理時間収集処理無しのバージョン）に相当する。

（３）アスペクトプログラム（.classファイル）２３；
アスペクトソースファイル２１をアスペクトコンパイルした結果生成される、上記第２の性能データ収集プログラム（Javaクラス）１７である。アスペクトソースファイル２１内で定義された各ログ出力対象関数内の各ログ出力箇所でアプリケーションプログラム（.classファイル）２４が呼び出しを行うことで、ログ出力処理を行う。つまり、アスペク
トプログラム（.classファイル）２３自体は、基本的に、所定のログ出力処理を行うだけである。

（４）アプリケーションプログラム（.classファイル）２４；
アプリケーションプログラム２２に対しアスペクトコンパイルを行うことで、例えば図４（ｂ）に示すように各ログ出力箇所に上記アスペクトプログラム（.classファイル）２３の呼び出し処理が埋め込まれたプログラム。

上記のように生成したアスペクトプログラム（.classファイル）２３及びアプリケーションプログラム（.classファイル）２４を、例えば図３に示すようにアプリケーション実行環境に配備、置き換えすることで（上記の通り、これらプログラム２３，２４は、第２の性能データ収集プログラム（Javaクラス）１７、Ｊａｖａクラス１２に相当する）、アプリケーションプログラムの性能データの収集が可能になる。

尚、図１〜図３に示すものは、一例であり、この例に限るものではない。すなわち、公知のように、上記“アスペクト指向プログラミング”手法に係るコンパイラでは、アスペクトプログラムとアプリケーションプログラムとを統合することも可能である。

この場合、アスペクトコンパイル処理によって、例えば図４（ａ）に示すように、アプリケーションプログラム２２中にアスペクトプログラム２３が埋め込まれた形式の１つのプログラムが生成されることになる。アスペクトプログラム２３が埋め込まれる位置は、当然、アスペクトソースファイル（.ajファイル）２１で記述されている、上記各ログ出力対象関数に係る各ログ出力箇所（例えば関数の開始／終了時点）である。この場合も、埋め込まれるアスペクトプログラム２３自体は、上記ログ出力処理を実行するものである。

一方、本説明で用いる例では、上述した通り、２つのプログラムが１つに統合されることはなく、アスペクトプログラム（.classファイル）２３及びアプリケーションプログラム（.classファイル）２４が生成される。

そして、アプリケーションプログラム（.classファイル）２４には、図４（ｂ）に示すように、コンパイル前のアプリケーションプログラム（.classファイル）２２中に、アスペクトプログラム（.classファイル）２３を呼び出す処理が埋め込まれることになる。この呼び出し処理が埋め込まれる位置は、当然、アスペクトソースファイル（.ajファイル）２１で記述されている、上記ログ出力箇所である。そして、呼び出されたアスペクトプログラム（.classファイル）２３は、上記ログ出力処理を実行することになる。

尚、よく知られているように、一つの「クラス」は通常、１以上の「メソッド（関数）」を有しており、例えば全ての「クラス」を上記アプリケーションプログラム２２とし、アスペクトソースファイル（.ajファイル）２１で指定された関数を有する「クラス」には、当該関数の実行箇所に呼び出し処理が埋め込まれるようにしてもよいし、アスペクトソースファイル（.ajファイル）２１で指定された「クラス」のみを上記アプリケーションプログラム２２としてアスペクトコンパイラ２０に入力させるようにしてもよい。

図５は、本例のクライアントとサーバからなるシステム全体の動作を示す図である。
Ｗｅｂ／Ａｐサーバ１０は、任意のクライアント１００のブラウザ等から送られてくる任意のリクエストを受信すると、まず、第１の性能データ収集プログラム（Servletフィルタ）１６が、詳しくは後述する図６の処理によって得たセッションＩＤとリクエストＩＤを、主記憶装置３０内のスレッド固有の変数領域３１に格納する。尚、言うまでもないが、セッションＩＤは各セッションを識別する識別コードであり、リクエストＩＤは各リ
クエストに対し一意となるＩＤであり、スレッド固有の変数領域３１は各スレッド毎に割り当てられる変数領域である。

第１の性能データ収集プログラム（Servletフィルタ）１６は、更に、詳しくは後述する図６の処理によって、更に、日付時刻情報、スレッド名、処理の開始／終了情報、アクセスＵＲＬ等の各種情報を取得して、これら取得した情報を上記セッションＩＤ、リクエストＩＤと共に、例えば補助記憶装置４０（ハードディスク等）内のログファイル４１に書き込む。

上記第１の性能データ収集プログラム（Servletフィルタ）１６による処理に続いて、上記受信したリクエストに応じたＪａｖａアプリケーション（ＪＳＰ／Ｓｅｒｖｌｅｔ１１、Ｊａｖａクラス１２）が実行されることになる。（ＪＳＰ／Ｓｅｒｖｌｅｔ１１が実行され、当該スレッドから呼び出された関数が実行される。）
そして、任意のＪａｖａクラス１２が実行されるとき、このＪａｖａクラス１２が上記呼び出し処理が埋め込まれたものである場合には、この呼び出し処理が実行されることで呼び出されたアスペクトプログラム（.classファイル）２３（第２の性能データ収集プログラム（Javaクラス）１７）が実行されることになる。

この呼び出しタイミングは、ユーザ等が上記ソースプログラムで任意に指定しているものであり、例えば関数の実行開始時／終了時等であり、ここではこの例を用いて説明する。

呼び出された第２の性能データ収集プログラム（Javaクラス）１７は、詳しくは後述する図７の処理を実行することで、当該スレッド固有の変数領域３１に格納されている上記セッションＩＤ、リクエストＩＤや、日付時刻情報、スレッド名、処理の開始／終了情報、アクセスＵＲＬ等の各種情報を、例えば補助記憶装置４０（ハードディスク等）内のログファイル４１に書き込む。

尚、上記各種処理は、一旦、主記憶装置３０内に記憶しておき、リクエストによる一連の処理（リクエストに応じて呼び出される全関数の実行）が完了したタイミングで、主記憶装置３０から補助記憶装置４０上のログファイル４１に出力するようにしてもよい。

以下、図６、図７を参照して、上記第１、第２の性能データ収集プログラムによって実行される処理について説明する。
上記の通り、図６は第１の性能データ収集プログラム（Servletフィルタ）１６の処理フローチャート図であり、図７は第２の性能データ収集プログラム（Javaクラス）１７の処理フローチャート図である。

まず、図６に示す処理について説明する。
図６に示すように、第１の性能データ収集プログラム（Servletフィルタ）１６は、任意のクライアントから任意のリクエストを受信する毎に（ステップＳ１１）、まず、当該Ａｐサーバが自動的に割り当てるセッションＩＤと、当該リクエストの通過時に当該プログラム（Servletフィルタ）がプログラム内でカウント／生成するリクエストＩＤとを、上記スレッド固有の変数領域３１に格納する（ステップＳ１２）。また、Ｊａｖａ内部で付与されるスレッド名を取得する（ステップＳ１３）。更に、現在日時（あるいは上記リクエストを受信した時点）を示す日付時刻情報等を、Ｗｅｂ／Ａｐサーバ１０内の不図示のシステムクロックから取得する（ステップＳ１４）。

そして、上記各処理により取得した各種情報、すなわち現在の日付時刻情報、セッションＩＤ、リクエストＩＤ、スレッド名と、更に、処理の開始／終了情報、アクセスＵＲＬ
を、ログファイル４１に書き込む（ステップＳ１５）。

尚、処理の開始／終了情報は、単に、任意のリクエストに応じた処理の開始時点か終了時点かを示す情報であり、リクエスト受信時には当然“開始”となる。尚、リクエストに応じた一連の処理が終了してレスポンスを返す際にも、第１の性能データ収集プログラム（Servletフィルタ）１６は図６の処理を実行するものであり、その際には処理の開始／終了情報は当然“終了”となる。また、尚、アクセスＵＲＬは、リクエストされた（アクセス先の）ホームページ等のＵＲＬである。

次に、図７の処理について以下に説明する。
尚、図７に示す各ステップの処理のうち、第２の性能データ収集プログラム（Javaクラス）１７自体によって実行される処理は、ステップＳ２４〜Ｓ２７であると見做してもよい。すなわち、ステップＳ２１〜Ｓ２３の処理は、任意の第２の性能データ収集プログラム（Javaクラス）１７が呼び出されるまでの処理を意味すると見做してもよい。つまり、ＪＳＰ／Servlet１１が任意のＪａｖａクラス１２を呼出す毎に（ステップＳ２１）、このＪａｖａクラス１２にログ出力対象関数がない場合（ステップＳ２２，ＮＯ）、すなわち上記アスペクト・コンパイルにより呼び出し処理が全く埋め込まれていない場合には、当然、第２の性能データ収集プログラム（Javaクラス）１７が呼び出されることはなく、このＪａｖａクラス１２の処理が実行されるだけである。

一方、ログ出力対象関数がある場合には（ステップＳ２２，ＹＥＳ）、このログ出力対象関数の実行に伴って、上記ログ出力箇所（関数実行開始／終了時等）に埋め込まれている呼び出し処理が実行される毎に（ステップＳ２３，ＹＥＳ）、呼び出された第２の性能データ収集プログラム（Javaクラス）１７がステップＳ２４〜Ｓ２７の処理を実行することになる。

すなわち、まず、当該スレッドに対応する上記スレッド固有変数領域３１に記憶されている上記セッションＩＤ、リクエストＩＤを取得し（ステップＳ２４）、Ｊａｖａ内部で付与されるスレッド名を取得する（ステップＳ２５）。更に、現在日時（あるいは上記呼び出しを受けた時点等）の日付時刻情報等を、Ｗｅｂ／Ａｐサーバ１０内の不図示のシステムクロックから取得する（ステップＳ２６）。

そして、上記各処理で取得した各種情報、すなわち現在の日付時刻情報、セッションＩＤ、リクエストＩＤ、スレッド名と、更に、処理の開始／終了情報、アクセスＵＲＬ、（呼び出し元の）関数名を、当該関数の性能データとしてログファイル４１に書き込む（ステップＳ２７）。

尚、開始／終了情報や（呼び出し元の）関数名は、呼び出し処理の際にパラメータとして渡してもよいし、他の方法であってよい。
上述した処理により、任意のクライアント（セッション）からの任意のリクエストに応じた全てのログ出力対象関数に関する上記性能データには、同一のセッションＩＤ及びリクエストＩＤが格納されていることになり、後に、収集した性能データを分析する際に、例えば各リクエストによる同じ関数に係る処理時間を一覧表示して、他と比較して処理時間が非常に長いものがあった場合に、この関数の性能データに含まれるセッションＩＤ及びリクエストＩＤから、そのクライアントやリクエスト固有の問題があることが推定できる等、クライアントやリクエスト固有の問題があった場合に特定が容易となる
図８に、上記ログファイル４１の格納データ形式の一例を示す。

図示の例では、ログファイル４１のテーブル５０（以下、性能データ５０とも言うものとする）は、年月日時分秒．ミリ秒５１、ログレベル５２、セッションＩＤ５３、リクエ
ストＩＤ５４、スレッド名５５、開始／終了５６、ＵＲＬ５７、実行メソッド情報５８等の各データ項目より成る（尚、図示の「備考・参考情報」はここでは関係ない）。

年月日時分秒．ミリ秒５１には、上記現在の日付時刻情報が格納される。この例のように、日付時刻情報は、年月日時分秒に加えてミリ秒単位まであり、ここではミリ秒は３桁となっている。

ログレベル５２は常に“ＤＥＢＵＧ”とするが、ここでは関係ない。
セッションＩＤ５３、リクエストＩＤ５４、スレッド名５５、開始／終了５６、ＵＲＬ５７には、それぞれ上記セッションＩＤ、リクエストＩＤ、スレッド名、処理の開始／終了情報、アクセスＵＲＬが格納される。

実行メソッド情報５８には、上記呼び出し元の関数名（メソッド名）が格納される。よって、図６の処理の際には何も格納されない。
上述した本システムによれば、アプリケーションプログラムの各ソースコード毎に逐一、処理時間収集のための仕組みを組み込んだり、モジュールを入れ替える必要がなくなる。更に、複数のクライアント、リクエストから同じ関数が呼ばれた場合であっても、クライアント、リクエストに対応した関数の処理時間を収集することができる。

上述した実施例の動作を概略的に示す図面として図９、図１０を示すものとし、以下、図９、図１０について簡単に説明するものとする。
上記の通り、図９は上述した実施例のＷｅｂ／Ａｐサーバ１０の動作を概略的に示す図であり、図１０はそのフローチャート図である。

図９に示す動作は、既に説明してある通りであり、任意のクライアント１００のブラウザから任意のＨＴＴＰリクエストがあると、第１の性能データ収集プログラム（Servletフィルタ）１６が、セッション情報（セッションＩＤ、リクエストＩＤ）の記憶や、上記各種情報のログ出力を行う。そして、リクエストに応じたＪａｖａアプリケーションを実行させる。これにより、ＪＳＰ／Servlet１１は、各メソッド（Ｊａｖａクラス１２）を実行させ、Ｊａｖａクラス１２は上記呼び出し処理が挿入されているものである場合には、この呼び出し処理実行のタイミングで第２の性能データ収集プログラム（Javaクラス）１７を呼び出す。本例では、上記の通り、一例として、Ｊａｖａクラス１２（関数）の実行開始と終了時のタイミングで、呼び出し処理が実行されるものである。

これより、図示の通り、第２の性能データ収集プログラム（Javaクラス）１７は、Ｊａｖａクラス１２（関数）の実行開始と終了時のタイミングで、それぞれ、上記ログ出力処理を行うことになる。

そして、リクエストに応じたＪａｖａアプリケーション処理が全て終了したら、第１の性能データ収集プログラム（Servletフィルタ）１６は、レスポンス通過の際に、上記ログ出力を行う。更に、セッション情報を解除する。すなわち、上記スレッド固有変数領域３１に格納したセッション情報を消去する。

図１０は、図９に対応する概略的な処理フローチャート図である。よって、必ずしも実際の動作と一致するものではないが（実際の動作は図５、図６、図７等で既に説明してある）、以下、簡単に説明するものとする。

図１０において、任意のリクエストを受信すると（ステップＳ３１）、生成されるセッションＩＤ、リクエストＩＤを上記スレッド固有変数領域３１に格納し、当該リクエストに応じた関数（Ｊａｖａクラス１２）が実行される毎に（ステップＳ３３）、上記の例で
は関数処理開始時（ステップＳ３４，ＹＥＳ）及び終了時（ステップＳ３６，ＹＥＳ）にそれぞれ、上記各種情報（セッションＩＤ、リクエストＩＤ、日付時刻情報等）から成る性能データを取得して（ステップＳ３５，Ｓ３７）、ログファイル４１に書き込む（ステップＳ３９）。

図１１に、上記ログファイル４１に書き込まれたログデータの一例を示す。
図示の通り、ログファイル４１には、任意の同一のセッションＩＤ及びリクエストＩＤの組み合わせ毎に、この同一のセッションＩＤ及びリクエストＩＤによるＵＲＬ５７（ここでは省略して示す）へのアクセスに応じて実行された、すなわち任意のクライアント（ブラウザ）からの任意のリクエストに応じて実行された一連の関数処理等のログデータ（性能データ）が、書き込まれた順番通りに（ログ出力処理実行順に）格納されている。

また、同図の例では、実行メソッド情報５８として、α、βが格納されており、これはメソッド名（関数名）α、βの２つの関数が、セッションＩＤ＝‘1122’及びリクエストＩＤ＝‘３’によるＵＲＬ５７（ここでは省略して示す）へのアクセスに応じて実行されたことを意味する。

上記メソッド（関数）α、βの実行に関する４つのレコードが、実行メソッド情報５８及び開始／終了５６が「α；開始」→「β；開始」→「β；終了」→「α；終了」という順番に格納されているのは、メソッドα実行中にメソッドβが呼び出されたことを意味している。つまり、基本的に「開始」が複数連続するのは、任意の関数を呼び出していることを意味している。この様に、ログファイル４１には、各関数の開始、終了のタイミングでログ出力された順番にレコードが記録されているので、上記の通り他の関数等の呼び出し関係を解析することができる。

また、図示の一連のレコードの最初と最後のレコードには、実行メソッド情報５８（関数名）が記録されていないが、これは、上記第１の性能データ収集プログラム（Servletフィルタ）１６による上記ＨＴＴＰリクエスト受付時及び応答時のログ出力処理によって記録されたレコードであることを意味する。この第１の性能データ収集プログラム（Servletフィルタ）１６による上記ＨＴＴＰリクエストの受付及び応答に係る処理を「リクエスト受付・応答処理」と呼ぶものとする。従って、ログファイル４１には、任意の同一のセッションＩＤ及びリクエストＩＤの組み合わせ毎に、「リクエスト受付・応答処理」に係るレコードと、各関数実行（開始／終了）に係るレコードとが記録されることになる（例えば、ログ記録処理の際に、セッションＩＤ及びリクエストＩＤをキーにしてログファイル４１を検索して、該当するレコード群の最後に新たなレコードを追加すればよい）。

尚、図１１では、日付時刻情報（年月日時分秒．ミリ秒５１）は、年月日時は省略し、分秒．ミリ秒のみ示してある。また、上記の通りＵＲＬ５７の具体例は省略してある。
以下、上述したようにして収集した性能データを分析して表示する処理について説明する。

本例では、性能データを可視化表示（表、バー、グラフ等による表示）する為に、まず、上記ログファイル４１のデータを、表、グラフ等の表示の元となる内部データに変換する。この変換処理の一例を図１２に示す。また、内部データ構造の一例を図１３、図１４等に示す。尚、図１２の処理は、図１３の例に応じた処理例である。

図１３は、内部データ構造に係る概略的な階層構造を示す図である。
まず、図１３に示すように、各内部データを格納する不図示の内部データファイルは、例えば階層０、階層１、階層２、・・等の階層構造を有する。階層０は最上位階層である。

階層１は各クライアント（ブラウザ）毎に対応する階層である。つまり、これまでに当該Ｗｅｂサーバにアクセスした記録が無い（少なくとも内部データには無い）新たなクライアント（ブラウザ）毎からのアクセスがある毎に、新たな階層１のデータが作成される。

そして、各階層１毎に、この階層１のクライアント（ブラウザ）から任意のリクエストがある毎に、その階層１内に新たな階層２の内部データが作成される。
尚、ここでは階層１と階層２とに分けて考えているが、実際には上述した通り（そして図１４等に示す通り）任意の「セッションＩＤ及びリクエストＩＤ」の組み合わせを１単位とする性能データ収集・記録が行われるわけであるので、図示の階層１、階層２のデータに関しては特に説明しない。階層１と階層２とから成るデータは、上記「リクエスト受付・応答処理」に係る性能データに基づいて作成される内部データであると考えてよい。

そして、各階層２毎に、そのリクエストに応じた関数が実行される毎に記録されたログデータがある毎に、該関数に応じた新たな階層３の内部データが作成される。更に、この階層３の関数の実行中に呼び出された別の関数に関するログデータがある毎に、該別の関数に応じた新たな階層４の内部データが作成される。

上記図１３に示す階層構造に応じた上記内部データへの変換処理について、図１２を参照して説明する。
図１２の処理は、任意のログファイル４１を対象として、このログファイル４１に格納されている性能データを１行（１レコード）ずつ読み出して（ステップＳ４１）、読み出したレコードについてステップＳ４２以降の処理を実施する。

まず、読み出したレコードのセッションＩＤを用いて内部データファイル内を検索して、同一のセッションＩＤの階層１があるか否かをチェックし（ステップＳ４２）、無い場合には（ステップＳ４２，ＮＯ）、このセッションＩＤ（クライアント（ブラウザ））に応じた新たな階層１を内部データファイル内に作成し、これを階層０の最後（既に作成されている階層１群の最後の階層１の後）に追加する（ステップＳ４３）。

更に、読み出したレコードのリクエストＩＤに応じた階層２を新規作成して、これを階層１（ここでは新たに作成した階層１）の最後に追加する。更に、主記憶上に設けられる任意の記憶領域（又は変数）（以下、“開始状態”と呼ぶ）に、当該レコードのＵＲＬ５７を記憶する（ステップＳ４５）。尚、この例に限らず、“開始状態”として「関数無し」等と記録してもよい。

また、ステップＳ４２がＹＥＳでステップＳ４４がＮＯの場合も、ステップＳ４５の処理が行われる。ステップＳ４４は、上記同一セッションＩＤの階層１内に、読み出したレコードのリクエストＩＤと同一のリクエストＩＤの階層２があるか否かを判定する処理である。

ステップＳ４５の処理後は、ステップＳ５１の判定処理へ移行し、ログファイル４１内の全てのレコードの読み込みが完了しない限り、ステップＳ５１の判定はＮＯとなってステップＳ４１へ戻り、次のレコードの読み込みを行うことになる。

尚、階層２以下（階層２、階層３、階層４・・・等）の階層の新規作成に際しては、上記読み出したレコードの各データ（年月日時分秒．ミリ秒５１、セッションＩＤ５３、リクエストＩＤ５４、ＵＲＬ５７、実行メソッド情報５８）を、その階層情報（‘２’、‘３’、‘４’等）と共に、内部データファイルに新規追加レコードとして記憶する処理も
行われる。その際、年月日時分秒．ミリ秒５１は、後述する開始日時６４として記憶される。

上述したステップＳ４５の処理により任意のリクエストＩＤに応じた新規階層２が作成された後、次以降のレコードがログファイル４１から読み込まれると、上記図１１に示す例のように、これらレコードはこのリクエストに応じて実行される各関数に関する性能データである。よって、ステップＳ４２、Ｓ４４の判定はＹＥＳとなり、ステップＳ４６の処理が実行される。ステップＳ４６の処理では上記“開始状態”に任意の関数名（ここでは関数名αとする）が記憶されているか否かを判定する。上記ステップＳ４５の直後のレコードに関する処理では、上記の通り関数名ではなくＵＲＬが記憶されているので、ステップＳ４６の判定はＮＯとなり、ステップＳ４７の処理へ移行する。

ステップＳ４７の処理では、読み込んだレコード（任意の関数に関する性能データ）に関する階層３を新規作成し、階層２の最後に記憶する。そして、上記“開始状態”に当該レコードの関数名（実行メソッド情報５８）を関数名αとして記憶する。そして、ステップＳ５１の判定を経てステップＳ４１に戻る。

次に読み込むレコードに関しては、ステップＳ４２，Ｓ４４，Ｓ４６の判定がＹＥＳとなり、ステップＳ４８の処理に移行する。ステップＳ４８では、読み込んだレコードの開始／終了５６が“開始”、“終了”の何れであるかを判定する。もし、上記関数名αの関数（メソッド）が更に別の関数を呼び出すものではなかったなら、ステップＳ４８の判定は「終了」となるものであり、ステップＳ４９の処理へ移行する。

ステップＳ４９では、当該関数名αの関数に関する内部データおける後述する終了日時６５に、読み込んだレコードの年月日時分秒．ミリ秒５１を記憶する。更に、開始日時６４と終了日時６５との時間差を求め、これを経過時間６６に記憶する。これにより、当該関数名αに関する表示用等の内部データは、図１４に示す６１〜６９の各データ項目のうち、実行時間６７を除いて全て記録されることになる。尚、実行時間６７の算出・記録処理については後に説明する。

ステップＳ４９では、最後に、上記“開始状態”に現在の階層の親階層の関数名（関数名が無い場合にはＵＲＬ）を記憶する。
一方、上記関数名αの関数（メソッド）が更に別の関数を呼び出していたならば、当該読み込んだレコードは、例えば図１１の例における「α；開始」のレコードの次の「β；開始」のレコードのように、呼び出された関数の「開始」時のレコードであるので、ステップＳ４８の判定は「開始」となり、ステップＳ５０の処理に移る。

ステップＳ５０では、「関数αの階層＋１」の階層（ここでは階層４）を新規作成し、これを当該関数αの階層内の最後に追加する。そして、上記“開始状態”に当該読み込んだレコードの関数名（実行メソッド情報５８）を新たな関数名αとして記憶する（ステップＳ５０）。

その後、開始／終了５６が「終了」のレコードが読み込まれると、ステップＳ４８の判定は当然「終了」となり、ステップＳ４９の処理が実行されることになる。
尚、例えば図１１に示すように、同一のセッションＩＤ・リクエストＩＤを有するレコード群の最後には、上記「リクエスト受付・応答処理」の応答処理で記録されたレコードが格納されていることになるので、図１２には特に示していないが、当該最後のレコードを読み込んだ場合には（関数名が無いこと等で判定できる）、上記ステップＳ４５で作成されていた階層２の内部データを完成させる。すなわち、当該階層２の内部データの後述する終了日時６５に、読み込んだレコードの年月日時分秒．ミリ秒５１を記憶すると共に
、経過時間６６等を算出して記憶する。

図１４に示す表示用の内部データ６０は、階層６１、ＵＲＬ６２、関数名６３、開始日時６４、終了日時６５、経過時間６６、実行時間６７、セッションＩＤ６８、及びリクエストＩＤ６９の各データ項目より成る。

階層６１には、上記階層１，２，３等の階層を示す数値が格納される。階層は、上記の通り、関数等のネストの深さを示すものである。
ＵＲＬ６２、関数名６３には、それぞれ、上記ＵＲＬ５７、実行メソッド情報５８が格納される。同様に、セッションＩＤ６８、リクエストＩＤ６９には、それぞれ、セッションＩＤ５３、リクエストＩＤ５４が格納される。

開始／終了５６が「開始」のレコードの日付時刻情報（年月日時分秒．ミリ秒５１）が開始日時６４に格納され、開始／終了５６が「終了」のレコードの日付時刻情報（年月日時分秒．ミリ秒５１）が終了日時６５に格納される。

経過時間６６は、上記の通り、開始日時６４と終了日時６５との時間差（終了日時６５−開始日時６４）である。つまり、経過時間６６は、例えば、各関数の処理開始から終了までの時間を意味する。但し、各関数に限らず、例えば図１１に示す最初と最後のレコードから生成される内部データは、上記「リクエスト受付・応答処理」に係る内部データということになり、この場合の経過時間６６は、リクエスト受付から応答までの時間を意味することになる。

本例では、リクエストは任意のＵＲＬへのアクセスを例にしており、この例では上記「リクエスト受付・応答処理」に係る経過時間６６は、任意のＵＲＬ（ホームページ）アクセスに係る処理全体の最初から最後までの時間を意味することになる。また、上記「リクエスト受付・応答処理」には、単なる受付、応答の処理だけでなく、各関数の呼び出し処理も含まれる。

この様な「リクエスト受付・応答処理」のことを、以下「ＵＲＬ」と呼ぶものとする。
従って、上記「リクエスト受付・応答処理」に係る経過時間６６は、「ＵＲＬ」に係る経過時間６６と表現できる。また、これより、経過時間６６とは、「ＵＲＬ」／関数の処理開始から終了までの時間を意味するものと言える。また、上記の通り「ＵＲＬ」は関数を呼び出すものであり、例えば図１１に示す例では、「ＵＲＬ」は関数αを呼び出す。同様に図１７に示す例では「ＵＲＬ」は、関数getDB()、関数setDB()を呼び出すものと表現できる。

ここで、上記経過時間６６には、「ＵＲＬ」／関数から呼び出した他の関数の処理に係る時間（当該他の関数の経過時間）も含まれる。経過時間６６から当該他の関数の経過時間を除外したものが、実行時間６７となる。

上記表示用の内部データ６０について、以下、図１５〜図１７に示す具体例を参照して更に説明する。
図１５は任意のリクエストに係る表示用の内部データ６０の具体例であり、図１６は図１５に示す内部データ６０の元となった性能データ５０の一例を示す図である。図１７は、図１５に示す例に応じたリクエスト時の動作を示す図である。

図１５に示すように、この例では、ＵＲＬ＝“http//:localhost:8080/DBAccess.jsp”に対するアクセスがあり、セッションＩＤ＝‘1234’且つリクエストＩＤ＝‘１’が割り当てられたものとし、図１５はこの場合に収集された図１６の性能データ５０から生成さ
れた表示用の内部データ６０を示すものである。

尚、図１３に示す例やこの例に対応する図１２の処理では、上記の通り、セッションＩＤで１階層、リクエストＩＤで１階層という扱いにしていたが、これは１つの考え方を示すものであり、この例に限らない。本手法では、基本的に、任意のセッションＩＤとリクエストＩＤの組み合わせが示す各リクエスト毎に、性能データ５０の収集が行われるので、当該各リクエスト毎の性能データ５０の最初のレコード（すなわち上記「ＵＲＬ」によってログ出力されたレコード）に関する内部データ６０には、図１５に示すように階層１を与える。

尚、最初のレコードであるか否かは、例えば前回読み込んだ性能データ５０のレコードのセッションＩＤとリクエストＩＤとを一時的に記憶して、これと今回読み込んだレコードのセッションＩＤとリクエストＩＤと比較して不一致である場合に、最初のレコードであると判定する。勿論、この例に限らない。

すなわち、上記最初のレコードを含め、この最初のレコードと同一のセッションＩＤとリクエストＩＤを有する一連のレコードを順次読み込む毎に、そのレコードの開始／終了５６が「開始」か「終了」かによって、「開始」であれば階層を＋１し、「終了」であれば階層を−１する。ここでは、階層の初期値は‘０’とする。この例では、上記最初のレコードは当然「開始」であるので、「０＋１」で上記の通り階層１が与えられる。

その後、例えば、その後のレコードが、「開始」→「開始」→「終了」→「終了」→「開始」→「終了」→「終了」であったならば、階層は、上記１から２→３→２→１→２→１となる。この例は、例えば最初に関数α実行開始し（これには階層２が与えられる）、関数αから関数βが呼び出され（これには階層３が与えられる）、関数βが終了し、更に関数αが終了した後に、関数γが実行される（これには階層２が与えられる）場合等である。

これは、図１５、図１７に示す例でいうと、まず、上記最初のレコードは当然「開始」であり、上記の通り階層１となり、２番目以降のレコードは、図１７に示すように、関数名getDB()に係る「開始」→「終了」、更に関数名setDB()に係る「開始」→「終了」となり、最後に上記階層１に関する「終了」となる。よって、図１５、図１７に示すように、これら関数名getDB()とsetDB()に係る表示用の内部データ６０の階層６１は、共に‘２’となる。

この様に、性能データ５０においては「開始」、「終了」毎に別々のレコードであったものを、表示用の内部データ６０では「ＵＲＬ」や各関数毎に１つにまとめて、開始日時、終了日時が記録され、更に階層や経過時間等が求められて記憶されている。尚、図１４には示さないが、内部データ６０に更に呼び出し元（上位階層）の関数の関数名も記憶するようにしてもよい。

ここで、特に図示しないが、図１４に示すデータ構造の内部データ作成処理について、以下、図１５、図１６に示す例も参照しながら説明する。尚、図１６では、日付時刻情報（年月日時分秒．ミリ秒５１）は、年月日時は省略し、分秒．ミリ秒のみ示してある。

この処理では、例えば上記ログファイル４１（性能データ５０）からレコードを１行読み込む毎に、まず、内部データ６０の中に読み出したレコードのセッションＩＤ５３及びリクエストＩＤ５４と同一のセッションＩＤ６８及びリクエストＩＤ６９を有するデータが存在するか否かをチェックする。あるいは、このチェック処理は、前回読み込んだレコードのセッションＩＤ及びリクエストＩＤを一時的に保持しておき、これと一致するか否
かにより判定してもよい。

もし、同一のセッションＩＤ６８及びリクエストＩＤ６９を有するデータが存在しないならば（上記チェック結果がＮＯであるものとする）、このレコードは上記「ＵＲＬ」（特に第１の性能データ収集プログラム（Servletフィルタ）１６）によってリクエスト受付時にログ出力されたレコード（同一のセッションＩＤ６８及びリクエストＩＤ６９を有するレコード群の最初のレコード）ということになる。

もし、読み込んだレコードが上記最初のレコード（例えば図１６に示すレコードａに相当）である場合には、まず、任意の変数（ここでは“階層変数”という）に初期値‘１’をセットする。

続いて、内部データ６０に新たなレコードを追加し、このレコードの階層６１に階層変数の値（ここでは上記の通り‘１’）を記憶する。更に、この内部データ６０の新たなレコードの各データ項目に、上記ログファイル４１から読み出したレコードにおける該当するデータ項目のデータをコピーする。すなわち、ＵＲＬ５７、実行メソッド情報５８、セッションＩＤ５３、及びリクエストＩＤ５４の各データを、それぞれ、ＵＲＬ６２、関数名６３、セッションＩＤ６８、リクエストＩＤ６９にコピー・記憶する。更に、この場合は、開始／終了５６は「開始」となっているので、その日付時刻情報（年月日時分秒．ミリ秒５１）を開始日時６４にコピー・記憶する。尚、この場合、実行メソッド情報５８は空白なので、図１５の階層１のデータに示すように、関数名６３は空白となる。

この状態では、例えば図１５に示す例では階層１の内部データのみが作成され且つこの内部データは未完成となっている。つまり、終了日時６５、経過時間６６、及び実行時間６７は未だ記録されていない。

そして、次のレコードを読み込む。
上記最初のレコードの次以降の各レコードは、上記一連の処理の終了時のレコードまでは全て同一のセッションＩＤ６８及びリクエストＩＤ６９を有することになるので、上記チェック結果はＹＥＳの判定となり、その場合には以下の処理が実行される。

すなわち、まず、読み込んだレコードの開始／終了５６を参照して、これが「開始」であるか「終了」であるかによって処理が分かれる。
まず、「開始」である場合には、まず、上記“階層変数”を＋１インクリメントする。そして、上記最初のレコードの場合と同様にして、内部データ６０に新たなレコードを追加し、このレコードの階層６１に現在の“階層変数”の値を記憶すると共に、この内部データ６０の新たなレコードの各データ項目に、読み出したレコードにおける該当するデータ項目のデータをコピーする。上記の通り、終了日時６５、経過時間６６、及び実行時間６７以外の各データ項目のデータがコピー・記録される。

図１６の例では、レコードａの次にレコードｂが読み込まれ、階層変数は‘２’となり、図１５に示すようにこの関数名getDB()に関する各データ（終了日時６５、経過時間６６、及び実行時間６７は除く）が記録されることになる。

一方、読み込んだレコードの開始／終了５６が「終了」である場合には、この「終了」レコードと対になる「開始」レコードによって既に内部データ６０に新たなレコードが追加されているので（但し、上記の通り、未完成）、この対となる「開始」レコードを探して、このレコードを完成させる。

すなわち、例えばその階層６１の値が現在の“階層変数”の値と同一であり且つ関数名
が同じであるレコードを検索して求める。そして、求めたレコードの終了時間６５に読み込んだレコードの日付時刻情報（年月日時分秒．ミリ秒５１）を記憶し、経過時間６６を算出・記憶する。更に、可能であれば、実行時間６７も算出・記憶する。実行時間６７の算出方法は後に説明する。

この様にして、「終了」のレコードを読み込む毎に、内部データ６０における未完成のレコードが完成する。図１６の例では、レコードｃが読み込まれることで、図１５に示す関数getDB()に関する内部データが完成する。

読み込んだレコードの開始／終了５６が「終了」である場合には、上記処理の後、最後に、“階層変数”を−１デクリメントする。そして、次のレコードを読み込むことになる。レコードｃに関する処理では、最後に、階層変数＝‘１’にしていることになる。

図１６に示す例では、その後に更にレコードｄ、ｅが読み込まれ、図１５に示すように、関数setDB()に関する内部データの新規レコード（階層＝‘２’）が作成され、完成することになる。

そして、最後にレコードｆが読み込まれ、上記階層１のレコードが完成することになる。
ここで、上記実行時間６７の算出処理について説明する。

図１７に示す例では、例えば階層１のレコードの経過時間６６には、この階層１（上記「ＵＲＬ」）から呼び出される２つの関数（getDB()とsetDB()）の経過時間６６も含まれており、経過時間６６からは階層１（「ＵＲＬ」）自体の処理に掛かった時間は分からない。これは各関数においても同様であり、図１７では２つの関数（getDB()とsetDB()）は他の関数を呼び出すものではないが、例えば図１８（ａ）に示す例では、「ＵＲＬ」から呼び出された関数Ａは関数Ｂを呼び出し、更にその後に「ＵＲＬ」から呼び出された関数Ｂは関数Ｃを呼び出している。

図１８（ａ）に図上太い縦線で示すものが、「ＵＲＬ」や各関数Ａ，Ｂ，Ｃの経過時間６６を示すものである。図示の通り、例えば関数Ａの経過時間には当該関数Ａから呼び出した関数Ｂの経過時間も含まれており、関数Ａ自体の処理実行に要した時間は、経過時間からは分からない。よって、この例の場合、関数Ａの経過時間から関数Ｂの経過時間を差し引いた時間を求めて、これを上記実行時間６７とする。もし、他の関数を呼び出していない場合には、経過時間６６＝実行時間６７となる。

このようにして実行時間６７を求めると、図１８（ａ）の場合、「ＵＲＬ」及び各関数の実行時間６７は、図１８（ｂ）に図上太い縦線で示すものとなる。例えば、関数Ａの実行時間６７は、図示の「ａ１＋ａ２」となる。この関数Ａから呼び出された関数Ｂの実行時間６７は、その経過時間６６と同じとなる。また、その後に「ＵＲＬ」から呼び出された関数Ｂの実行時間は、図示の「ｂ１＋ｂ２」となる。

また、図１７に示す例では、階層１（「ＵＲＬ」）の実行時間６７は、図示の経過時間から、getDB()の経過時間とsetDB()の経過時間を差し引いた値となる。つまり、「ＵＲＬ」であっても関数であっても、それが直接呼び出した各関数の経過時間の総和を、自己の経過時間から差し引いた値が、その「ＵＲＬ」又は関数の実行時間として求められる。

ここで、直接呼び出した関数は、上記のように図１４には示さないがテーブル６０に呼び出し元の関数の関数名も記憶するようにした場合には、これを参照すれば分かる。そうでない場合でも、階層と、開始日時６４から終了日時６５までの時間帯（以下、経過時間
帯と呼ぶ）を比較すれば、呼び出し関係が分かる。

すなわち、任意の対象レコードの実行時間６７を求める場合には、この対象レコードの階層の１つ下の階層（対象レコードの階層＋１；例えば対象レコードの階層が‘２’であれば‘３’）の全てのレコードを抽出して、対象レコードの経過時間帯に、抽出した各レコードの経過時間帯が含まれるか否かを判定し、含まれるものは該当レコードとする。そして、全ての該当レコードの経過時間６６の総和を、対象レコードの経過時間６６から差し引くことで、対象レコードの実行時間６７が求められる。

例えば図１５に示す例において、図示の階層１（「ＵＲＬ」）のレコードを対象レコードした場合、この対象レコードの経過時間帯は、年月日時を省略すると、「40:00.848〜40:30.848」となる。また、この対象レコードの階層は‘１’であるので、階層が‘２’であるレコードを抽出すると、図示の関数名getDB()とsetDB()の２つのレコードが抽出される。

そして、各抽出レコードの経過時間帯は、図示の通り、「40:10.848〜40:15.848」と「40:20.848〜40:25.848」であり、何れも上記対象レコードの経過時間帯「40:00.848〜40:30.848」に含まれるので、両方とも上記該当レコードとなる。

そして、対象レコードの経過時間は30000（ミリ秒）であり、上記各該当レコードの経過時間はそれぞれ、5000（ミリ秒）と5000（ミリ秒）であるので、
対象レコードの実行時間６７＝30000−（5000＋5000）＝20000（ミリ秒）
となる。

尚、既に説明してあるが、上記図１５、図１７の説明における「ＵＲＬ」や図１８（ａ）、（ｂ）に示す「ＵＲＬ」とは、主に第１の性能データ収集プログラム（Servletフィルタ）１６とＪＳＰ／Servlet１１によって実行される処理を意味する。換言すれば、任意のＵＲＬへのアクセスに係る処理のうち、各関数によって実行される処理以外の処理を意味する。例えば図１７に示すＵＲＬの処理（階層１の処理）の経過時間は、ＵＲＬ＝“http//:localhost:8080/DBAccess.jsp”に対するアクセスのリクエスト受信から応答までの時間を意味する。

更に、上述したアプリケーションプログラムの性能データ収集の際に、ＯＳ／ミドルウェアの性能データ（リソース状況を示す各種データ）も収集しておく。ＯＳ／ミドルウェアのリソース状況を示す各種データの収集は、例えば従来で説明したように、例えばWindows（登録商標）のパフォーマンスモニタ等の既存の機能により実現できる。

そして、上述した処理によって生成された上記表示用の内部データ６０と、ＯＳ／ミドルウェアのリソース状況を、同一時間軸上にプロットして表示することで、例えば図１９（ａ）のような表示が行われる。表示用の内部データ６０に関しては、図示の例では、セッション・リクエスト毎の処理に掛かった時間（処理時間）を示すバーが表示される（例えば上記階層１（「ＵＲＬ」）の経過時間６６に基づき表示する）。尚、図上では、セッション毎としているが、実際には、任意のセッションＩＤとリクエストＩＤとの組み合わせ毎に表示する。

この表示処理や上述した内部データ生成処理を行うコンピュータ装置は、Ｗｅｂ／Ａｐサーバ１０であってもよいし、他の任意の情報処理装置であってもよい。何れにしても、上述した各関数等の性能データ収集、ＯＳ／ミドルウェアのリソース状況を示す各種データの収集、表示用の内部データの生成、この内部データに基づく表示を行う装置／システム全体を、性能データ収集・表示システムと呼ぶものとする。

あるいは、既に、上述した各関数等の性能データ収集、及びＯＳ／ミドルウェアのリソース状況を示す各種データの収集が行われて記憶されていることを前提として、これら収集・記憶されているデータに基づいて、表示用の内部データの生成、この内部データに基づく表示を行う装置のことを、性能データ表示装置と呼ぶものとする。

また、図１９（ａ）のような表示を行うだけであれば、上記の通り階層１の経過時間６６のデータのみで表示可能であるが、実際には、例えば図示のセッション１の表示として、例えば図１５に示すセッションＩＤ＝‘1234’、リクエストＩＤ＝‘１’の内部データを全て取得して表示する。

よって、図１９（ａ）には示されないが、例えば図１９（ｂ）の拡大表示が示すように、上記セッション・リクエスト毎の処理時間を示すバーは、各ＵＲＬ／関数毎の実行時間を示す処理時間バーが結合されたものとして生成されている（例えば各関数毎に色を変える等、区別がつくように表示する）。つまり、例えば、図１８（ｂ）に示すものが図１９（ｂ）に示すように１本のバー形状で示されているものであり、表示の形態は変わっていても内容的には図１８（ｂ）と示すものと略同様である。尚、図１９（ｂ）には示していないが、バー内に各関数の関数名等を表示するようにしてもよい。

図１９（ａ）、（ｂ）に示すように、更に、上記ＯＳ／ミドルウェアのリソース状況を示す各種データに基づくグラフ等も、上記バーの表示に重ねて表示される。
図１９（ａ）に示す表示画面では、ＯＳ／ミドルウェアのリソース状況の一例として、ディスクＩ／Ｏ（ディスクへの負荷量）が表示される（図では折れ線グラフのような表示となっている）。これをオペレータ等が視認することで、例えば、ディスクへの負荷量が増大している時間帯が分かり、更にこの時間帯に実行されたセッションが分かるので（図では主にセッション３が該当）、例えば図示のような矩形選択を行う（この例に限らず例えば該当セッションを直接指定する等）ことで、該当セッションの性能データが図１９（ｂ）に示すように拡大表示されることになる。

上記の通り、図１９（ｂ）に示す拡大表示では、セッション３に係り実行された各関数の実行時間が表示されるので、オペレータ等はこの表示を参照したり、あるいは更に他の正常と思われる（処理時間が短い、あるいはディスクへの負荷量が小さい）セッションを比較の為に拡大表示する等して、性能が悪い関数（（他と比較して）実行時間が長い関数；ディスク負荷量増加に影響を及ぼしている関数等）を容易に把握することができるようになる。

尚、図１９（ａ）に示す表示は、例えばオペレータ等が任意の時間帯（図の横軸の時間全体に相当）を指定することで表示されるが、この例に限らない。例えば、オペレータが任意のＵＲＬを指定することで、上記性能データ６０のうちそのＵＲＬ６２が指定されたＵＲＬと同一である全てのデータが抽出された表示されるものであってもよい。この場合には、例えば、同一のＵＲＬへのアクセスであるにも係らず、他のセッションよりも極端に処理時間が長いセッションを特定することができる等、クライアント（ブラウザ）固有の問題があった場合に特定が容易となる。

上記の例に限らず、例えば特定の関数名を指定して該当するデータを抽出させてその実行時間を表示させる等（この場合には、各データ毎にそのセッションＩＤ等も一緒に表示させる）、様々な検索条件を入力可能としてこの検索条件に応じた表示を行わせることができる。

図２０（ａ）、（ｂ）に他の表示例を示す。これら表示例は基本的には図１９（ａ）、
図２０と略同様の表示であり、図２０（ａ）は任意に指定された時間帯のアプリケーション性能データやＯＳ／ミドルウェアのリソース状況の表示画面であり、図２０（ｂ）は図２０（ａ）の画面上でオペレータ等により任意に指定された部分（図上点線で示す矩形領域）の拡大表示画面である。

図２０（ａ）が図１９（ａ）と異なる点は、まず、ＯＳ／ミドルウェアのリソース状況として、ディスクへの負荷量とＣＰＵ使用率の２種類が表示されている（図ではそれぞれ折れ線グラフのような表示となっている）点である。この様に、複数種類のリソース状況を表示させることもでき、アプリケーション性能データとリソース状況の対応関係が更に正確に行えるようになる。尚、上記表示は、例えば、ＯＳ／ミドルウェアのリソース状況を示す各種データのなかから、オペレータ等が任意の１又は複数の種類を指定して表示させることができる。

更に、図２０（ａ）では図１９（ａ）に比べて短時間に多数のセッション・リクエスト毎の処理が実行された為、各セッション毎のバーの表示が密集して表示される為、図２０（ａ）に示すように画面上では各セッション毎のバーが区別できない表示となっている。すなわち、画面上の時間ｔの位置（縦の点線で示す位置）をほぼ中心とする、画面の左上から右下に至る帯状の線が、各セッション毎のバーの表示が密集して成る表示となっている。この様に、あたかも１つの線のように密集して表示される場合もある。尚、バーの表示も折れ線グラフの表示も、グラフ表示の一種と見做してよいものとする。

この様な表示であっても、ＯＳ／ミドルウェアのリソース状況の表示を参考にして、問題がありそうな特定の時間帯を上記矩形として指定することで、図２０（ｂ）に示すように拡大表示されるので、オペレータ等は、各セッション毎の処理時間や、各セッションに係る各関数の処理時間が分かり、問題があるセッションや関数を容易に把握することができる。尚、図２０（ｂ）は図１９（ｂ）とは異なり、複数のセッションについて表示されるが、この中から更に特定のセッションをオペレータ等が選択して拡大表示させることも当然可能である。

尚、上記特定領域（特定時間帯）の選択・指定方法は、上記矩形による方法に限らず、既知の様々な方法であってよい。例えば、マウスのホイール操作との連動、数値指定等であってよい。また、尚、ＯＳ／ミドルウェアのリソース状況は、アプリケーションプログラムが実行されるＷｅｂサーバに限らず、当該Ｗｅｂサーバと接続し、同一システム上にあるサーバ（データベースサーバ等）のものであっても構わない。

また、上記アプリケーションプログラムの性能データ収集・解析結果（上記表示用の内部データ６０等）に基づいて、更に、平均・最速・最遅処理時間、メソッド呼び出し回数等を計算することも可能であり、計算結果は例えば市販の表計算ソフトを用いて表形式で出力することもできる。

図２１に、上記Ｗｅｂ／Ａｐサーバ１０等のコンピュータのハードウェア構成図を示す。尚、当該コンピュータは、Ｗｅｂ／Ａｐサーバ１０に限らず、上記性能データ収集・表示システムを構成する他の情報処理装置であってもよい。

図２１に示すコンピュータ７０は、ＣＰＵ７１、メモリ７２、入力部７３、出力部７４、記憶部７５、記録媒体駆動部７６、及びネットワーク接続部７７を有し、これらがバス７８に接続された構成となっている。

ＣＰＵ７１は、当該コンピュータ７０全体を制御する中央処理装置である。また、ＣＰＵ７１には、例えば、上記主記憶装置３０が内臓されていてもよい。
メモリ７２は、プログラム実行、データ更新等の際に、記憶部７５（あるいは可搬型記録媒体７９）に記憶されているプログラムあるいはデータを一時的に格納するＲＡＭ等のメモリである。ＣＰＵ７１は、メモリ７２に読み出したプログラム／データを用いて、各種処理を実行する。

出力部７４は、例えばディスプレイ等であり、上記図１９、図２０等に示す内部データ等の表示画面等が表示される。
入力部７３は、例えば、キーボード、マウス等であり、ユーザはこれらを操作して、上記図１９、図２０等に示す画面上で所望の入力操作（上記矩形領域の指定等）を行う。

ネットワーク接続部７７は、例えば不図示のネットワークに接続して、他の情報処理装置（クライアント１００等）との通信（コマンド／データ送受信等）を行う為の構成である。

記憶部７５は、例えばハードディスク等であり、例えば第１、第２の性能データ収集プログラム１６，１７や、アプリケーションプログラム（ＪＳＰ／Ｓｅｒｖｌｅｔ１１、Ｊａｖａクラス１２等）が格納されている。その他、ＯＳ１５やＪａｖａＶＭ１４を実現するプログラム等、本例のＷｅｂ／Ａｐサーバ１０の各種機能・処理（特に図６、図７、図１０、図１２に示す処理）を実現させる為に必要となる各種プログラムが格納されている。

ＣＰＵ７１は、上記記憶部７５に格納されている各種プログラムを読み出し・実行することにより、上述した性能データ収集・表示システムとしての各種機能・処理を実現する。

また、記憶部７５は、上記補助記憶装置４０に相当するものであってもよく、この場合にはログファイル４１も記憶されることになる。また、記憶部７５には表示用の内部データ６０も記憶されてもよい。すなわち、記憶部７５には、図８、図１１、図１３、図１４図１５、図１６等に示すデータ等が格納されるものであってもよい。

あるいは、上記記憶部７５に格納される各種プログラム／データは、可搬型記録媒体７９に記憶されているものであってもよい。この場合、可搬型記録媒体７９に記憶されているプログラム／データは、記録媒体駆動部７６によって読み出される。可搬型記録媒体７９とは、例えば、ＦＤ（フレキシブル・ディスク）７９ａ、ＣＤ−ＲＯＭ７９ｂ、その他、ＤＶＤ、光磁気ディスク等である。

あるいは、また、上記プログラム／データは、ネットワーク接続部７７により接続しているネットワークを介して、他の装置内に記憶されているものをダウンロードするものであってもよい。あるいは、更に、インターネットを介して、外部の他の装置内に記憶されているものをダウンロードするものであってもよい。

また、本発明は、上記本発明の各種処理をコンピュータ上で実現するプログラムを記録した可搬型記憶媒体として構成できるだけでなく、当該プログラム自体として構成することもできる。

以上説明したように、本手法では、アプリケーションプログラムのセッション・リクエスト毎の関数レベルでの処理時間や処理実行日時を自動的に集計して、この集計結果をＯＳ／ミドルウェアのリソース状況と同一グラフ上で重ね合わせて表示することが可能であり、アプリケーションプログラムのセッション・リクエスト毎の処理時間や更に関数毎の処理時間と、ＯＳ／ミドルウェアのリソース状況との関連を把握することが可能となる。
これより、上記の通り、ＯＳ／ミドルウェアの処理性能悪化に影響を及ぼしている関数を特定できるだけでなく、この関数実行に係るセッション・リクエストが把握でき、クライアントやリクエスト固有の問題があった場合に特定が容易となる。すなわち、効率的且つ的確な性能ボトルネック分析が可能となる。

また、アプリケーションプログラムのセッション・リクエスト毎の、更に各関数レベルでの、性能データ収集の為の処理は、上記の通りアスペクト・コンパイルによって容易に追加可能であり、ユーザ等の手間が掛からないものとなる。

尚、本手法は、例えば以下のシステム・状況において特に有用に適用可能である。
（ア）新規開発する業務システム利用者の要求性能達成度の確認及び性能改善の為に実施する性能テストにおける、性能データ収集後のデータ集計および表示。

（イ）機能追加、利用者増などにより、運用開始後、アプリケーションプログラムの性能確認・改善を実施する場合の、性能データ収集後のデータ集計および表示。
（ウ）その他、アプリケーションプログラムの性能データ集計および表示が必要なシステム全般。

本例のクライアントとサーバからなるシステムのシステム構成図である。 第２の性能データ収集プログラム等の生成処理を説明する為の図である。 図２と図１を対応付けて示す図である。 （ａ）、（ｂ）はアスペクト・コンパイル結果のアプリケーション（Javaクラス）の一例である。 本例のシステム全体の動作を示す図である。 第１の性能データ収集プログラムの処理フローチャート図である。 第２の性能データ収集プログラムの処理フローチャート図である。 ログファイルの格納データ形式の一例を示す図である。 本実施例のＷｅｂ／Ａｐサーバの動作を概略的に示す図である。 図９に対応する概略的なフローチャート図である。 ログファイルに書き込まれたログデータの一例を示す図である。 図１３の例に応じた変換処理の一例を示すフローチャート図である。 内部データ構造の一例を図（その１）である。 内部データ構造の一例を図（その２）である。 図１４に示すデータ構造における内部データの具体例である。 図１５に示す内部データの元となった性能データの一例を示す図である。 図１５に示す例に応じたリクエスト時の動作を示す図である。 （ａ）はＵＲＬ／各関数の経過時間、（ｂ）はその実行時間を示す図である。 （ａ）は内部データ等に基づく表示画面例（その１）、（ｂ）は（ａ）に示す画面の一部分の拡大画面例である。 （ａ）は内部データ等に基づく表示画面例（その２）、（ｂ）は（ａ）に示す画面の一部分の拡大画面例である。 コンピュータ・ハードウェア構成図である。 従来のシステム構成及び性能データ収集方式を示す図である。 （ａ）、（ｂ）は従来の性能データ等の表示例である。

符号の説明

１０ Ｗｅｂ／Ａｐサーバ
１１ ＪＳＰ／Ｓｅｒｖｌｅｔ
１２ Ｊａｖａクラス
１３ Ｓｅｒｖｌｅｔコンテナ
１４ ＪａｖａＶＭ（Ｊａｖａ仮想マシン）
１５ ＯＳ
１６ 第１の性能データ収集プログラム
１７ 第２の性能データ収集プログラム
２０ アスペクトコンパイラ
２１ アスペクトソースファイル
２２ アプリケーションプログラム
２３ アスペクトプログラム（.classファイル）
２４ アプリケーションプログラム（.classファイル）
３０ 主記憶装置
３１ スレッド固有の変数領域
４０ 補助記憶装置
４１ ログファイル
５０ ログファイルのテーブル（性能データ）
５１ 年月日時分秒．ミリ秒
５２ ログレベル
５３ セッションＩＤ
５４ リクエストＩＤ
５５ スレッド名
５６ 開始／終了
５７ ＵＲＬ
５８ 実行メソッド情報
６０ 表示用の内部データ
６１ 階層
６２ ＵＲＬ
６３ 関数名
６４ 開始日時
６５ 終了日時
６６ 経過時間
６７ 実行時間
６８ セッションＩＤ
６９ リクエストＩＤ
７０ コンピュータ
７１ ＣＰＵ
７２ メモリ
７３ 入力部
７４ 出力部
７５ 記憶部
７６ 記録媒体駆動部
７７ ネットワーク接続部
７８ バス
７９ 可搬型記録媒体
７９ａ ＦＤ（フレキシブル・ディスク）
７９ｂ ＣＤ−ＲＯＭ
１００ クライアント
１０１ クライアントプログラム（ブラウザ等）
１０２ ＯＳ

Claims (6)

1. 任意のクライアントから任意のリクエストを受け付ける毎に、このリクエストに応じたセッションＩＤ、リクエストＩＤを所定の記憶領域に記憶すると共に、該セッションＩＤとリクエストＩＤとに対応付けて所定のログ情報を記録する第１の性能データ収集手段と、
   前記リクエストに応じて所定の１以上の関数の処理を実行するアプリケーション実行手段と、
   前記アプリケーション実行手段による前記各関数の処理実行時に、前記所定の記憶領域から前記セッションＩＤ、リクエストＩＤを取得して、該セッションＩＤとリクエストＩＤとに対応付けて前記各関数の処理実行に係る所定の性能データを前記ログ情報に追加記録する第２の性能データ収集手段と、
   ＯＳ／ミドルウェアのリソース状況を示すデータを収集するリソース状況データ収集手段と、
   前記記録されたログ情報に基づいて、任意の前記各リクエストに応じた処理全体の開始日時、終了日時、処理時間を求め、又は前記各関数毎にその関数の処理の開始日時、終了日時、該関数の処理実行に掛かった時間である実行時間を求めて、該求めた情報を前記セッションＩＤ及びリクエストＩＤに対応付けて成る内部データを生成・記憶する内部データ生成・記憶手段と、
   前記内部データに基づいて、任意の前記各リクエスト毎の処理全体の処理時間又は該処理全体中の各関数の前記実行時間を示す可視化表示を行うと共に、これと同一時間軸上に前記リソース状況データに基づく可視化表示を重ね合わせて表示する表示手段と、
   を有することを特徴とする性能データ収集・表示システム。
2. 前記第２の性能データ収集手段と前記アプリケーション実行手段を実現させるプログラムは、所定のログ出力処理と任意の各ログ出力対象／ログ出力箇所とが記述されたアスペクトソースファイルと、前記関数の処理に係るアプリケーションプログラムとをアスペクト・コンパイルすることで生成されることを特徴とする請求項１記載の性能データ収集・表示システム。
3. 前記各関数の処理実行に係る所定の性能データは、該各関数の関数名、処理開始／終了日時、接続先ＵＲＬであることを特徴とする請求項１又は２記載の性能データ収集・表示システム。
4. 任意のクライアントからの任意のリクエストを受付ける毎に生成されるセッションＩＤとリクエストＩＤとに対応付けて、該リクエストに応じた処理全体に係る性能データ、又は該処理全体中の各関数の処理実行に係る性能データが、ログ情報として記憶された性能データ記憶手段と、
   少なくとも前記リクエストに応じた処理の実行時のＯＳ／ミドルウェアのリソース状況を示す各種データが記憶されたリソース状況データ記憶手段と、
   前記記録されたログ情報に基づいて、任意の前記各リクエストに応じた処理全体の開始日時、終了日時、処理時間を求め、又は前記各関数毎にその関数の処理の開始日時、終了日時、該関数の処理実行に掛かった時間である実行時間を求めて、該求めた情報を前記セッションＩＤ及びリクエストＩＤに対応付けて成る内部データを生成・記憶する内部データ生成・記憶手段と、
   前記内部データに基づいて、任意の前記各リクエスト毎の処理全体の処理時間又は該処理全体中の各関数の前記実行時間を示す可視化表示を行うと共に、これと同一時間軸上に前記リソース状況データに基づく可視化表示を重ね合わせて表示する表示手段と、
   を有することを特徴とする性能データ表示装置。
5. コンピュータを、
   任意のクライアントから任意のリクエストを受け付ける毎に、このリクエストに応じたセッションＩＤ、リクエストＩＤを所定の記憶領域に記憶すると共に、該セッションＩＤとリクエストＩＤとに対応付けて所定のログ情報を記録する第１の性能データ収集手段と、
   前記リクエストに応じて所定の１以上の関数の処理を実行するアプリケーション実行手段と、
   前記アプリケーション実行手段による前記各関数の処理実行時に、前記所定の記憶領域から前記セッションＩＤ、リクエストＩＤを取得して、該セッションＩＤとリクエストＩＤとに対応付けて前記各関数の処理実行に係る所定の性能データを前記ログ情報に追加記録する第２の性能データ収集手段と、
   ＯＳ／ミドルウェアのリソース状況を示すデータを収集するリソース状況データ収集手段と、
   前記記録されたログ情報に基づいて、任意の前記各リクエストに応じた処理全体の開始日時、終了日時、処理時間を求め、又は前記各関数毎にその関数の処理の開始日時、終了日時、該関数の処理実行に掛かった時間である実行時間を求めて、該求めた情報を前記セッションＩＤ及びリクエストＩＤに対応付けて成る内部データを生成・記憶する内部データ生成・記憶手段と、
   前記内部データに基づいて、任意の前記各リクエスト毎の処理全体の処理時間又は該処理全体中の各関数の前記実行時間を示す可視化表示を行うと共に、これと同一時間軸上に前記リソース状況データに基づく可視化表示を重ね合わせて表示する表示手段、
   として機能させる為のプログラム。
6. コンピュータを、
   任意のクライアントからの任意のリクエストを受付ける毎に生成されるセッションＩＤとリクエストＩＤとに対応付けて、該リクエストに応じた処理全体に係る性能データ、又は該処理全体中の各関数の処理実行に係る性能データが、ログ情報として記憶された性能データ記憶手段と、
   少なくとも前記リクエストに応じた処理の実行時のＯＳ／ミドルウェアのリソース状況を示す各種データが記憶されたリソース状況データ記憶手段と、
   前記記録されたログ情報に基づいて、任意の前記各リクエストに応じた処理全体の開始日時、終了日時、処理時間を求め、又は前記各関数毎にその関数の処理の開始日時、終了日時、該関数の処理実行に掛かった時間である実行時間を求めて、該求めた情報を前記セッションＩＤ及びリクエストＩＤに対応付けて成る内部データを生成・記憶する内部データ生成・記憶手段と、
   前記内部データに基づいて、任意の前記各リクエスト毎の処理全体の処理時間又は該処理全体中の各関数の前記実行時間を示す可視化表示を行うと共に、これと同一時間軸上に前記リソース状況データに基づく可視化表示を重ね合わせて表示する表示手段、
   として機能させる為のプログラム。