JP2004264914A - システム性能測定分析装置 - Google Patents
システム性能測定分析装置 Download PDFInfo
- Publication number
- JP2004264914A JP2004264914A JP2003046120A JP2003046120A JP2004264914A JP 2004264914 A JP2004264914 A JP 2004264914A JP 2003046120 A JP2003046120 A JP 2003046120A JP 2003046120 A JP2003046120 A JP 2003046120A JP 2004264914 A JP2004264914 A JP 2004264914A
- Authority
- JP
- Japan
- Prior art keywords
- processing unit
- performance
- application
- processing units
- processing
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3466—Performance evaluation by tracing or monitoring
- G06F11/3495—Performance evaluation by tracing or monitoring for systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/865—Monitoring of software
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/875—Monitoring of systems including the internet
Landscapes
- Engineering & Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
- Multi Processors (AREA)
Abstract
【課題】アプリケーションの動作性能を測定・分析し、その結果に基づき協同動作を最適化するためのシステム性能測定分析をコンピュータで実現させる。
【解決手段】性能を測定しようとするシステムのアプリケーションを分析し、それらのアプリケーションを構成する処理単位を抽出し、処理単位間の関連を明らかにし、且つ各処理単位がシステムを構成するハードウェア資源の内、どのハードウェア資源上で動作しているかを明らかにする。また、各処理単位の動作性能（実行に要する時間、各処理単位間の通信時間など）をアプリケーションのソースコードを改変することなく、計測することを実現する。加えて処理の実行段階において各ハードウェア資源の負荷状況を測定し、上記の各処理単位の動作性能と動作しているハードウェア資源及びハードウェア資源の負荷状況とともに表示する。
【選択図】図７
【解決手段】性能を測定しようとするシステムのアプリケーションを分析し、それらのアプリケーションを構成する処理単位を抽出し、処理単位間の関連を明らかにし、且つ各処理単位がシステムを構成するハードウェア資源の内、どのハードウェア資源上で動作しているかを明らかにする。また、各処理単位の動作性能（実行に要する時間、各処理単位間の通信時間など）をアプリケーションのソースコードを改変することなく、計測することを実現する。加えて処理の実行段階において各ハードウェア資源の負荷状況を測定し、上記の各処理単位の動作性能と動作しているハードウェア資源及びハードウェア資源の負荷状況とともに表示する。
【選択図】図７
Description
【０００１】
【発明の属する技術分野】
本発明は、ネットワークで接続された複数のサーバ及びソフトウェアによって構成されたシステム環境において、システム全体の動作性能を測定し・分析することによって、システムの協同動作を最適化するための方法に関する。
【０００２】
【従来の技術】
今日、コンピュータの使用が非常に盛んになり、あらゆるところでコンピュータが使用されている。さらに、複数のコンピュータ（サーバ）をネットワークで接続し、それらのサーバに様々なアプリケーションを分散して配置・利用する形態が一般化している。これらのアプリケーションは従来個別に利用されることが多かったが、インターネットやウェブの普及により、今日では複数のアプリケーションを協同動作させて所望の処理を実行する利用形態が増えている。ウェブサービスはその典型例である。このようなアプリケーションの協同動作環境においては、所望の処理に複数のアプリケーションが関与するため、所望の処理の動作性能を向上させるためには、所望の処理に関与する全てのアプリケーション（これらアプリケーションの全体をシステムと呼ぶ）の動作性能を改善することが必要となる。あるいは逆に、システム内のアプリケーションの一つでも性能が劣化すると、それがスループット上のボトルネックとなりシステムの動作性能が劣化してしまう。このような環境においては、システム内の全てのアプリケーションとＩＴリソースを監視し、システムの性能上のボトルネック解消を解消するための要因分析と解決策提示（これをシステムの最適化と呼ぶ）が必要となる。
従来、コンピュータシステムにおいてアプリケーション実行の性能劣化が発生した場合には、その要因を特定するために以下のような方法を使用していた。
１．ハードウェア資源（ＣＰＵ、ハードディスク、メモリ、ネットワークカードなど）の負荷状況を測定し、負荷が高いハードウェア資源を特定する。
２．アプリケーション群の個々の処理性能を測定し、性能劣化が見られるアプリケーションを特定する。
【０００３】
ＩＴリソースの負荷状況を監視するシステムの従来の取組みについては、特許文献１及び特許文献２がある。また、言語に依存しないでソフトウェアの性能を監視するシステムとしては、特許文献３がある。また、特許文献４は、ソフトウェアの構成をビジュアル化して表示する方法を開示し、特許文献５はソースコードの解析方法を開示している。
【０００４】
【特許文献１】
米国特許５，５７２，６７２号
【０００５】
【特許文献２】
米国特許５，５０６，９５５号
【０００６】
【特許文献３】
米国出願公開ＵＳ２００２／００９５６６０号
【０００７】
【特許文献４】
米国特許６，２２６，７８７号
【０００８】
【特許文献５】
米国特許５，５００，８８１号
アプリケーションが単一のハードウェア上に配置され、実行されてきた、従来のシステム環境においては、上記の方法を組み合わせることにより、どのアプリケーションの性能劣化が、どのハードウェア資源によって引き起こされていたかを特定するのは比較的容易である。
【０００９】
【発明が解決しようとする課題】
昨今はアプリケーション群がネットワークで接続された複数のハードウェアに分散的に配置され、実行されるケースが増加している。こうした環境においては、一つのアプリケーションが複数のハードウェア資源上で実行され得るため、アプリケーションとそれを実行しているハードウェア資源を一対一で対応付けることが困難となる。
【００１０】
この問題を解決するためには、アプリケーションをより細かな処理単位に分割し、処理単位ごとの性能を評価し、個々の処理単位とそれが動作しているハードウェア資源の両面から性能劣化の要因を特定する必要がある。
本発明の課題は、アプリケーションの動作性能をより詳細に測定し、協同動作の最適化作業に適切な情報を提供することのできるシステム性能測定分析装置を提供することである。
【００１１】
加えて、従来のアプリケーションの動作性能の測定手法においては、アプリケーションのソースコード入手や改変などが前提となっているが、本発明では不要とすることも課題としている。
【００１２】
【課題を解決するための手段】
本発明のシステム性能測定分析装置は、ネットワークで接続された複数のサーバにインストールされ、その一部または全てがバーチャルマシン環境下で協同動作する複数のアプリケーションに関して、該アプリケーションの動作性能を測定・分析し、その結果に基づき協同動作を最適化するためのシステム性能測定分析装置であって、該アプリケーションを構成する処理単位を解析・抽出し、処理単位間の呼び出し関係を解析・取得するアプリケーション解析手段と、該処理単位の動作性能を測定する動作性能測定手段と、該処理単位と、該処理単位が利用するハードウェア資源との対応関係を解析・取得するハードウェア資源特定手段と、該処理単位間の呼び出し関係、該処理単位の動作性能、該処理単位が動作するハードウェア資源を、共に表示する表示手段（これをオブジェクト・ディプロイメント・ダイアグラムと呼ぶ）を備えることを特徴とする。
【００１３】
【発明の実施の形態】
・前提とする環境
本発明の実施形態においては、ネットワークを介して接続された複数のハードウェア及びソフトウェア（アプリケーション）により構成されるシステム、すなわち、ハードウェア資源（サーバ、クライアントなどのコンピュータ、ネットワーク及びそれらを構成するＣＰＵ、メモリ、ハードディスク、ネットワークカード等）と、ソフトウェア資源（ハードウェア資源上に分散的に配置され実行されるアプリケーション群）により構成されているシステム環境を前提とする。またこれらのアプリケーションの一部または全部がバーチャルマシン環境（ ．ＮＥＴ（登録商標）プラットフォームのＣＬＲ（登録商標）、Ｊ２ＥＥ（登録商標）プラットフォームのＪＶＭ（登録商標）など）の下で実行されることを前提とする。
・バーチャルマシン環境
バーチャルマシン環境について述べる。本実施形態の装置では、システムの動作性能（処理単位の実行時間、ハードウェアの処理性能、ネットワークの通信時間など）を測定する際に、バーチャルマシン（ＶＭ）を介して行う。またバイナリーファイルからソースコードを復元する際にもＶＭ を利用する。ＶＭが利用可能な環境として、マイクロソフト社の ．ＮＥＴ（登録商標）やサンマイクロシステムが提唱したＪ２ＥＥ（登録商標）などがある。本明細書では．ＮＥＴ（登録商標）環境を前提とした手法（フローチャート）について説明する。他のＶＭ環境でも、本明細書に記述されている方法に基づいて同様の方法を容易に考案・実施できる。
図１は、．ＮＥＴ（登録商標）フレームワークの構成を示したものである。．ＮＥＴ（登録商標）フレームワークの内部は、大きく３つの要素から構成されている。最下層にあるＣＬＲ（Ｃｏｍｍｏｎ Ｌａｎｇｕａｇｅ Ｒｕｎｔｉｍｅ：登録商標）は、アプリケーションやコンポーネントを実行するためのエンジン（ＶＭ）である。そしてアプリケーションのシステム・インターフェイスとなるクラス・ライブラリ群がその上にある。ＡＳＰ ．ＮＥＴ（登録商標）は、Ｗｉｎｄｏｗｓ（登録商標）アプリケーションを除く、Ｗｅｂ ＳｅｒｖｉｃｅとＷｅｂアプリケーションを実装するためのクラス・ライブラリである。．ＮＥＴ（登録商標）フレームワーク上のアプリケーションは、．ＮＥＴ（登録商標）フレームワークによって提供されるクラス・ライブラリを使用してコーディングされる。作成されたソースコードは、コンパイラによってアプリケーションないしコンポーネントの実行コードに変換されるが、この際に生成されるのは特定のＣＰＵ命令に依存したネイティブ・コードではなく、マネージド・コードと呼ばれる中間コードである。アプリケーションの実行時には、マネージド・コードがＣＬＲのＪＩＴ（登録商標）コンパイラにより最終的なネイティブ・コードに変換され、実行される。
ＣＬＲは、マネージド・コードに対して、大きく分けて以下の２つの情報を持っていることを要求する。
（１）ＭＳＩＬ（Ｍｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｍｅｄｉａｔｅ Ｌａｎｇｕａｇｅ（中間言語：登録商標）：実行可能コード
（２）メタデータ ：ＭＳＩＬ（登録商標）に関する情報
（内部に含むメソッド／プロパティ、利用する外部のメソッド／プロパティ 等、ＣＬＲが実行時に必要とする情報）
・実施の形態の概要
本発明の実施形態においては、性能を測定しようとするシステムのソフトウエアを分析し、それらのソフトウエアを構成する処理単位 （オブジェクト）を抽出し、処理単位間の関連を明らかにして図示する（この図をコールグラフと呼ぶ）。コールグラフを生成する上で、バイナリファイル（実行可能ファイル）からソースコードを復元する。
【００１４】
次に、各処理単位の動作性能（実行に要する時間、各処理単位間の通信時間など）を計測する。バーチャルマシンから読み取り可能なデータを利用して動作性能を計測することで、アプリケーションのソースコードを改変することなくこれを実現する。
【００１５】
そして、各処理単位がシステムを構成するハードウェア資源の内、どのハードウェア資源上で動作しているかを明らかにする。また処理の実行段階において各ハードウェア資源の負荷状況を測定し表示する。
・実施の形態の詳細な説明
１． ソースコードの復元
ソースコードを直接入手できない場合でも、本発明が前提しているバーチャルマシン環境においては、本発明の方法を用いることでバイナリファイルからソースコードを復元する。
【００１６】
例えば ．ＮＥＴ（登録商標）環境においてはコンパイラにより、高級言語で記述されたソースコードをバイナリファイルに変換する。図２はソースコードからバイナリファイルを生成する過程と、バイナリファイルからソースコードを復元する過程を示した模式図である。２０１のＣ＃（登録商標）、Ｃ＋＋（登録商標）、ＶＢ（登録商標）（ビジュアルベーシック）などの高級言語で記述されたソースコードから２０２のコンパイル処理で２０３のバイナリファイルが生成される。また、バイナリファイルからソースコードを復元する際には．２０４のデコンパイルによりソースコードを復元する。
図３はソースコードを復元する処理ステップを示すフローチャートである。
ステップＳ３０１では、システム内の全サーバマシンを探査し、．ＮＥＴ（登録商標）環境がインストールされているサーバを発見し、接続する。ステップＳ３０２では、接続したサーバの．ＮＥＴ（登録商標）上のアプリケーションのバイナリファイルを収集する。Ｓ３０３では、バイナリファイルを読み込み、ステップＳ３０４でＭＳＩＬ（登録商標）ディスアセンブラエンジンを利用して、バイナリファイルからメタデータとＭＳＩＬ（登録商標）（中間コード）を抽出する。ステップＳ３０５でモジュールのＭＳＩＬ（登録商標）の構文解析を行い、ステップＳ３０６で意味解析を行う。各キーワード及びキーワードのパラメータを精査し、元の高級言語の対応するキーワードと照合する。この過程で変数、クラス、メソッド、プロパティなどを識別する。これらにより、ステップＳ３０６のとおりソースコードが復元される。
２． アプリケーションの解析
アプリケーションを解析しコールグラフを生成する方法として、ここではレイジーワーカー（Ｌａｚｙ Ｗｏｒｋｅｒ）法と命名した方法を用いる。レイジーワーカー法は、システム内のアプリケーションのソースコードを解析することにより、アプリケーションを構成する処理単位を抽出し、処理単位間の呼び出し関係を解析する方法の一つである。ここで処理単位とは、クラス、メソッド、プロパティや、クラスから生成されるインスタンス又はオブジェクトなどのような、アプリケーションの細かな実行単位を指す。
レイジーワーカー法は、準備プロセスとツリー生成プロセスの二段階で構成される。準備プロセスでは、ソースコードを基に「クラスの呼出元（Ｃａｌｌｅｒ）・呼出先（Ｃａｌｌｅｅ）」を解析・取得する。次のツリー生成プロセスでは、準備プロセスで取得したＣａｌｌｅｒ・Ｃａｌｌｅｅ情報に基づき、任意の処理単位に対して、該処理単位が直接／間接に呼び出す全処理単位の呼出関係をツリー型のデータ構造として生成する。ツリー生成プロセスが生成するツリー構造は「ノード」と「ポインタ」により表現される。ノードは処理単位に対応し、ポインタは処理単位間の呼出関係に対応する。生成されたツリー構造を適切な描画アプリケーションで描画することによりコールグラフを生成する。レイジーワーカー法では、準備プロセスでソースコードを解析しておくことにより、ツリー生成プロセスではソースコードを参照することなくツリー構造を生成する。これにより、任意の処理単位を起点とするコールグラフを、ソースコードの再解析なしに効率的に生成・描画する。
（１） 準備プロセス
図４はレイジーワーカー法の準備プロセスの処理ステップの例を示すフローチャートである。
準備プロセスでは、まず、ステップＳ４０１でクラスリストを用意する。クラスリストはクラスを登録するためのデータ構造である。リスト内の各クラスはツリー構造をしており、各クラス内のメソッド及びクラスの呼出元や呼出先のメソッドに関する情報等を格納している。クラスリストの初期値をヌル（空）にした後、アプリケーション内の全てのソースコードに対してステップＳ４０２のソースファイル処理を行っていく。
ソースファイル処理では、ソースファイル内の全てのソースコードに対してステップＳ４１１でクラスの記述の開始を検知することでクラスを抽出し、検知したクラスに対してステップＳ４１２のクラス処理を行っていく。
クラス処理では、検知したクラスをステップＳ４２１で自クラスとし、該クラス内の全ての記述からステップＳ４２２でメソッド又はプロパティの記述の開始を検知することでメソッド又はプロパティを抽出し、検知したメソッド又はプロパティに対してステップＳ４２３のコーラー・コーリー処理を行っていく。
コーラー・コーリー処理ではまず、ステップＳ４３１で検知したメソッド又はプロパティを自メソッドとし、ステップＳ４３２で自クラス及び自メソッドに対して後述のリスト・データ処理を行う。
自メソッド内の全ての記述から、ステップＳ４３３で他のメソッド又はプロパティの呼出を行っている記述を検知し、ステップＳ４３４で該メソッド又はプロパティが属するクラスを呼出先クラスとし、ステップＳ４３５該メソッド又はプロパティを呼出先メソッドとする。呼出先クラス及び呼出先メソッドに対してもステップＳ４３６でステップＳ４３２同様リスト・データ処理を行う。そして、ステップＳ４３７で自クラスの呼出先情報に呼出先メソッドを追加し、ステップＳ４３８で呼出先クラスの呼出元情報に自メソッドを追加する。
リスト・データ処理では該クラスが存在しない場合ステップＳ４４１でこれを追加する。該クラスに該メソッドが存在しない場合ステップＳ４４３でこれを追加する。
（２） ツリー生成プロセス
準備プロセスで解析・取得されたクラスの呼出元（Ｃａｌｌｅｒ）・呼出先（Ｃａｌｌｅｅ）情報を元に指定されたクラスについて、図５に示す処理ステップに従ってツリー型のデータ構造を生成する。
【００１７】
ツリー生成プロセスでは、ステップＳ５０１で指定されたクラスがクラスリストに存在しているかを参照し、該クラスが存在すればステップＳ５０２で該クラスに対応するノードを生成し、ステップＳ５０３のノード・ポインタ処理を行う。存在しなければステップＳ５０４で適切なエラーメッセージを表示して終了する。
【００１８】
ノード・ポインタ処理では、ステップＳ５１１で現在のノードをカレントノードとし、ステップＳ５１２でカレントノードの呼出先情報を参照し、ヌルでなければ、ステップＳ５１３で該情報として登録されている全ての呼出先のノードを生成する。このノードをターゲットノードと呼ぶ。ステップＳ５１４でカレントノードから全ターゲットノードへのポインタを生成する。生成した全ターゲットノードに対し、ステップＳ５１５で同様のノード・ポインタ処理を行う。
【００１９】
以上により、処理単位間の呼び出し関係を詳細なレベルで生成・描画できる。
３． システム構成
図６は、本発明の実施形態に従ったプログラムが実装されたシステムの構成を示す図である。６０１は監視専用端末であり、６０２は監視対象端末である。これらの端末は６０３のＬＡＮ、ＷＡＮ、インターネットなどのネットワークを介して接続されている。
４． ソフトウェア構成
図７は、本発明の実施形態に従ったプログラムの機能構成の概念図である。エージェントハンドラ７０１は、各サーバ１〜ｎに設けられるエージェント＃１〜＃ｎを統括管理するソフトウェアである。エージェントハンドラ７０１は、各監視対象端末を監視する監視専用端末で動作する。エージェントは各サーバ上で動作するソフトウェアである。エージェント＃１〜＃ｎは該エージェントが動作しているサーバ１〜ｎの動作性能を監視する。エージェントハンドラが各サーバの動作性能を監視するには、サーバ１〜ｎ上で動作しているエージェント＃１〜＃ｎとコンソール＃１〜＃ｎを介してエージェントから動作性能情報を取得する。
【００２０】
各サーバ１〜ｎのエージェント＃１〜＃ｎは、ＯＳの性能情報取得手段と、アプリケーション性能情報取得手段と、データベースシステム（ＤＢＭＳ）の性能情報取得手段と、ネットワークの性能情報を取得する手段とを有する。
ＯＳの性能情報は、ＯＳレベル監視プログラムから得られる。ＯＳレベル監視プログラムは、Ｗｉｎｄｏｗｓ環境におけるＷＭＩ（Ｗｉｎｄｏｗｓ Ｍａｎａｇｅｍｅｎｔ Ｉｎｓｔｒｕｍｅｎｔａｔｉｏｎ（登録商標））等である。アプリケーションの性能情報は、管理サービスプログラムを使用して取得する。管理サービスプログラムとは、Ｍｉｃｒｏｓｏｆｔ（登録商標）社の．ＮＥＴプラットフォームに設けられるＣＬＲ（Ｃｏｍｍｏｎ Ｌａｎｇｕａｇｅ Ｒｕｎｔｉｍｅ ：バーチャルマシンの機能を持つ）のようなユーティリティである。本発明においては、アプリケーションの性能情報を、後述の処理単位の動作性能の測定を行うことにより、より詳細なレベルで測定することを実現している。データベースの性能情報は、直接データベースにアクセスすることによって得られる。また、ネットワークの性能情報は、図６のシステムがＴＣＰ／ＩＰネットワークで構成されている場合、ＳＮＭＰによるネットワーク機器の監視や、回線の接続状況の監視を行うことによって得られる。
５． 処理単位の動作性能の測定
処理単位の動作性能（実行時間など）を測定する際、本発明が前提しているバーチャルマシン環境においては、本発明による方法でソースコードに一切手を加えずに動作性能を測定する。
ＶＭ環境下においては、ＶＭがアプリケーションの実行エンジンとしてコードの実行を管理し、アプリケーションに対して様々なサービスを提供している。アプリケーション実行時においては、ＶＭは各処理単位の実行に関わる様々な管理などを行っている。そこで本発明では、ＶＭにフッカ（ｈｏｏｋｅｒ）という小さなソフトウエアを挿入することで、ＶＭと直接自由に通信し、動作性能の測定に関わるデータをＶＭから取得することを実現している。アプリケーション実行時、ＶＭは処理単位の開始、終了、呼出等を管理している。これらのイベントがＶＭに発生すると、フッカは該イベントを検知し、更に必要とする情報の収集を行って該処理単位の動作性能を測定する。
【００２１】
図８は、処理単位の動作性能の測定の処理ステップを示すフローチャートである。本処理はフッカが前述のＶＭのイベント検知時に開始する。ステップＳ８０１では、ＶＭにアクセスして、イベントの種類を確認する。
イベントの種類がステップＳ８０２の処理単位の生成であった場合、ステップＳ８０３でメタデータにアクセスして、クラス名や内部に含むメソッド／プロパティ、利用する外部のクラス及びメソッド／プロパティ等の性能測定に必要な情報を収集し、ステップＳ８０４で該処理単位が開始した時間を保存する。
【００２２】
イベントの種類がステップＳ８０５の処理単位の呼出であった場合には、Ｓ８０６で呼出先が他のサーバで実行される処理単位であるか否かを判断し、他のサーバの場合には、ステップＳ８０７でサーバ間の通信に要した時間を記録する。
イベントの種類がステップＳ８０８の処理単位の終了であった場合には、ステップＳ８０９で合計実行時間を計算し、ステップＳ８１０で保存する。
６． ハードウェア資源特定手段
ＶＭ環境下においては、メタデータを参照することで該サーバに配置されているアプリケーション・コンポーネントの情報を収集できる。これにより、サーバ上に配置され、実行される処理単位を特定する。
【００２３】
図９は、処理単位の配置状況に関する情報を収集するためのフローである。ステップＳ９０１でネットワークに接続されているサーバに接続する。ステップＳ９０２で該サーバのＶＭに接続し、ステップＳ９０３でそのメタデータを参照して、ステップＳ９０４で該サーバで実行されうる処理単位の情報を収集する。ステップＳ９０５で収集した情報を保存する。以上の処理を、監視対象の全てのサーバに対して実行していくことで、各処理単位が実行されるサーバを特定することが可能である。
７． システム性能の表示
上記の手段により測定した処理単位の動作性能を、該処理単位間の呼び出し関係、該処理単位の動作性能、該処理単位が利用するハードウェア資源を共に、オブジェクトディプロイメントダイアグラム（以下、ＯＤＤと略記）と命名した表示方法により、表示する。
【００２４】
図１０と図１１は、ＯＤＤの表示例である。表示部の多くを占めるコールグラフ（処理単位間の関係を示すグラフ）が、図１０ではフロー型で表示されており、図１１ではツリー型で表示されている。
同図の上部には、「ウェブサーバ」、「アプリケーションサーバ＃１」「アプリケーションサーバ＃２」の表示部がある。各表示部は、色を有し、ウェブアプリケーションシステムを構成するサーバマシンを示す。もし、アプリケーション＃２が赤色で示され、且つ、画面の真ん中で「課金処理」が赤色で示されていたならば、「課金処理」は「アプリケーションサーバ＃２」で動作していることが分かる。システムの全てのマシン名は異なる色で表示される。スクリーン上に表示されるテキストなどの色はサーバマシンの色に対応している。
【００２５】
同図の右側には、「ＣＰＵ」「メモリ」「ディスク」「ネットワーク」と示されたグラフがある。これらのグラフは、各サーバにおけるハードウェア資源の消費量を示している。ユーザは、これを見て、ハードウェア資源の現状をチェックし、ハードウェアの状態とそのマシン上にある特定の処理単位との関連を得ることができる。
【００２６】
コールグラフ上には、ユーザが任意に設定した時間間隔における動作性能の平均値が示される。この動作性能は、ネットワーク性能（通信時間）、処理単位の動作性能（実行時間）、等を含む。図１０及び図１１の事例で示しているＯＤＤは、主にネットワーク性能と処理単位の動作性能を扱い、他のシステムの動作性能上無視できる程度の要素については表示していない。
【００２７】
スクリーンの下部には表がある。この表は、詳細な数値情報を表示する為に使用する。また、ユーザは、特定のデータの履歴を表から得ることができる。
このスクリーンの表示は、ユーザーが指定した任意の時間毎に更新される。
ユーザは、システムの性能が劣化する障害が発生した時などのシステムの動作性能をより詳細なレベルで見たい時には、このスクリーンを使って問題を特定する。障害要因は、“アプリケーション”、“環境設定”、“ハードウェア資源”、“ネットワーク”のいずれかに分類でき、対応することになる。“ハードウェア資源”とは、例えばハードディスク障害やディスプレイの障害などのＩＴ機器類に不具合が生じた場合であり、障害部分を修理又は交換することで対応できる。“ネットワーク”の場合、障害対応ができる範囲はＬＡＮなどの特定の範囲に限られる。また、これらのハードウェア資源やネットワークを設定するのが、“環境設定”であるが、ハードウェア資源すなわち、ＣＰＵ、ハードディスク、メモリや、ネットワーク等はアプリケーションが使用することによって動作するものであることから、システム障害の大部分は“アプリケーション”によって引き起こされているものであると言える。
以下に“アプリケーション”、“環境設定”、“ハードウェア資源”、“ネットワーク”のそれぞれによって障害が引き起こされている場合の例を述べる。
１． アプリケーションの場合
アプリケーションによって障害が引き起こされている場合、システム管理者は表の“平均応答時間”と“応答時間”の値を比較することで、容易に特定の処理単位の動作性能が劣化していることに気付くことができる。これらの２つの値に大きな差があれば、何らかの問題があると考えることができる。このような場合、その他の処理単位の動作性能についても調べ、最も動作性能の劣化している処理単位を特定することが可能である。例えば、ある処理単位の現在の応答時間が８．１秒であり、平均応答時間が６．１秒であった場合、システムに何らかの障害が起きていると考えることができる。システム管理者は動作している他の処理単位についても調査をする。平均応答時間は３．１秒の“会計処理”の現在の応答時間が５．１秒であれば、“会計処理”には、平均と比較して２秒の差が生じていることになる。これに対して他の処理単位の応答時間のずれは０．５秒以内であったとすると、システム管理者は“会計処理”をクリックし、ソースコードを確認してその障害の原因を特定することができる。
２． 環境設定の場合
環境設定に問題がある場合、それはサーバマシン全体に影響を与える為、サーバマシン全体の性能が劣化することになる。典型的な例としては、環境設定の問題により、サーバマシン上の全ての処理単位の動作性能が劣化することが挙げられる。基本的な考え方はアプリケーションの場合と似ているが、性能に影響を与える範囲に違いがある。
【００２８】
障害の発見は、アプリケーションの場合同様、動作性能の劣化を注意深く観察することで行うことができる。
３． ハードウェア資源の場合
ハードウェア資源に問題がある場合、特定のマシンのＣＰＵやメモリ、ハードディスク等の消費時間が得られなかったり、その消費率が０になったりすることから、アプリケーションや環境設定の場合に比して、障害の発見は容易である。
【００２９】
例えば、ＯＤＤにサーバＡからのハードウェア資源の消費状況に関する値が表示されなくなった場合、サーバＡは障害を起こしていると考えることが出来る。
４． ネットワークの場合
ネットワーク障害は一般的に、システムを構成するサーバマシンがインターネットを介して接続された二つ以上のＬＡＮに分散して配置されている場合に影響を与える。たとえそれぞれの拠点のＬＡＮの性能が良くても、インターネットの性能までを保証することはできない。
【００３０】
例えばサーバマシンＡがＬＡＮ＃１に、サーバマシンＢがＬＡＮ＃２に配置されており、ＬＡＮ＃１とＬＡＮ＃２がインターネットを介して接続されている場合、ＬＡＮ＃１とＬＡＮ＃２がいかに高速であっても、インターネットの部分はコントロールすることができないため、システム全体のネットワーク性能については誰も保証することができない。
【００３１】
ＯＤＤの表示においては、個々のオブジェクトをつなぐ線の色や種類（波線や点線など）を変えて表示し、オブジェクトが異なるネットワーク上に存在することを示す。加えて、個々の表示アイテムごとの動作性能を表示する。
【００３２】
【発明の効果】
本発明により、アプリケーションの動作性能をより細かな処理単位で測定し、且つ個々の処理単位が動作しているハードウェア資源との対応を容易に明らかにできる。加えて、ＯＤＤにより、上記の個々の処理単位の動作性能とそれらが動作しているハードウェア資源との対応を視覚的、直感的に理解できる形で提供することが可能となる。
【００３３】
このように、ＯＤＤは、問題の原因を特定するのに役立つ情報を直感的に理解できる形で提供することで、ユーザが応答性能の調査を容易に行うことを可能とする。
これにより、システムの性能劣化を検知した際には、その要因を細かな処理単位レベルで特定することが可能となり、解決する為に改善すべきプログラムをより細かな処理単位レベルで知ることが可能となる。
【００３４】
また、処理単位とハードウェア資源の対応関係を容易に把握することが可能となるため、システムの性能劣化を解決しようとする場合において、ソフトウェアの処理方法の改善とＩＴリソースの処理能力の向上を図るなど、システムを構成するソフトウェアとハードウェアの両面から、その要因をより詳細なレベルで特定し、改善すべきアイテム（修正すべき処理単位または増強すべきハードウェア資源など）を知ることが可能となる。結果として、アプリケーションのソースコードの書き換え・修正やハードウェア資源の増強を行って、アプリケーションの動作性能を迅速に最適化することができる。
【図面の簡単な説明】
【図１】バーチャルマシン環境の１つの例である．ＮＥＴ（登録商標）の構成を示す図である。
【図２】ソースコードからバイナリファイルの生成と、バイナリファイルからソースコードの復元を行う際の考え方を示した図である。
【図３】ソースコード復元処理のフローである。
【図４】レイジーワーカー法の準備プロセスの処理のフローである。
【図５】レイジーワーカー法のツリー生成プロセスの処理のフローである。
【図６】本発明の実施形態に従った装置のシステム構成を示す図である。
【図７】本発明の実施形態に従ったソフトウェアの機能構成の概念図である。
【図８】オブジェクトの動作性能の測定の処理のフローである。
【図９】オブジェクト配置情報の収集の処理のフローである。
【図１０】オブジェクトディプロイメントダイアグラム（フロー型）の表示例である。
【図１１】オブジェクトディプロイメントダイアグラム（ツリー型）の表示例である。
【発明の属する技術分野】
本発明は、ネットワークで接続された複数のサーバ及びソフトウェアによって構成されたシステム環境において、システム全体の動作性能を測定し・分析することによって、システムの協同動作を最適化するための方法に関する。
【０００２】
【従来の技術】
今日、コンピュータの使用が非常に盛んになり、あらゆるところでコンピュータが使用されている。さらに、複数のコンピュータ（サーバ）をネットワークで接続し、それらのサーバに様々なアプリケーションを分散して配置・利用する形態が一般化している。これらのアプリケーションは従来個別に利用されることが多かったが、インターネットやウェブの普及により、今日では複数のアプリケーションを協同動作させて所望の処理を実行する利用形態が増えている。ウェブサービスはその典型例である。このようなアプリケーションの協同動作環境においては、所望の処理に複数のアプリケーションが関与するため、所望の処理の動作性能を向上させるためには、所望の処理に関与する全てのアプリケーション（これらアプリケーションの全体をシステムと呼ぶ）の動作性能を改善することが必要となる。あるいは逆に、システム内のアプリケーションの一つでも性能が劣化すると、それがスループット上のボトルネックとなりシステムの動作性能が劣化してしまう。このような環境においては、システム内の全てのアプリケーションとＩＴリソースを監視し、システムの性能上のボトルネック解消を解消するための要因分析と解決策提示（これをシステムの最適化と呼ぶ）が必要となる。
従来、コンピュータシステムにおいてアプリケーション実行の性能劣化が発生した場合には、その要因を特定するために以下のような方法を使用していた。
１．ハードウェア資源（ＣＰＵ、ハードディスク、メモリ、ネットワークカードなど）の負荷状況を測定し、負荷が高いハードウェア資源を特定する。
２．アプリケーション群の個々の処理性能を測定し、性能劣化が見られるアプリケーションを特定する。
【０００３】
ＩＴリソースの負荷状況を監視するシステムの従来の取組みについては、特許文献１及び特許文献２がある。また、言語に依存しないでソフトウェアの性能を監視するシステムとしては、特許文献３がある。また、特許文献４は、ソフトウェアの構成をビジュアル化して表示する方法を開示し、特許文献５はソースコードの解析方法を開示している。
【０００４】
【特許文献１】
米国特許５，５７２，６７２号
【０００５】
【特許文献２】
米国特許５，５０６，９５５号
【０００６】
【特許文献３】
米国出願公開ＵＳ２００２／００９５６６０号
【０００７】
【特許文献４】
米国特許６，２２６，７８７号
【０００８】
【特許文献５】
米国特許５，５００，８８１号
アプリケーションが単一のハードウェア上に配置され、実行されてきた、従来のシステム環境においては、上記の方法を組み合わせることにより、どのアプリケーションの性能劣化が、どのハードウェア資源によって引き起こされていたかを特定するのは比較的容易である。
【０００９】
【発明が解決しようとする課題】
昨今はアプリケーション群がネットワークで接続された複数のハードウェアに分散的に配置され、実行されるケースが増加している。こうした環境においては、一つのアプリケーションが複数のハードウェア資源上で実行され得るため、アプリケーションとそれを実行しているハードウェア資源を一対一で対応付けることが困難となる。
【００１０】
この問題を解決するためには、アプリケーションをより細かな処理単位に分割し、処理単位ごとの性能を評価し、個々の処理単位とそれが動作しているハードウェア資源の両面から性能劣化の要因を特定する必要がある。
本発明の課題は、アプリケーションの動作性能をより詳細に測定し、協同動作の最適化作業に適切な情報を提供することのできるシステム性能測定分析装置を提供することである。
【００１１】
加えて、従来のアプリケーションの動作性能の測定手法においては、アプリケーションのソースコード入手や改変などが前提となっているが、本発明では不要とすることも課題としている。
【００１２】
【課題を解決するための手段】
本発明のシステム性能測定分析装置は、ネットワークで接続された複数のサーバにインストールされ、その一部または全てがバーチャルマシン環境下で協同動作する複数のアプリケーションに関して、該アプリケーションの動作性能を測定・分析し、その結果に基づき協同動作を最適化するためのシステム性能測定分析装置であって、該アプリケーションを構成する処理単位を解析・抽出し、処理単位間の呼び出し関係を解析・取得するアプリケーション解析手段と、該処理単位の動作性能を測定する動作性能測定手段と、該処理単位と、該処理単位が利用するハードウェア資源との対応関係を解析・取得するハードウェア資源特定手段と、該処理単位間の呼び出し関係、該処理単位の動作性能、該処理単位が動作するハードウェア資源を、共に表示する表示手段（これをオブジェクト・ディプロイメント・ダイアグラムと呼ぶ）を備えることを特徴とする。
【００１３】
【発明の実施の形態】
・前提とする環境
本発明の実施形態においては、ネットワークを介して接続された複数のハードウェア及びソフトウェア（アプリケーション）により構成されるシステム、すなわち、ハードウェア資源（サーバ、クライアントなどのコンピュータ、ネットワーク及びそれらを構成するＣＰＵ、メモリ、ハードディスク、ネットワークカード等）と、ソフトウェア資源（ハードウェア資源上に分散的に配置され実行されるアプリケーション群）により構成されているシステム環境を前提とする。またこれらのアプリケーションの一部または全部がバーチャルマシン環境（ ．ＮＥＴ（登録商標）プラットフォームのＣＬＲ（登録商標）、Ｊ２ＥＥ（登録商標）プラットフォームのＪＶＭ（登録商標）など）の下で実行されることを前提とする。
・バーチャルマシン環境
バーチャルマシン環境について述べる。本実施形態の装置では、システムの動作性能（処理単位の実行時間、ハードウェアの処理性能、ネットワークの通信時間など）を測定する際に、バーチャルマシン（ＶＭ）を介して行う。またバイナリーファイルからソースコードを復元する際にもＶＭ を利用する。ＶＭが利用可能な環境として、マイクロソフト社の ．ＮＥＴ（登録商標）やサンマイクロシステムが提唱したＪ２ＥＥ（登録商標）などがある。本明細書では．ＮＥＴ（登録商標）環境を前提とした手法（フローチャート）について説明する。他のＶＭ環境でも、本明細書に記述されている方法に基づいて同様の方法を容易に考案・実施できる。
図１は、．ＮＥＴ（登録商標）フレームワークの構成を示したものである。．ＮＥＴ（登録商標）フレームワークの内部は、大きく３つの要素から構成されている。最下層にあるＣＬＲ（Ｃｏｍｍｏｎ Ｌａｎｇｕａｇｅ Ｒｕｎｔｉｍｅ：登録商標）は、アプリケーションやコンポーネントを実行するためのエンジン（ＶＭ）である。そしてアプリケーションのシステム・インターフェイスとなるクラス・ライブラリ群がその上にある。ＡＳＰ ．ＮＥＴ（登録商標）は、Ｗｉｎｄｏｗｓ（登録商標）アプリケーションを除く、Ｗｅｂ ＳｅｒｖｉｃｅとＷｅｂアプリケーションを実装するためのクラス・ライブラリである。．ＮＥＴ（登録商標）フレームワーク上のアプリケーションは、．ＮＥＴ（登録商標）フレームワークによって提供されるクラス・ライブラリを使用してコーディングされる。作成されたソースコードは、コンパイラによってアプリケーションないしコンポーネントの実行コードに変換されるが、この際に生成されるのは特定のＣＰＵ命令に依存したネイティブ・コードではなく、マネージド・コードと呼ばれる中間コードである。アプリケーションの実行時には、マネージド・コードがＣＬＲのＪＩＴ（登録商標）コンパイラにより最終的なネイティブ・コードに変換され、実行される。
ＣＬＲは、マネージド・コードに対して、大きく分けて以下の２つの情報を持っていることを要求する。
（１）ＭＳＩＬ（Ｍｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｍｅｄｉａｔｅ Ｌａｎｇｕａｇｅ（中間言語：登録商標）：実行可能コード
（２）メタデータ ：ＭＳＩＬ（登録商標）に関する情報
（内部に含むメソッド／プロパティ、利用する外部のメソッド／プロパティ 等、ＣＬＲが実行時に必要とする情報）
・実施の形態の概要
本発明の実施形態においては、性能を測定しようとするシステムのソフトウエアを分析し、それらのソフトウエアを構成する処理単位 （オブジェクト）を抽出し、処理単位間の関連を明らかにして図示する（この図をコールグラフと呼ぶ）。コールグラフを生成する上で、バイナリファイル（実行可能ファイル）からソースコードを復元する。
【００１４】
次に、各処理単位の動作性能（実行に要する時間、各処理単位間の通信時間など）を計測する。バーチャルマシンから読み取り可能なデータを利用して動作性能を計測することで、アプリケーションのソースコードを改変することなくこれを実現する。
【００１５】
そして、各処理単位がシステムを構成するハードウェア資源の内、どのハードウェア資源上で動作しているかを明らかにする。また処理の実行段階において各ハードウェア資源の負荷状況を測定し表示する。
・実施の形態の詳細な説明
１． ソースコードの復元
ソースコードを直接入手できない場合でも、本発明が前提しているバーチャルマシン環境においては、本発明の方法を用いることでバイナリファイルからソースコードを復元する。
【００１６】
例えば ．ＮＥＴ（登録商標）環境においてはコンパイラにより、高級言語で記述されたソースコードをバイナリファイルに変換する。図２はソースコードからバイナリファイルを生成する過程と、バイナリファイルからソースコードを復元する過程を示した模式図である。２０１のＣ＃（登録商標）、Ｃ＋＋（登録商標）、ＶＢ（登録商標）（ビジュアルベーシック）などの高級言語で記述されたソースコードから２０２のコンパイル処理で２０３のバイナリファイルが生成される。また、バイナリファイルからソースコードを復元する際には．２０４のデコンパイルによりソースコードを復元する。
図３はソースコードを復元する処理ステップを示すフローチャートである。
ステップＳ３０１では、システム内の全サーバマシンを探査し、．ＮＥＴ（登録商標）環境がインストールされているサーバを発見し、接続する。ステップＳ３０２では、接続したサーバの．ＮＥＴ（登録商標）上のアプリケーションのバイナリファイルを収集する。Ｓ３０３では、バイナリファイルを読み込み、ステップＳ３０４でＭＳＩＬ（登録商標）ディスアセンブラエンジンを利用して、バイナリファイルからメタデータとＭＳＩＬ（登録商標）（中間コード）を抽出する。ステップＳ３０５でモジュールのＭＳＩＬ（登録商標）の構文解析を行い、ステップＳ３０６で意味解析を行う。各キーワード及びキーワードのパラメータを精査し、元の高級言語の対応するキーワードと照合する。この過程で変数、クラス、メソッド、プロパティなどを識別する。これらにより、ステップＳ３０６のとおりソースコードが復元される。
２． アプリケーションの解析
アプリケーションを解析しコールグラフを生成する方法として、ここではレイジーワーカー（Ｌａｚｙ Ｗｏｒｋｅｒ）法と命名した方法を用いる。レイジーワーカー法は、システム内のアプリケーションのソースコードを解析することにより、アプリケーションを構成する処理単位を抽出し、処理単位間の呼び出し関係を解析する方法の一つである。ここで処理単位とは、クラス、メソッド、プロパティや、クラスから生成されるインスタンス又はオブジェクトなどのような、アプリケーションの細かな実行単位を指す。
レイジーワーカー法は、準備プロセスとツリー生成プロセスの二段階で構成される。準備プロセスでは、ソースコードを基に「クラスの呼出元（Ｃａｌｌｅｒ）・呼出先（Ｃａｌｌｅｅ）」を解析・取得する。次のツリー生成プロセスでは、準備プロセスで取得したＣａｌｌｅｒ・Ｃａｌｌｅｅ情報に基づき、任意の処理単位に対して、該処理単位が直接／間接に呼び出す全処理単位の呼出関係をツリー型のデータ構造として生成する。ツリー生成プロセスが生成するツリー構造は「ノード」と「ポインタ」により表現される。ノードは処理単位に対応し、ポインタは処理単位間の呼出関係に対応する。生成されたツリー構造を適切な描画アプリケーションで描画することによりコールグラフを生成する。レイジーワーカー法では、準備プロセスでソースコードを解析しておくことにより、ツリー生成プロセスではソースコードを参照することなくツリー構造を生成する。これにより、任意の処理単位を起点とするコールグラフを、ソースコードの再解析なしに効率的に生成・描画する。
（１） 準備プロセス
図４はレイジーワーカー法の準備プロセスの処理ステップの例を示すフローチャートである。
準備プロセスでは、まず、ステップＳ４０１でクラスリストを用意する。クラスリストはクラスを登録するためのデータ構造である。リスト内の各クラスはツリー構造をしており、各クラス内のメソッド及びクラスの呼出元や呼出先のメソッドに関する情報等を格納している。クラスリストの初期値をヌル（空）にした後、アプリケーション内の全てのソースコードに対してステップＳ４０２のソースファイル処理を行っていく。
ソースファイル処理では、ソースファイル内の全てのソースコードに対してステップＳ４１１でクラスの記述の開始を検知することでクラスを抽出し、検知したクラスに対してステップＳ４１２のクラス処理を行っていく。
クラス処理では、検知したクラスをステップＳ４２１で自クラスとし、該クラス内の全ての記述からステップＳ４２２でメソッド又はプロパティの記述の開始を検知することでメソッド又はプロパティを抽出し、検知したメソッド又はプロパティに対してステップＳ４２３のコーラー・コーリー処理を行っていく。
コーラー・コーリー処理ではまず、ステップＳ４３１で検知したメソッド又はプロパティを自メソッドとし、ステップＳ４３２で自クラス及び自メソッドに対して後述のリスト・データ処理を行う。
自メソッド内の全ての記述から、ステップＳ４３３で他のメソッド又はプロパティの呼出を行っている記述を検知し、ステップＳ４３４で該メソッド又はプロパティが属するクラスを呼出先クラスとし、ステップＳ４３５該メソッド又はプロパティを呼出先メソッドとする。呼出先クラス及び呼出先メソッドに対してもステップＳ４３６でステップＳ４３２同様リスト・データ処理を行う。そして、ステップＳ４３７で自クラスの呼出先情報に呼出先メソッドを追加し、ステップＳ４３８で呼出先クラスの呼出元情報に自メソッドを追加する。
リスト・データ処理では該クラスが存在しない場合ステップＳ４４１でこれを追加する。該クラスに該メソッドが存在しない場合ステップＳ４４３でこれを追加する。
（２） ツリー生成プロセス
準備プロセスで解析・取得されたクラスの呼出元（Ｃａｌｌｅｒ）・呼出先（Ｃａｌｌｅｅ）情報を元に指定されたクラスについて、図５に示す処理ステップに従ってツリー型のデータ構造を生成する。
【００１７】
ツリー生成プロセスでは、ステップＳ５０１で指定されたクラスがクラスリストに存在しているかを参照し、該クラスが存在すればステップＳ５０２で該クラスに対応するノードを生成し、ステップＳ５０３のノード・ポインタ処理を行う。存在しなければステップＳ５０４で適切なエラーメッセージを表示して終了する。
【００１８】
ノード・ポインタ処理では、ステップＳ５１１で現在のノードをカレントノードとし、ステップＳ５１２でカレントノードの呼出先情報を参照し、ヌルでなければ、ステップＳ５１３で該情報として登録されている全ての呼出先のノードを生成する。このノードをターゲットノードと呼ぶ。ステップＳ５１４でカレントノードから全ターゲットノードへのポインタを生成する。生成した全ターゲットノードに対し、ステップＳ５１５で同様のノード・ポインタ処理を行う。
【００１９】
以上により、処理単位間の呼び出し関係を詳細なレベルで生成・描画できる。
３． システム構成
図６は、本発明の実施形態に従ったプログラムが実装されたシステムの構成を示す図である。６０１は監視専用端末であり、６０２は監視対象端末である。これらの端末は６０３のＬＡＮ、ＷＡＮ、インターネットなどのネットワークを介して接続されている。
４． ソフトウェア構成
図７は、本発明の実施形態に従ったプログラムの機能構成の概念図である。エージェントハンドラ７０１は、各サーバ１〜ｎに設けられるエージェント＃１〜＃ｎを統括管理するソフトウェアである。エージェントハンドラ７０１は、各監視対象端末を監視する監視専用端末で動作する。エージェントは各サーバ上で動作するソフトウェアである。エージェント＃１〜＃ｎは該エージェントが動作しているサーバ１〜ｎの動作性能を監視する。エージェントハンドラが各サーバの動作性能を監視するには、サーバ１〜ｎ上で動作しているエージェント＃１〜＃ｎとコンソール＃１〜＃ｎを介してエージェントから動作性能情報を取得する。
【００２０】
各サーバ１〜ｎのエージェント＃１〜＃ｎは、ＯＳの性能情報取得手段と、アプリケーション性能情報取得手段と、データベースシステム（ＤＢＭＳ）の性能情報取得手段と、ネットワークの性能情報を取得する手段とを有する。
ＯＳの性能情報は、ＯＳレベル監視プログラムから得られる。ＯＳレベル監視プログラムは、Ｗｉｎｄｏｗｓ環境におけるＷＭＩ（Ｗｉｎｄｏｗｓ Ｍａｎａｇｅｍｅｎｔ Ｉｎｓｔｒｕｍｅｎｔａｔｉｏｎ（登録商標））等である。アプリケーションの性能情報は、管理サービスプログラムを使用して取得する。管理サービスプログラムとは、Ｍｉｃｒｏｓｏｆｔ（登録商標）社の．ＮＥＴプラットフォームに設けられるＣＬＲ（Ｃｏｍｍｏｎ Ｌａｎｇｕａｇｅ Ｒｕｎｔｉｍｅ ：バーチャルマシンの機能を持つ）のようなユーティリティである。本発明においては、アプリケーションの性能情報を、後述の処理単位の動作性能の測定を行うことにより、より詳細なレベルで測定することを実現している。データベースの性能情報は、直接データベースにアクセスすることによって得られる。また、ネットワークの性能情報は、図６のシステムがＴＣＰ／ＩＰネットワークで構成されている場合、ＳＮＭＰによるネットワーク機器の監視や、回線の接続状況の監視を行うことによって得られる。
５． 処理単位の動作性能の測定
処理単位の動作性能（実行時間など）を測定する際、本発明が前提しているバーチャルマシン環境においては、本発明による方法でソースコードに一切手を加えずに動作性能を測定する。
ＶＭ環境下においては、ＶＭがアプリケーションの実行エンジンとしてコードの実行を管理し、アプリケーションに対して様々なサービスを提供している。アプリケーション実行時においては、ＶＭは各処理単位の実行に関わる様々な管理などを行っている。そこで本発明では、ＶＭにフッカ（ｈｏｏｋｅｒ）という小さなソフトウエアを挿入することで、ＶＭと直接自由に通信し、動作性能の測定に関わるデータをＶＭから取得することを実現している。アプリケーション実行時、ＶＭは処理単位の開始、終了、呼出等を管理している。これらのイベントがＶＭに発生すると、フッカは該イベントを検知し、更に必要とする情報の収集を行って該処理単位の動作性能を測定する。
【００２１】
図８は、処理単位の動作性能の測定の処理ステップを示すフローチャートである。本処理はフッカが前述のＶＭのイベント検知時に開始する。ステップＳ８０１では、ＶＭにアクセスして、イベントの種類を確認する。
イベントの種類がステップＳ８０２の処理単位の生成であった場合、ステップＳ８０３でメタデータにアクセスして、クラス名や内部に含むメソッド／プロパティ、利用する外部のクラス及びメソッド／プロパティ等の性能測定に必要な情報を収集し、ステップＳ８０４で該処理単位が開始した時間を保存する。
【００２２】
イベントの種類がステップＳ８０５の処理単位の呼出であった場合には、Ｓ８０６で呼出先が他のサーバで実行される処理単位であるか否かを判断し、他のサーバの場合には、ステップＳ８０７でサーバ間の通信に要した時間を記録する。
イベントの種類がステップＳ８０８の処理単位の終了であった場合には、ステップＳ８０９で合計実行時間を計算し、ステップＳ８１０で保存する。
６． ハードウェア資源特定手段
ＶＭ環境下においては、メタデータを参照することで該サーバに配置されているアプリケーション・コンポーネントの情報を収集できる。これにより、サーバ上に配置され、実行される処理単位を特定する。
【００２３】
図９は、処理単位の配置状況に関する情報を収集するためのフローである。ステップＳ９０１でネットワークに接続されているサーバに接続する。ステップＳ９０２で該サーバのＶＭに接続し、ステップＳ９０３でそのメタデータを参照して、ステップＳ９０４で該サーバで実行されうる処理単位の情報を収集する。ステップＳ９０５で収集した情報を保存する。以上の処理を、監視対象の全てのサーバに対して実行していくことで、各処理単位が実行されるサーバを特定することが可能である。
７． システム性能の表示
上記の手段により測定した処理単位の動作性能を、該処理単位間の呼び出し関係、該処理単位の動作性能、該処理単位が利用するハードウェア資源を共に、オブジェクトディプロイメントダイアグラム（以下、ＯＤＤと略記）と命名した表示方法により、表示する。
【００２４】
図１０と図１１は、ＯＤＤの表示例である。表示部の多くを占めるコールグラフ（処理単位間の関係を示すグラフ）が、図１０ではフロー型で表示されており、図１１ではツリー型で表示されている。
同図の上部には、「ウェブサーバ」、「アプリケーションサーバ＃１」「アプリケーションサーバ＃２」の表示部がある。各表示部は、色を有し、ウェブアプリケーションシステムを構成するサーバマシンを示す。もし、アプリケーション＃２が赤色で示され、且つ、画面の真ん中で「課金処理」が赤色で示されていたならば、「課金処理」は「アプリケーションサーバ＃２」で動作していることが分かる。システムの全てのマシン名は異なる色で表示される。スクリーン上に表示されるテキストなどの色はサーバマシンの色に対応している。
【００２５】
同図の右側には、「ＣＰＵ」「メモリ」「ディスク」「ネットワーク」と示されたグラフがある。これらのグラフは、各サーバにおけるハードウェア資源の消費量を示している。ユーザは、これを見て、ハードウェア資源の現状をチェックし、ハードウェアの状態とそのマシン上にある特定の処理単位との関連を得ることができる。
【００２６】
コールグラフ上には、ユーザが任意に設定した時間間隔における動作性能の平均値が示される。この動作性能は、ネットワーク性能（通信時間）、処理単位の動作性能（実行時間）、等を含む。図１０及び図１１の事例で示しているＯＤＤは、主にネットワーク性能と処理単位の動作性能を扱い、他のシステムの動作性能上無視できる程度の要素については表示していない。
【００２７】
スクリーンの下部には表がある。この表は、詳細な数値情報を表示する為に使用する。また、ユーザは、特定のデータの履歴を表から得ることができる。
このスクリーンの表示は、ユーザーが指定した任意の時間毎に更新される。
ユーザは、システムの性能が劣化する障害が発生した時などのシステムの動作性能をより詳細なレベルで見たい時には、このスクリーンを使って問題を特定する。障害要因は、“アプリケーション”、“環境設定”、“ハードウェア資源”、“ネットワーク”のいずれかに分類でき、対応することになる。“ハードウェア資源”とは、例えばハードディスク障害やディスプレイの障害などのＩＴ機器類に不具合が生じた場合であり、障害部分を修理又は交換することで対応できる。“ネットワーク”の場合、障害対応ができる範囲はＬＡＮなどの特定の範囲に限られる。また、これらのハードウェア資源やネットワークを設定するのが、“環境設定”であるが、ハードウェア資源すなわち、ＣＰＵ、ハードディスク、メモリや、ネットワーク等はアプリケーションが使用することによって動作するものであることから、システム障害の大部分は“アプリケーション”によって引き起こされているものであると言える。
以下に“アプリケーション”、“環境設定”、“ハードウェア資源”、“ネットワーク”のそれぞれによって障害が引き起こされている場合の例を述べる。
１． アプリケーションの場合
アプリケーションによって障害が引き起こされている場合、システム管理者は表の“平均応答時間”と“応答時間”の値を比較することで、容易に特定の処理単位の動作性能が劣化していることに気付くことができる。これらの２つの値に大きな差があれば、何らかの問題があると考えることができる。このような場合、その他の処理単位の動作性能についても調べ、最も動作性能の劣化している処理単位を特定することが可能である。例えば、ある処理単位の現在の応答時間が８．１秒であり、平均応答時間が６．１秒であった場合、システムに何らかの障害が起きていると考えることができる。システム管理者は動作している他の処理単位についても調査をする。平均応答時間は３．１秒の“会計処理”の現在の応答時間が５．１秒であれば、“会計処理”には、平均と比較して２秒の差が生じていることになる。これに対して他の処理単位の応答時間のずれは０．５秒以内であったとすると、システム管理者は“会計処理”をクリックし、ソースコードを確認してその障害の原因を特定することができる。
２． 環境設定の場合
環境設定に問題がある場合、それはサーバマシン全体に影響を与える為、サーバマシン全体の性能が劣化することになる。典型的な例としては、環境設定の問題により、サーバマシン上の全ての処理単位の動作性能が劣化することが挙げられる。基本的な考え方はアプリケーションの場合と似ているが、性能に影響を与える範囲に違いがある。
【００２８】
障害の発見は、アプリケーションの場合同様、動作性能の劣化を注意深く観察することで行うことができる。
３． ハードウェア資源の場合
ハードウェア資源に問題がある場合、特定のマシンのＣＰＵやメモリ、ハードディスク等の消費時間が得られなかったり、その消費率が０になったりすることから、アプリケーションや環境設定の場合に比して、障害の発見は容易である。
【００２９】
例えば、ＯＤＤにサーバＡからのハードウェア資源の消費状況に関する値が表示されなくなった場合、サーバＡは障害を起こしていると考えることが出来る。
４． ネットワークの場合
ネットワーク障害は一般的に、システムを構成するサーバマシンがインターネットを介して接続された二つ以上のＬＡＮに分散して配置されている場合に影響を与える。たとえそれぞれの拠点のＬＡＮの性能が良くても、インターネットの性能までを保証することはできない。
【００３０】
例えばサーバマシンＡがＬＡＮ＃１に、サーバマシンＢがＬＡＮ＃２に配置されており、ＬＡＮ＃１とＬＡＮ＃２がインターネットを介して接続されている場合、ＬＡＮ＃１とＬＡＮ＃２がいかに高速であっても、インターネットの部分はコントロールすることができないため、システム全体のネットワーク性能については誰も保証することができない。
【００３１】
ＯＤＤの表示においては、個々のオブジェクトをつなぐ線の色や種類（波線や点線など）を変えて表示し、オブジェクトが異なるネットワーク上に存在することを示す。加えて、個々の表示アイテムごとの動作性能を表示する。
【００３２】
【発明の効果】
本発明により、アプリケーションの動作性能をより細かな処理単位で測定し、且つ個々の処理単位が動作しているハードウェア資源との対応を容易に明らかにできる。加えて、ＯＤＤにより、上記の個々の処理単位の動作性能とそれらが動作しているハードウェア資源との対応を視覚的、直感的に理解できる形で提供することが可能となる。
【００３３】
このように、ＯＤＤは、問題の原因を特定するのに役立つ情報を直感的に理解できる形で提供することで、ユーザが応答性能の調査を容易に行うことを可能とする。
これにより、システムの性能劣化を検知した際には、その要因を細かな処理単位レベルで特定することが可能となり、解決する為に改善すべきプログラムをより細かな処理単位レベルで知ることが可能となる。
【００３４】
また、処理単位とハードウェア資源の対応関係を容易に把握することが可能となるため、システムの性能劣化を解決しようとする場合において、ソフトウェアの処理方法の改善とＩＴリソースの処理能力の向上を図るなど、システムを構成するソフトウェアとハードウェアの両面から、その要因をより詳細なレベルで特定し、改善すべきアイテム（修正すべき処理単位または増強すべきハードウェア資源など）を知ることが可能となる。結果として、アプリケーションのソースコードの書き換え・修正やハードウェア資源の増強を行って、アプリケーションの動作性能を迅速に最適化することができる。
【図面の簡単な説明】
【図１】バーチャルマシン環境の１つの例である．ＮＥＴ（登録商標）の構成を示す図である。
【図２】ソースコードからバイナリファイルの生成と、バイナリファイルからソースコードの復元を行う際の考え方を示した図である。
【図３】ソースコード復元処理のフローである。
【図４】レイジーワーカー法の準備プロセスの処理のフローである。
【図５】レイジーワーカー法のツリー生成プロセスの処理のフローである。
【図６】本発明の実施形態に従った装置のシステム構成を示す図である。
【図７】本発明の実施形態に従ったソフトウェアの機能構成の概念図である。
【図８】オブジェクトの動作性能の測定の処理のフローである。
【図９】オブジェクト配置情報の収集の処理のフローである。
【図１０】オブジェクトディプロイメントダイアグラム（フロー型）の表示例である。
【図１１】オブジェクトディプロイメントダイアグラム（ツリー型）の表示例である。
Claims (9)
- ネットワークで接続された複数のサーバにインストールされ、その一部または全てがバーチャルマシン環境下で協同動作する複数のアプリケーションに関して、該アプリケーションの動作性能を測定・分析し、その結果に基づき協同動作を最適化するためのシステム性能測定分析をコンピュータで実現させるためのプログラムであって、
該アプリケーションを構成する処理単位を解析・抽出し、処理単位間の呼び出し関係を解析・取得するアプリケーション解析ステップと、
該処理単位の動作性能を測定する動作性能測定ステップと、
該処理単位と、該処理単位が利用するハードウェア資源との対応関係を解析・取得するハードウェア資源特定ステップと、
該処理単位間の呼び出し関係、該処理単位の動作性能、該処理単位が利用するハードウェア資源を、共に表示する表示ステップと、
を備えることを特徴とするシステム性能測定分析プログラム。 - 前記表示手段の表示は、ユーザーが指定した任意の時間毎に更新され、更新時の処理単位の動作性能を示すことを特徴とする請求項１に記載のシステム性能測定分析プログラム。
- 前記動作性能測定手段は、処理単位の実行時間及びネットワークの通信時間を測定することを特徴とする請求項１に記載のシステム性能測定分析プログラム。
- 前記動作性能測定手段は、アプリケーションのソースコードを改変せずに動作性能を測定することを特徴とする請求項１に記載のシステム性能測定分析プログラム。
- 前記アプリケーション解析手段は、バーチャルマシン環境が提供するディスアセンブラ機能を利用してソースコードを復元するステップと、ソースコードを解析して処理単位の抽出並びに処理単位間の呼び出し関係を取得するステップによって構成されることを特徴とする請求項１に記載のシステム性能測定分析プログラム。
- 前記ハードウェア資源特定手段は、バーチャルマシン環境のメタデータを利用して、処理単位と処理単位が利用するハードウェア資源の対応関係を取得することを特徴とする請求項１に記載のシステム性能測定分析プログラム。
- 前記表示手段は、処理単位と処理単位が動作するハードウェア資源の対応関係を、視覚的に表現することを特徴とする請求項１に記載のシステム性能測定分析プログラム。
- ネットワークで接続された複数のサーバにインストールされ、その一部または全てがバーチャルマシン環境下で協同動作する複数のアプリケーションに関して、該アプリケーョンの動作性能を測定・分析し、その結果に基づき協同動作を最適化するためのシステム性能測定分析方法であって、
該アプリケーションを構成する処理単位を解析・抽出し、処理単位間の呼び出し関係を解析・取得するアプリケーション解析手段と、
該処理単位の動作性能を測定する動作性能測定手段と、
該処理単位と、該処理単位が利用するハードウェア資源との対応関係を解析・取得するハードウェア資源特定手段と、
該処理単位間の呼び出し関係、該処理単位の動作性能、該処理単位が利用するハードウェア資源を、共に表示する表示手段と、
を備えることを特徴とするシステム性能測定分析方法。 - ネットワークで接続された複数のサーバにインストールされ、その一部または全てがバーチャルマシン環境下で協同動作する複数のアプリケーションに関して、該アプリケーションの動作性能を測定・分析し、その結果に基づき協同動作を最適化するためのシステム性能測定分析装置であって、
該アプリケーションを構成する処理単位を解析・抽出し、処理単位間の呼び出し関係を解析・取得するアプリケーション解析手段と、
該処理単位の動作性能を測定する動作性能測定手段と、
該処理単位と、該処理単位が利用するハードウェア資源との対応関係を解析・取得するハードウェア資源特定手段と、
該処理単位間の呼び出し関係、該処理単位の動作性能、該処理単位が利用するハードウェア資源を、共に表示する表示手段と、
を備えることを特徴とするシステム性能測定分析装置。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003046120A JP2004264914A (ja) | 2003-02-24 | 2003-02-24 | システム性能測定分析装置 |
| PCT/JP2004/002011 WO2004075061A1 (ja) | 2003-02-24 | 2004-02-20 | システム性能測定分析装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003046120A JP2004264914A (ja) | 2003-02-24 | 2003-02-24 | システム性能測定分析装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004264914A true JP2004264914A (ja) | 2004-09-24 |
Family
ID=32905540
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003046120A Pending JP2004264914A (ja) | 2003-02-24 | 2003-02-24 | システム性能測定分析装置 |
Country Status (2)
| Country | Link |
|---|---|
| JP (1) | JP2004264914A (ja) |
| WO (1) | WO2004075061A1 (ja) |
Cited By (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2009031859A (ja) * | 2007-07-24 | 2009-02-12 | Nippon Telegr & Teleph Corp <Ntt> | 情報収集システムおよび情報収集方法 |
| JP2011238233A (ja) * | 2010-05-11 | 2011-11-24 | Computer Associates Think Inc | 動的計測を介してのカスタムコードの診断を効率化するためのメソッド呼び出しの検出 |
| CN102609351A (zh) * | 2012-01-11 | 2012-07-25 | 华为技术有限公司 | 用于分析系统的性能的方法、设备和系统 |
| JP2014509036A (ja) * | 2011-03-21 | 2014-04-10 | アマゾン・テクノロジーズ、インコーポレイテッド | メトリックデータに動的にタグを付けるための方法およびシステム |
| US9411616B2 (en) | 2011-12-09 | 2016-08-09 | Ca, Inc. | Classloader/instrumentation approach for invoking non-bound libraries |
| US10977032B2 (en) | 2017-12-25 | 2021-04-13 | Mitsubishi Electric Corporation | Assistance device, design assistance method and program |
| WO2022123763A1 (ja) * | 2020-12-11 | 2022-06-16 | 日本電信電話株式会社 | コールグラフ作成装置、コールグラフ作成方法及びプログラム |
| US20230221896A1 (en) * | 2022-01-13 | 2023-07-13 | Microsoft Technology Licensing, Llc | Performance evaluation of an application based on detecting degradation caused by other computing processes |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11222078B2 (en) | 2019-02-01 | 2022-01-11 | Hewlett Packard Enterprise Development Lp | Database operation classification |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS6435637A (en) * | 1987-07-31 | 1989-02-06 | Hitachi Ltd | Program tracing system |
| JPH0580992A (ja) * | 1991-09-20 | 1993-04-02 | Hokkaido Nippon Denki Software Kk | 手続き・関数関連図出力方式 |
| JPH05274132A (ja) * | 1992-03-25 | 1993-10-22 | Matsushita Electric Ind Co Ltd | プログラム解析装置 |
| JP2000122901A (ja) * | 1998-10-12 | 2000-04-28 | Hitachi Ltd | ジャーナル取得解析装置 |
| JP2000315198A (ja) * | 1999-05-06 | 2000-11-14 | Hitachi Ltd | 分散処理システム及びその性能モニタリング方法 |
| JP2001282759A (ja) * | 2000-03-31 | 2001-10-12 | Suntory Ltd | ウェブアプリケーションシステムに対する運用を行う運用機構およびウェブアプリケーションシステム |
| JP2002082926A (ja) * | 2000-09-06 | 2002-03-22 | Nippon Telegr & Teleph Corp <Ntt> | 分散アプリケーション試験・運用管理システム |
-
2003
- 2003-02-24 JP JP2003046120A patent/JP2004264914A/ja active Pending
-
2004
- 2004-02-20 WO PCT/JP2004/002011 patent/WO2004075061A1/ja active Application Filing
Cited By (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2009031859A (ja) * | 2007-07-24 | 2009-02-12 | Nippon Telegr & Teleph Corp <Ntt> | 情報収集システムおよび情報収集方法 |
| JP2011238233A (ja) * | 2010-05-11 | 2011-11-24 | Computer Associates Think Inc | 動的計測を介してのカスタムコードの診断を効率化するためのメソッド呼び出しの検出 |
| JP2014509036A (ja) * | 2011-03-21 | 2014-04-10 | アマゾン・テクノロジーズ、インコーポレイテッド | メトリックデータに動的にタグを付けるための方法およびシステム |
| US9411616B2 (en) | 2011-12-09 | 2016-08-09 | Ca, Inc. | Classloader/instrumentation approach for invoking non-bound libraries |
| CN102609351A (zh) * | 2012-01-11 | 2012-07-25 | 华为技术有限公司 | 用于分析系统的性能的方法、设备和系统 |
| CN102609351B (zh) * | 2012-01-11 | 2015-12-02 | 华为技术有限公司 | 用于分析系统的性能的方法、设备和系统 |
| US10977032B2 (en) | 2017-12-25 | 2021-04-13 | Mitsubishi Electric Corporation | Assistance device, design assistance method and program |
| WO2022123763A1 (ja) * | 2020-12-11 | 2022-06-16 | 日本電信電話株式会社 | コールグラフ作成装置、コールグラフ作成方法及びプログラム |
| JP7513116B2 (ja) | 2020-12-11 | 2024-07-09 | 日本電信電話株式会社 | コールグラフ作成装置、コールグラフ作成方法及びプログラム |
| US20230221896A1 (en) * | 2022-01-13 | 2023-07-13 | Microsoft Technology Licensing, Llc | Performance evaluation of an application based on detecting degradation caused by other computing processes |
| US11816364B2 (en) * | 2022-01-13 | 2023-11-14 | Microsoft Technology Licensing, Llc | Performance evaluation of an application based on detecting degradation caused by other computing processes |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2004075061A1 (ja) | 2004-09-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11659020B2 (en) | Method and system for real-time modeling of communication, virtualization and transaction execution related topological aspects of monitored software applications and hardware entities | |
| US10216527B2 (en) | Automated software configuration management | |
| US8234631B2 (en) | Method and system for tracing individual transactions at the granularity level of method calls throughout distributed heterogeneous applications without source code modifications | |
| Zhao et al. | lprof: A non-intrusive request flow profiler for distributed systems | |
| Lo et al. | Scenario-based and value-based specification mining: better together | |
| US8938489B2 (en) | Monitoring system performance changes based on configuration modification | |
| US8832665B2 (en) | Method and system for tracing individual transactions at the granularity level of method calls throughout distributed heterogeneous applications without source code modifications including the detection of outgoing requests | |
| US8555296B2 (en) | Software application action monitoring | |
| US7395458B2 (en) | Diagnostic instrumentation | |
| US10496517B2 (en) | System and method for providing runtime diagnostics of executing applications | |
| US20040039728A1 (en) | Method and system for monitoring distributed systems | |
| US10489264B2 (en) | Monitoring activity on a computer | |
| Jayaraman et al. | Compact visualization of Java program execution | |
| US7720950B2 (en) | Discovery, maintenance, and representation of entities in a managed system environment | |
| US10394531B2 (en) | Hyper dynamic Java management extension | |
| JP2007316905A (ja) | アプリケーションプログラムを監視する計算機システム及びその方法 | |
| US20160323362A1 (en) | Automatic task tracking | |
| JP2004264914A (ja) | システム性能測定分析装置 | |
| JP5803935B2 (ja) | 可用性分析装置及び可用性分析方法 | |
| US20130307854A1 (en) | Method and System for Visualising a System Model | |
| US11416376B2 (en) | Investigative platform for software application development and production | |
| US10949232B2 (en) | Managing virtualized computing resources in a cloud computing environment | |
| Cesario et al. | DyeVC: an approach for monitoring and visualizing distributed repositories | |
| US20080243782A1 (en) | Client collection membership evaluation | |
| Ortalo | Implementation of a Distributed Security Monitoring Tool: ESOPE |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040806 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20050405 |