JPWO2006046297A1 - 分析方法及び装置 - Google Patents

分析方法及び装置 Download PDF

Info

Publication number
JPWO2006046297A1
JPWO2006046297A1 JP2006542174A JP2006542174A JPWO2006046297A1 JP WO2006046297 A1 JPWO2006046297 A1 JP WO2006046297A1 JP 2006542174 A JP2006542174 A JP 2006542174A JP 2006542174 A JP2006542174 A JP 2006542174A JP WO2006046297 A1 JPWO2006046297 A1 JP WO2006046297A1
Authority
JP
Japan
Prior art keywords
delay time
server
storage unit
average
stored
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.)
Granted
Application number
JP2006542174A
Other languages
English (en)
Other versions
JP4180638B2 (ja
Inventor
菊池　慎司
慎司 菊池
横山　乾
乾 横山
明 竹山
明 竹山
健一 島▲崎▼
健一 島▲崎▼
高光 前田
高光 前田
宏司 石橋
宏司 石橋
正哉 進藤
正哉 進藤
光太郎 津呂
光太郎 津呂
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Publication of JPWO2006046297A1 publication Critical patent/JPWO2006046297A1/ja
Application granted granted Critical
Publication of JP4180638B2 publication Critical patent/JP4180638B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
    • 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
    • G06F11/3419—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 by assessing time
    • 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/3447—Performance evaluation by modeling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays
    • 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
    • G06F11/3419—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 by assessing time
    • G06F11/3423—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 by assessing time where the assessed time is active or idle time
    • 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/86—Event-based monitoring

Abstract

本発明は、複数のサーバを含むコンピュータ・システムのレスポンスに関する分析を行う分析方法であり、まず上記コンピュータ・システムから複数のサーバの各々のＣＰＵ使用率のデータを取得し、ＣＰＵ使用率格納部に格納する。そして、上記コンピュータ・システムにおいて生成される処理履歴データを取得し、当該コンピュータ・システムのユーザによるリクエスト頻度のデータを生成し、リクエスト頻度データ格納部に格納する。そして、ＣＰＵ使用率格納部に格納された各サーバのＣＰＵ使用率とリクエスト頻度格納部に格納されたリクエスト頻度とを用いて、各サーバにおける平均遅延時間を推定し、サーバ遅延時間格納部に格納する。このようにすることで分析対象のコンピュータ・システムを変更したり、余分なコストをかけずに分析を行うことができる。

Description

本発明は、コンピュータ・システムのレスポンスに関する分析技術に関する。
ネットワークサービスの発展に伴い、サービスを提供するためのシステムが複雑、大規模化してきている。多くのサービスが多数のサーバを組み合わせて提供されるようになってきている。このようなシステムにおいては、それぞれのサーバのリソースの利用状況がユーザのレスポンスにどのような影響を与えているかを把握することが非常に困難になってきている。
従来、複数のサーバからなるシステムにおいて、それぞれのサーバにおける遅延が、ユーザが体感するレスポンスタイムに対してどのくらいの割合を占めるかを調査するには下記の２つの方法が知られていた。すなわち、（１）各サーバ間で送受信するメッセージに認識用の特別なタグを付けておき、そのタグを用いて遅延を計測するものである。（２）各サーバ間で送受信されるメッセージをパケットキャプチャにより採取し、その情報を解析するものである。
しかし、（１）の方法では、既存のシステムやサービスに変更を加えなければならず、本機能の導入は容易ではない。また、（２）の方法では、パケットキャプチャのための高価な機器や大容量のストレージが必要である。さらに、セキュリティの観点からもパケットキャプチャは好まれない。
また、特開２００４−２１７５６号公報には、情報システム上で動作する一つまたは複数のアプリケーションについて、種々の利用状況下での各アプリケーションの応答性能を、限られた実験回数で効果的に評価する技術が開示されている。より具体的には、アプリケーションの種々の利用状況に対応した負荷投入実験を複数回行う際、アプリケーションの利用状況に関する数量と、アプリケーションの応答性能に関する数量と、ハードウェア・リソースの利用状況に関する数量と、ハードウェア・リソースの応答性能に関する数量を取得し、数量間の依存関係を記述する推定式群を作成する事により、推定式群を用いたアプリケーションの応答性能の評価を可能にするものである。しかし、この技術は「実験」が必要であり、通常の処理を行いながら分析を行うことはできない。
特開２００４−２１７５６号公報
従って、本発明の目的は、分析対象（以下監視対象とも呼ぶ）のコンピュータ・システムから容易に取得できる情報を用いて当該コンピュータ・システムのレスポンスに関する分析を実施するための技術を提供するものである。
本発明に係る分析方法は、複数のサーバを含むコンピュータ・システムのレスポンスに関する分析を行う分析方法であって、上記コンピュータ・システムから上記複数のサーバの各々のＣＰＵ使用率のデータを取得し、ＣＰＵ使用率格納部に格納するステップと、上記コンピュータ・システムにおいて生成される処理履歴データを取得し、上記コンピュータ・システムのユーザによるリクエスト頻度のデータを生成し、リクエスト頻度データ格納部に格納するステップと、ＣＰＵ使用率格納部に格納された各サーバのＣＰＵ使用率とリクエスト頻度格納部に格納されたリクエスト頻度とを用いて、各サーバにおける平均遅延時間を推定し、サーバ遅延時間格納部に格納する推定ステップとを含む。
このように、ＣＰＵ使用率及び処理履歴データといった容易に取得できるデータを用いて処理を行うため、導入コストを軽減し、セキュリティ面でも問題を生じさせずに分析処理を実施することができる。
さらに、上で述べた推定ステップが、ＣＰＵ使用率格納部に格納された各サーバのＣＰＵ使用率とリクエスト頻度格納部に格納されたリクエスト頻度とを用いて、各サーバの１リクエストあたりの平均消費ＣＰＵ時間を推定し、消費ＣＰＵ時間格納部に格納する消費ＣＰＵ時間推定ステップと、消費ＣＰＵ時間格納部に格納された各サーバの１リクエストあたりの平均消費ＣＰＵ時間とＣＰＵ使用率格納部に格納された各サーバのＣＰＵ使用率とを用いて、各サーバにおける平均遅延時間を推定し、サーバ遅延時間格納部に格納するサーバ遅延時間推定ステップとを含むようにしてもよい。
また、上で述べた消費ＣＰＵ時間推定ステップにおいて、予め指定された時間帯における各サーバのＣＰＵ使用率とリクエスト頻度とを用いて回帰分析を実施することにより、各サーバの１リクエストあたりの平均消費ＣＰＵ時間を推定するようにしてもよい。このように予め指定された時間帯に限定することにより、ユーザによるリクエストをあまり処理していない時間帯を除外することができ、計算精度を向上させることができるようになる。
さらに、上で述べたサーバ遅延時間推定ステップにおいて、サーバの１リクエストあたりの平均消費ＣＰＵ時間と当該サーバにおける平均遅延時間との関係を表す係数値を当該係数値を決定する要素であるＣＰＵ使用率の所定単位毎及びＣＰＵ個数毎に格納するマトリクス格納部を参照して該当する係数値を読み出し、当該係数値と上記サーバの１リクエストあたりの平均消費ＣＰＵ時間とから上記サーバにおける平均遅延時間を算出するようにしてもよい。上記係数値はＣＰＵ使用率とＣＰＵ個数の関数となっているので、都度計算することも可能であるが、実際的には計算量が増加するため、処理速度を上げるため上で述べたようにマトリクス格納部に格納しておく場合もある。
また、上記コンピュータ・システムに含まれる複数のサーバが、実行する業務種別に応じてカテゴリ分けされている場合、当該カテゴリ毎に平均遅延時間を推定するステップをさらに含むようにしても良い。例えば層（レイヤ：Layer）が規定されているようなコンピュータでは、当該層をカテゴリとして層毎の平均遅延時間を算出することもある。例えば、業務毎に問題点を抽出するためである。
さらに、サーバ遅延時間格納部に格納されたデータを用いて、コンピュータ・システム全体の平均遅延時間を推定し、システム遅延時間格納部に格納するステップをさらに含むようにしてもよい。
また、上記コンピュータ・システムにおける、ユーザによるリクエストに対するレスポンス時間の平均実測値を取得し、平均実測値格納部に格納するステップと、平均実測値格納部に格納された平均実測値とシステム遅延時間格納部に格納された上記コンピュータ・システム全体の平均遅延時間との差により、サーバ以外の箇所で発生した遅延時間を推定するステップとをさらに含むようにしてもよい。サーバ以外の箇所で発生した遅延時間がコンピュータ・システム全体の平均遅延時間より短い場合には、何らかの理由により推定が不適切であり、そのような場合を検出することも可能となる。
さらに、カテゴリ毎に、平均消費ＣＰＵ時間の総和とリクエスト頻度との相関係数を算出し、当該相関係数に基づきカテゴリ毎の平均遅延時間の信頼度を決定し、信頼度データ格納部に格納するステップと、信頼度データ格納部に格納されたカテゴリ毎の平均遅延時間の信頼度に基づき、カテゴリ毎の平均遅延時間を補正し、記憶装置に格納する補正ステップとをさらに含むようにしてもよい。例えば信頼度が高い平均遅延時間をそのまま使用し、信頼度が低い平均遅延時間については補正を大きく加えるようにする。
さらに、上で述べた補正ステップが、カテゴリ毎の平均遅延時間を信頼度の高い順にソートするステップと、信頼度の高い順に前記カテゴリ毎の平均遅延時間を累積してゆき、累積された平均遅延時間が遅延実測値未満であって最大の値を有することとなる信頼度の順番を特定するステップと、特定された信頼度の順番の次の順番の遅延時間を、遅延実測値と信頼度の高い順にカテゴリ毎の平均遅延時間を特定された信頼度の順番まで累積することにより得られる値との差に補正するステップとを含むようにしてもよい。
また、リクエスト頻度が例えば試験的に変更された場合、当該変更後のリクエスト頻度に応じて各サーバのＣＰＵ使用率を変更し、記憶装置に格納するステップと、記憶装置に格納された変更後の各サーバのＣＰＵ使用率を用いて、各サーバにおける平均遅延時間を推定し、記憶装置に格納するステップと、サーバ遅延時間格納部及び記憶装置に格納された変更前後の各サーバの平均遅延時間を比較可能な態様で出力するステップとをさらに含むようにしてもよい。リクエスト頻度の変動に対して遅延時間がどのように変化するかを知ることができる。
また、ＣＰＵ数が例えば試験的に変更された場合、当該変更後のＣＰＵ数に応じて各前記サーバのＣＰＵ使用率を変更し、記憶装置に格納するステップと、記憶装置に格納された変更後の各サーバのＣＰＵ使用率と変更後のＣＰＵ数とを用いて、各サーバにおける平均遅延時間を推定し、記憶装置に格納するステップと、サーバ遅延時間格納部及び記憶装置に格納された変更前後の各サーバの平均遅延時間を比較可能な態様で出力するステップとをさらに含むようにしてもよい。ＣＰＵ数を例えば増加させた場合に遅延時間がどの程度減少するか試すことができ、その効果から投資の是非を判断できるようになる。
また、サーバ数が変更された場合、当該変更後のサーバ数に応じて各サーバの１リクエストあたりの平均消費ＣＰＵ時間を算出し、記憶装置に格納するステップと、ＣＰＵ個数と記憶装置に格納された変更後の各サーバの１リクエストあたりの平均消費ＣＰＵ時間とを用いて、変更後における各サーバのＣＰＵ使用率を算出し、記憶装置に格納するステップと、記憶装置に格納された変更後の各サーバの１リクエストあたりの平均消費ＣＰＵ時間と変更後における各サーバのＣＰＵ使用率とを用いて、変更後における各サーバの平均遅延時間を推定し、記憶装置に格納するステップとをさらに含むようにしてもよい。サーバ数を例えば増加させた場合に遅延時間がどの程度減少するかを試すことができ、その効果から投資の是非を判断できるようになる。
さらに、記憶装置に格納された変更後における各サーバの平均遅延時間と変更後のサーバ数とを用いて、コンピュータ・システムに含まれる複数のサーバを実行する業務種別に応じて分けることにより規定されるカテゴリ毎の平均遅延時間を推定し、記憶装置に格納するステップをさらに含むようにしてもよい。
上で述べた分析方法をコンピュータに実行させるためのプログラムを作成することができ、このプログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークなどを介してデジタル信号として配信される場合もある。尚、中間的な処理結果はメモリ等の記憶装置に一時保管される。
図１は、本発明の原理を説明するための図である。 図２は、本発明の原理を説明するための図である。 図３は、本発明の実施例におけるシステム全体を説明するための図である。 図４Ａは、本発明の実施例における遅延時間分析装置の機能ブロックである。 図４Ｂは、本発明の実施例における遅延時間分析装置の機能ブロックである。 図５は、本発明の実施例におけるメインの処理フローを示す図である。 図６は、取得データの一例を示す図である。 図７は、（ａ）及び（ｂ）は、回帰計算を説明するための図である。 図８は、ビジネス時間に回帰計算の対象を限定する理由を説明するための図である。 図９は、信頼度算出処理の処理フローを示す図である。 図１０は、信頼度に応じた遅延時間の補正処理の処理フローを示す図である。 図１１（ａ）乃至（ｃ）は、信頼度に応じた遅延時間の補正処理の具体例を説明するための図である。 図１２は、リクエスト頻度変動時の遅延時間変化の推定処理の処理フローを示す図である。 図１３は、ＣＰＵ数変動時の遅延時間変化の推定処理の処理フローを示す図である。 図１４は、サーバ数変動時の遅延時間変化の推定処理の処理フローを示す図である。 図１５は、処理結果のテーブル化の一例を示す図である。 図１６は、処理結果のグラフ化の一例を示す図である。 図１７は、コンピュータの機能ブロック図である。
［本発明の原理］
Ａ．Ｗｅｂシステムモデルにおける平均遅延時間の理論値Ｘ^（Ｘの上に^を付した記号をＸ^とも示すものとする）の導出
Ａ−１．単一サーバの遅延時間のモデル化
まず、図１を用いて複数のＣＰＵを有する単一サーバＳにおける平均遅延時間を導出することを考える。図１に示すサーバＳはＣＰＵ＿１からＣＰＵ＿ＣまでのＣ個のＣＰＵを有し、外部からリクエスト頻度λ（req/sec）で入力されたリクエストは、待ち行列Ｓwに入れられた後にＣ個のＣＰＵで処理される。この際、ＣＰＵの使用率をρ（％）とする。そして、Ｍ／Ｍ／ｓ待ち行列モデルの解析結果より、サーバＳにおけるリクエストの平均滞在時間Ｔ（Ｃ，λ，ρ）は、以下のようになる。
Figure 2006046297
（１）式乃至（３）式より、サーバＳにおける平均滞在時間Ｔ（Ｃ，λ，ρ）は、以下の関係が成立する。なお、αはサーバＳに到達するリクエストの割合を表す。
Figure 2006046297
Ａ−２．第Ｎ層のサーバ層における遅延時間のモデル化
ここでは、単一サーバにおける遅延モデルを用いて、複数層における特定の単一層におけるリクエストの平均遅延時間を求める。前提となるシステム・モデルを図２に表す。第１層には、Ｍ1個のサーバＳ(1,1)、Ｓ(1,2)、．．．Ｓ(1,M1)が存在しており、第２層には、Ｍ2個のサーバＳ(2,1)、Ｓ(2,2)、．．．Ｓ(2,M2)が存在しており、さらに第Ｎ層には、ＭN個のサーバＳ(N,1)、Ｓ(N,2)、．．．Ｓ(N,MN)が存在している。また、αnは第ｎ層に到達するリクエストの割合を表し、各層におけるサーバにリクエストが均等に振り分けられ、本システムにλall（req/sec）というリクエスト頻度でリクエストが入力されると、第１層の各サーバには、λall／Ｍ1のリクエストが入力され、第１層から離脱するリクエストは（１−α2）λallであり、第２の層の各サーバには、α2λall／Ｍ2というリクエストが入力され、第２層から離脱するリクエストは（α2−α3）λallであり、第Ｎ−１層から離脱するリクエストは（αN-1−αN）λallであり、第Ｎ層の各サーバには、αNλall／ＭNのリクエストが入力され、第Ｎ層から出力されるリクエストはαNλallとなる。なお、１≦ｎ≦Ｎ、１≦ｍ≦Ｍnとする。
各層には、例えばユーザに対するフロントエンドとして用いられるＷｅｂサーバや、リクエストを動的に処理するためのアプリケーションサーバ等、それぞれ異なる役割が割り当てられている。
そして、第ｎ層のサーバＳ(n,m)に入ってくるリクエスト頻度をλ(n,m)とすると、サーバＳ(n,m)における平均遅延時間はＴ（Ｃ(n,m)，λ(n,m)，ρ(n,m)）と表すことができる。また、第ｎ層に入ってくるリクエストの総量はαnλallであり、それらがＭn個のサーバに均等に振り分けられるとすると、以下の式が成り立つ。
Figure 2006046297
リクエストは各サーバに均等に振り分けられるので、第ｎ層における全リクエストの平均遅延時間Ｗnは、第ｎ層に存在する全てのサーバの平均遅延時間の平均をとったものになる。
Figure 2006046297
ここで、（１）式乃至（４）式を用いると、Ｗnは下記のようになる。
Figure 2006046297
ここで表記を簡略化するためＨnを下記のように定義する。
Figure 2006046297
Ａ−３．システム全体における遅延時間のモデル化
ここでは、各層における遅延のモデルを用いて、システム全体における遅延時間のモデル化を行う。全てのリクエストのうち、第１層から第ｎ層までのサーバを利用した後、システムから離脱するリクエストの数Ｒnは、下記のようになる。
Figure 2006046297
また、第１層から第ｎ層までのサーバを利用した後、システムから離脱するリクエストの平均遅延Ｌnは、下記のようになる。
Figure 2006046297
また、定義より下記の関係が成り立つ。
Figure 2006046297
１リクエストあたりの平均遅延時間Ｘ^は、第１層から第ｉ層までのサーバを利用してからシステムを離脱するリクエストについて、それらの遅延と、全リクエストに対する割合の積で表すことができるので、下記のようになる。
Figure 2006046297
上記の結果より、全リクエストの平均遅延時間を考えた場合、Ｈnは各層で発生する遅延を表しており、その総和Ｘ^は、全リクエストに対するシステム全体での平均遅延時間を表していると言える。
［具体的処理］
図３に監視対象システム１００及び遅延分析装置１２０を含むシステムの概要を示す。監視対象システム１００は、ネットワークに接続されており、図２に示したようにＮ層（図３では説明を簡略化するため２層）の構成となっている。各層には、負荷分散装置１０１及び１０２が設けられており、当該負荷分散装置は、各層のサーバ群Ｓ(1,1)，Ｓ(1,2)及びＳ(1,M1)並びにサーバ群Ｓ(N,1)，Ｓ(N,2)及びＳ(N,MN)に対してほぼ均等にリクエストを分配する。第１層のサーバには、サーバログ１１１ａが設けられており、リクエストに対する処理を実施するとそのログデータが格納されるようになっている。また、各サーバには、ＣＰＵ（Central Processing Unit）使用率取得部１１２ａ及び１１２ｂが設けられており、本実施例ではＣＰＵ使用率を％単位で取得するようになっている。このＣＰＵ使用率取得部１１２ａ及び１１２ｂは、ＵＮＩＸ（登録商標） ＯＳ（Operating System）等の場合にはｓａｒ、ｍｐｓｔａｔ、ｉｏｓｔａｔなどのコマンドで実行される一般的なツールであって、近年のＯＳには同様の機能を有しているものが多い。
遅延分析装置１２０は、監視対象システム１００に接続されており、サーバログ１１１ａに格納されたログデータ及びＣＰＵ使用率を用いて処理を行う。このように従来とは異なり、監視対象システム１００内に特別の仕組みを組み込むことがないので遅延分析装置１２０の導入は容易であり、さらに監視対象システム１００内で処理される全てのパケットを解析するものでもないので、大容量のストレージを用いる必要は無く、セキュリティ上の問題も生じにくくなっている。遅延分析装置１２０は、表示装置、マウス、キーボードその他の入出力部１２１に接続されている。
図４Ａ及び図４Ｂに遅延分析装置１２０の機能ブロック図を示す。遅延分析装置１２０は、リクエスト頻度取得部１２０１と、ＣＰＵ使用率取得部１２０２と、ログデータ格納部１２０３と、リクエスト頻度格納部１２０４と、遅延実測値格納部１２０５と、ＣＰＵ使用率格納部１２０６と、システム構成データ格納部１２０７と、ＣＰＵ時間算出部１２０８と、ＣＰＵ時間格納部１２０９と、性能予測処理部１２１３と、サーバ遅延時間算出部１２１０と、Ｇテーブル格納部１２１１と、サーバ遅延時間格納部１２１４と、層遅延時間算出部１２１５と、層遅延時間格納部１２１６と、システム遅延時間算出部１２１７と、システム遅延時間格納部１２１８と、残余遅延時間算出部１２１９と、残余遅延時間格納部１２２０と、信頼度算出部１２２１と、信頼度格納部１２２２と、遅延時間補正部１２２３と、補正遅延時間格納部１２２４とを有する。
リクエスト頻度取得部１２０１は、監視対象システム１００のサーバログ１１１ａからログデータを受信しログデータ格納部１２０３に格納すると共に、入出力部１２１からの入力データに従ってログデータ格納部１２０３に格納されたログデータを処理してリクエスト頻度（req/sec）を算出し、リクエスト頻度格納部１２０４に格納する。また、ログデータ格納部１２０３に格納されたログデータを処理して平均遅延実測値を算出し、当該平均遅延実測値を遅延実測値格納部１２０５に格納する。ＣＰＵ使用率取得部１２０２は、監視対象システム１００のＣＰＵ使用率取得部１１２からＣＰＵ使用率のデータを取得し、当該データをＣＰＵ使用率格納部１２０６に格納する。
ＣＰＵ時間算出部は、リクエスト頻度格納部１２０４とＣＰＵ使用率格納部１２０６とシステム構成データ格納部１２０７とを参照して１リクエストあたりの消費ＣＰＵ時間を算出し、算出されたデータをＣＰＵ時間格納部１２０９に格納する。サーバ遅延時間算出部１２１０は、ＣＰＵ時間格納部１２０９とＧテーブル格納部１２１１とＣＰＵ使用率格納部１２０６とを参照してサーバ毎の遅延時間を算出し、算出されたデータをサーバ遅延時間格納部１２１４に格納する。なお、サーバ遅延時間算出部１２１０は、Ｇテーブル格納部１２１１を参照しない場合には、リクエスト頻度格納部１２０４とシステム構成データ格納部１２０７を参照することもある。
さらに層遅延時間算出部１２１５は、サーバ遅延時間格納部１２１４とシステム構成データ格納部１２０７とを参照して層毎の遅延時間を算出し、算出されたデータを層遅延時間格納部１２１６に格納する。システム遅延時間算出部１２１７は、層遅延時間格納部１２１６とシステム構成データ格納部１２０７とを参照してシステム全体の遅延時間を算出し、算出したデータをシステム遅延時間格納部１２１８に格納する。残余遅延時間算出部１２１９は、遅延実測値格納部１２０５とシステム遅延時間格納部１２１８とを参照してサーバ以外の他の装置により消費された残余の遅延時間を算出し、算出されたデータを残余遅延時間格納部１２２０に格納する。
また信頼度算出部１２２１は、残余遅延時間格納部１２２０とシステム構成データ格納部１２０７と遅延実測値格納部１２０５とリクエスト頻度格納部１２０４とＣＰＵ使用率格納部１２０６と層遅延時間格納部１２１６とを参照し、サーバ以外の他の装置により消費された残余の遅延時間が０未満である場合、各層の遅延時間について信頼度を算出し、算出された信頼度データを信頼度格納部１２２２に格納する。遅延時間補正部１２２３は、層遅延時間格納部１２１６と信頼度格納部１２２２とを参照して層毎の遅延時間を補正し、補正された遅延時間のデータを補正遅延時間格納部１２２４に格納する。
性能予測処理部１２１３は、ＣＰＵ使用率格納部１２０６とシステム構成データ格納部１２０７とＣＰＵ時間格納部１２０９とリクエスト頻度格納部１２０４とを用いて処理を行う。
なお、入出力部１２１は、遅延分析装置１２０内の格納部内のデータを表示装置などに出力することができるようになっている。
次に図５乃至図１６を用いて図３並びに図４Ａ及び図４Ｂに示したシステムの処理内容について説明する。まず、リクエスト頻度取得部１２０１は、監視対象システム１００のサーバログ１１１ａからログデータを取得してログデータ格納部１２０３に格納し、ＣＰＵ使用率取得部１２０２は監視対象システム１００のＣＰＵ使用率取得部１１２からＣＰＵ使用率のデータを受信し、ＣＰＵ使用率格納部１２０６に格納する（図５：ステップＳ１）。
ログデータ格納部１２０３に格納されるログデータの一例を以下に示す。
「192.168.164.108 - - [14/Sep/2004:12:27:50 +0900] "GET /~hoge/SSSS/SSSS__20040816.pdf HTTP/1.1" 200 147067 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)" 0.053」（Windowsは登録商標）
これは、Ａｐａｃｈｅ Ｗｅｂサーバにおいてカスタムログ形式で採取された１つのログの一例である。一般的には監視対象システム１００に含まれるＷｅｂサーバの/var/log/httpd/ディレクトリ配下などにサーバログ１１１ａとして格納されている。この第１項「192.168.164.108」はアクセス元クライアントのＩＰアドレスを表す。第２項及び第３項は省略されている。第４項「 [14/Sep/2004:12:27:50 +0900]」はアクセス時刻を表している。第５項「"GET /~hoge/SSSS/SSSS__20040816.pdf HTTP/1.1"」はアクセス内容を示す。第６項「200」はステータス（ここでは正常）を表す。第７項「147067」は送受信バイト数を表す。第８項「"-"」はリクエストされたＵＲＬパスを表す。第９項「"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)"」はアクセス元クライアントが使用しているブラウザを表す。第１０項「0.053」は、リクエストを扱うのにかかった時間（sec）を表す。
次に、入出力部１２１は、分析対象期間及びビジネス時間帯の設定入力を受け付け、例えばメインメモリ等の記憶装置に格納する（ステップＳ３）。ビジネス時間帯とは、ユーザからのリクエスト以外の処理にサーバが費やすＣＰＵ時間が少ない時間帯をいう。ビジネス時間帯を指定することにより、夜間など、リクエストが少ないときに多量のＣＰＵ時間がサーバで消費されることに起因する推定誤差を減らすことができる。
そして、リクエスト頻度取得部１２０１は、ログデータ格納部１２０３から指定分析対象期間及びビジネス時間帯におけるログデータを読み出し、例えば１時間毎にいくつのリクエストが処理されたかカウントし且つカウント値を３６００秒（＝１時間）で割ることにより１秒あたりのリクエスト頻度λ（req/sec）を算出し、リクエスト頻度格納部１２０４に格納する。また、リクエスト頻度取得部１２０１は、例えば１時間毎に全てのリクエストを取り扱うのにかかった時間を加算してリクエスト数で除することにより平均遅延実測値を算出し、遅延実測値格納部１２０５に格納する。さらに、ＣＰＵ使用率格納部１２０６は、ＣＰＵ使用率格納部１２０６に格納されたＣＰＵ使用率のデータに基づき、１時間毎に各サーバＳ(n,m)の平均ＣＰＵ使用率ρi (n,m)を算出し、ＣＰＵ使用率格納部１２０６に格納する（ステップＳ５）。１つのサーバが複数のＣＰＵを有する場合には、その複数のＣＰＵの平均ＣＰＵ使用率を算出して当該サーバのＣＰＵ使用率とする。なお、平均ＣＰＵ使用率ρi (n,m)におけるｉはｉ番目の単位時間（ここでは１時間毎）を表す。また、以下「平均」という文字を省略することもある。
ここまでの処理結果をまとめると、例えば図６に示すようになる。図６の例では、各時間帯につき、単位時間番号ｉと、リクエスト頻度λi（req/sec）と、遅延実測値Ａiと、ＣＰＵ使用率ρi (1,1)、ρi (1,2)、ρi (2,1)、ρi (3,1)とが示されている。
次に、ＣＰＵ時間算出部１２０８は、リクエスト頻度格納部１２０４とＣＰＵ使用率格納部１２０６とシステム構成データ格納部１２０７とを参照して、１リクエストあたりの消費ＣＰＵ時間を算出し、ＣＰＵ時間格納部１２０９に格納する（ステップＳ７）。各サーバで発生する遅延時間を算出するためには、まず、システム全体に対して外部から入ってくるリクエストλi（req/sec）に対して、各サーバで１リクエストあたりどれだけのＣＰＵ時間が消費されているか求める必要がある。しかし、単純に時間ｉにおけるサーバＳ(n,m)のＣＰＵ使用率ρi (n,m)とＣＰＵの個数Ｃ(n,m)との積をリクエスト頻度λiで割って、１リクエストあたりの平均消費ＣＰＵ時間を
Figure 2006046297
 として算出すると、以下のような不都合が生ずる。すなわち、サーバにおいては、通常、リクエストの処理以外にもシステムの維持等によって若干のＣＰＵ時間が消費されている。リクエスト頻度が極端に小さい場合、このようなＣＰＵ時間の割合が相対的に大きくなるため、１リクエストあたりの消費ＣＰＵ時間を大きく見積もってしまい、誤差の原因となる恐れがある。すなわち、図７（ａ）のように横軸をリクエスト頻度、縦軸をＣＰＵ使用率とすると、（１２）式をそのまま解釈するとリクエストがなければＣＰＵ使用率も０となるはずである。そこで、原点と各測定点とを結ぶ直線の傾きを１リクエストあたりの消費ＣＰＵ時間とすると、大きなバラツキが生ずる。
この問題を解決するために、１リクエストあたりの消費ＣＰＵ時間１／μ(n,m)が以下のように表されるものと仮定する。
Figure 2006046297
 そして１リクエストあたりの消費ＣＰＵ時間１／μ(n,m)を、回帰分析によって求め、以下の式で近似するものとする。
Figure 2006046297
図７（ｂ）に示すように、回帰計算を行えば、各測定点を結ぶ回帰直線の傾きを、１リクエストあたりの消費ＣＰＵ時間として算出することができ、より実際に近い値を得ることができる。
なお、回帰計算を行う際には、ユーザが指定したビジネス時間帯内のデータのみを用いる。これは、分析対象期間の全データを利用した場合、リクエストの小さい夜間にバッチ処理などが実行され、多量のＣＰＵ時間が消費されるなどの事象が発生すると、リクエスト数が小さい場合の方が、リクエスト数が多い場合よりＣＰＵ使用率が高いという現象が発生する。そうすると、回帰計算を用いた１リクエストあたりの消費ＣＰＵ時間推定において大きな誤差を生じさせる可能性がある。これは図８に示すように、夜間バッチ処理による測定点を黒丸で表すと、リクエスト頻度が小さいにもかかわらずＣＰＵ使用率が高くなるため縦軸の上の方にプロットされてしまい、日中のリクエスト処理についての測定値（白丸で表す）と合わせて回帰計算を行うと、実線のような回帰直線が得られてしまう場合がある。一方、日中のリクエスト処理についての測定値のみを用いれば点線のような傾きが正の正しい回帰直線が得られる。従って、ビジネス時間帯にデータを絞る必要がある。
上で述べた回帰計算をより詳しく述べると、分析対象期間のデータのうち、ユーザの指定したビジネス時間帯に該当するデータ（ＣＰＵ使用率ρ(n,m)，システム構成データであるＣＰＵ個数Ｃ(n,m)，リクエスト頻度λi）に対して、（１３）式のような直線を引いた場合に、偏差が最も少なくなるように最小二乗法により傾き１／μ(n,m)と切片α(n,m)を計算し、ＣＰＵ時間格納部１２０９に格納する。但し、α(n,m)が負となるときは、傾きを過大に見積もっている可能性が高いので、切片０として、再度以下の直線として回帰分析を実施して１／μ(n,m)を求める。
Figure 2006046297
また、傾き１／μ(n,m)が負となるときには、そのサーバでの１リクエストあたりの平均遅延時間は解析不能であると判断し、解析不能を表すコードをＣＰＵ時間格納部１２０９に格納する。このようなコードが格納されると、そのサーバが含まれる層で発生する平均遅延時間についても解析不能となる。
図５の説明に戻って、次にサーバ遅延時間算出部１２１０は、ＣＰＵ使用率格納部１２０６とシステム構成データ格納部１２０７とＣＰＵ時間格納部１２０９とＧテーブル格納部１２１１とを参照して、各サーバで発生する１リクエストあたりの平均遅延時間を算出し、算出された値をサーバ遅延時間格納部１２１４に格納する（ステップＳ９）。ｉ番目の単位時間において、各サーバで発生する１リクエストあたりの平均遅延時間Ｔi (n,m)は、以下の式で与えられる。
Figure 2006046297
 但し、ρ＝０のとき、Ｇ（Ｃ，０）＝１とする。
ここで１／μ(n,m)は１リクエストあたりの消費ＣＰＵ時間を表しているが、これは負荷が０％のときに発生する平均遅延時間に等しい。そして、負荷がρの時には、遅延が負荷０％のときのＧ（Ｃ，ρ）倍になることを意味している。
Ｇ（Ｃ，ρ）については、（３）式に示したように、サーバのＣＰＵ個数とＣＰＵ使用率によって算出される。但し、（３）式をそのまま計算すると比較的時間がかかるので、分析の粒度が決まっている場合には、サーバのＣＰＵ数及びＣＰＵ使用率を変動させ、事前に算出することも可能である。例えば、分析の粒度が、ＣＰＵ使用率においては１％単位で十分であり、且つ想定される１サーバあたりのＣＰＵの個数が５０個以下である場合、ＣＰＵ使用率が０乃至９９％（１％刻み）において、サーバのＣＰＵが１乃至５０個のそれぞれの場合におけるＧ（Ｃ，ρ）を予め算出しておき、それを１００×５０のマトリクスとしてＧテーブル格納部１２１１に格納しておく。そうすれば、システム構成データ格納部１２０７からＣＰＵ個数を取得し、ＣＰＵ使用率格納部１２０６からＣＰＵ使用率を取得し、Ｇデーブル格納部１２１１からＧ（Ｃ，ρ）の値を取得することができる。
最終的には、（１４）式に従って各サーバで発生する１リクエストあたりの平均遅延時間Ｔi (n,m)（以下、略して各サーバの平均遅延時間ともいう）が算出され、サーバ遅延時間格納部１２１４に格納される。
次に、層遅延時間算出部１２１５は、サーバ遅延時間格納部１２１４とシステム構成データ格納部１２０７とを参照して、各層における遅延時間Ｌi nを算出し、層遅延時間格納部１２１６に格納する（ステップＳ１１）。各層における遅延時間Ｌi nは、各層のサーバの平均遅延時間の和であり、以下のように表される。Ｍnについてはシステム構成データ格納部１２０７から取得する。
Figure 2006046297
そして、システム遅延時間算出部１２１７は、層遅延時間格納部１２１６とシステム構成データ格納部１２０７とを参照して、システム全体の遅延時間Ｄiを算出し、システム遅延時間格納部１２１８に格納する（ステップＳ１３）。システム全体の遅延時間Ｄiは、各層ｎにおける遅延時間Ｌi nの和であり、以下のように表される。Ｎについてはシステム構成データ格納部１２０７から取得する。
Figure 2006046297
その後、残余遅延時間算出部１２１９は、遅延実測値格納部１２０５とシステム遅延時間格納部１２１８とを参照して、サーバ以外の箇所でかかる遅延時間Ｅiを算出し、残余遅延時間格納部１２２０に格納する（ステップＳ１５）。遅延時間Ｅiは、システム全体の遅延時間Ｄiと遅延実測値Ａiの差であって、以下のように算出される。
Figure 2006046297
Ａi＜Ｄiということは、上で述べたような推定結果が適切ではないということであり、そのような場合にはＥi＝０に設定される。
そして主にＥi＝０となった場合に遅延時間の補正を行うため、信頼度算出部１２２１は、残余遅延時間格納部１２２０と層遅延時間格納部１２１６とシステム構成データ格納部１２０７とリクエスト頻度格納部１２０４とＣＰＵ使用率格納部１２０６と遅延実測値格納部１２０５とを参照して、各層の平均遅延時間の信頼度を算出処理を実施し、処理結果を信頼度格納部１２２２に格納する（ステップＳ１７）。この処理については図９を用いて説明する。まず、信頼度算出部１２２１は、第ｎ層の消費ＣＰＵ時間の総和ρとリクエスト頻度λとの間の相関係数を各層ｎの平均遅延時間の初期信頼度Ｒi nとして算出し、信頼度格納部１２２２に格納する（ステップＳ３１）。ｃｏｒｒｅｌを相関係数を求める関数とすると、以下のような式に従って信頼度Ｒi nを算出する。
Figure 2006046297
 （１５）式におけるｃｏｒｒｅｌ関数の第１項が第ｎ層における消費ＣＰＵ時間の総和である。なお、相関係数も後の計算で用いられるため、各層につき保持しておく。
そして相関係数Ｒi nが負であるか判断する（ステップＳ３３）。相関係数＜０であれば信頼度Ｒi n＝０と設定する（ステップＳ３７）。消費ＣＰＵ時間とリクエスト頻度の間には正の相関があることを仮定しており、負の相関に意味が無いためである。一方、相関係数≧０であれば、平均遅延実測値Ａiよりシステム全体の推定遅延時間Ｄiが長いか判断する（ステップＳ３５）。Ｄi＞Ａiが成り立つ場合には、あり得ない推定がなされており算出された遅延時間自体の信頼性が低いため、ステップＳ３７に移行する。すなわち、信頼度Ｒi n＝０と設定する。一方、Ｄi≦Ａiであれば、ステップＳ３１で算出された相関係数をそのまま信頼度として使用する。
図５の説明に戻って、遅延時間補正部１２２３は、信頼度格納部１２２２と層遅延時間格納部１２１６とを参照して、信頼度に応じた遅延時間の補正を行い、補正遅延時間格納部１２２４に格納する（ステップＳ１９）。なお、Ａi≧Ｄiであれば、本ステップはスキップされる。この処理については図１０を用いて説明する。まず、遅延時間補正部１２２３は、層遅延時間格納部１２１６と信頼度格納部１２２２とを参照して、各層の遅延時間を信頼度の高い順にソートし、補正遅延時間格納部１２２４に格納する（ステップＳ４１）。なお、信頼度が０の層が複数ある場合は、それらの相関係数の高い順にソートする。
そして、ソート結果に従って信頼度の高い順に層の遅延時間を加算し、当該加算値が平均遅延実測値未満の最大となるような信頼度の順番Ｂを特定する（ステップＳ４３）。ここでＰx＝ｎを、第ｎ層の信頼度Ｒi nの高さが上からｘ番目であるものとする。そうすると、Ｒi Px＞Ｒi Px+1が常に成り立つ。そしてステップＳ４３では以下の式を満たす最大のｙを求める。これがＢである。
Figure 2006046297
このようにして求められた信頼度Ｂ番目の層の遅延時間までについては補正は不要である。従って、信頼度Ｂ＋１番目の層の遅延時間を以下のように補正する（ステップＳ４５）。すなわち、第ＰB+1層の推定遅延時間Ｌi Px+1について補正を行い、その結果をＬ'i Px+1とする。補正結果及び補正不要の層（信頼度Ｂ番目までの層）の遅延時間は、補正遅延時間格納部１２２４に格納される。
Figure 2006046297
 この式は、遅延実測値と、各層の信頼度のうち、信頼度が高い方からＢ＋１番目までの遅延時間（推定平均値）の総和とが等しくなるように信頼度Ｂ＋１番目の層の遅延時間を補正を行う。
また、信頼度Ｂ＋１番目の層の信頼度を以下のように補正する（ステップＳ４７）。すなわち、第ＰB+1層の信頼度Ｒi Px+1について補正を行い、その結果をＲ'i Px+1とする。補正結果及び補正不要の層（信頼度Ｂ番目までの層）の信頼度データは、補正遅延時間格納部１２２４に格納される。
Figure 2006046297
 この式は、補正前の遅延時間と補正後の遅延時間の差が小さいほど、信頼度が高くなるように信頼度を補正している。
さらに、信頼度Ｂ＋２番目以降の層の遅延時間及び信頼を以下のように補正する（ステップＳ４９）。補正結果は、補正遅延時間格納部１２２４に格納される。
Ｌ'i Pn＝０ （ｎ＞Ｂ＋１）
Ｒ'i Pn＝０ （ｎ＞Ｂ＋１）
このような補正処理の具体例を図１１（ａ）乃至（ｃ）を用いて説明する。まず、図１１（ａ）に遅延時間推定結果及び実測結果を示す。本例における監視対象システム１００の第１層はＷｅｂサーバであり、第２層はアプリケーションサーバであり、第３層はＤＢサーバである。ここで、第１層の推定遅延時間は１５０ｍｓｅｃであり、相関係数０．９で信頼度０である。第２層の推定遅延時間は６０ｍｓｅｃであり、相関係数０．８５で信頼度０．８５である。第３層の推定遅延時間は３０ｍｓｅｃであり、相関係数０．６で信頼度０．６である。なお、平均遅延実測値が１００ｍｓｅｃである。
そして、ステップＳ４１でソートすると、図１１（ｂ）に示すように、各層は、第２層、第３層、第１層の順番に並べられ、システム全体の遅延時間は明らかに平均遅延実測値を超えており、システム全体の推定遅延時間は第１層の途中で超えてしまっている。
従って、図１１（ｃ）に示すように、第２層及び第３層については、遅延時間及び信頼度についてはそのまま用い、第１層の推定遅延時間については平均遅延実測値と第２層及び第３層の遅延時間の和との差に減らされ、１０ｍｓｅｃとなる。また信頼度も０．０６（＝１０／１５０）に補正されている。
このようにして推定値を実測値に合わせるような補正がなされる。
図５の説明に戻って、入出力部１２１は、出力処理を実施する（ステップＳ２１）。入出力部１２１が出力するデータは、（１）各サーバで発生する遅延時間の推定値Ｔi (n,m)、（２）各層で発生する遅延時間の推定値Ｌi n、（３）システム全体で発生する遅延時間の推定値Ｄi、（４）サーバ以外の箇所の遅延時間Ｅi、（５）各層の遅延時間の信頼度などである。信頼度の場合、値そのものを出力しても良いし、信頼度Ｒi nを例えば以下の３つのレベルに分類し、分類結果を出力するようにしても良い。すなわち、Ｒi n＞０．７であれば信頼度「高」、０．７≧Ｒi n＞０．３であれば信頼度「中」、０．３≧Ｒi nであれば信頼度「低」である。
上で述べたような信頼度の高中低の分類は、相関係数における相関の強さの判断に一般的に用いられている値である。すなわち、一般的に、相関係数の絶対値が０．７以上であれば、２つのパラメータの間に強い相関があると判断され、０．３乃至０．７程度であれば、弱い相関があると判断され、０．３以下であればほとんど無相関であるとされている。これは、相関係数の二乗が変動の説明率であることに起因している。そして、相関係数が０．７のとき、説明率は０．４９（約５０％）となる。すなわち、従属変数の変化のうち、半分程度がその説明変数によって説明可能である。また、相関係数が０．３のときは、説明率は０．１（約１０％）となり、従属変数の変化のうち、説明変数に起因するものは約１割程度しかないため、説明変数と従属変数の間にはほとんど相関が無いとされる。
本実施例でも同様に考え、相関係数が０．７以上あれば、ＣＰＵ使用率とリクエスト頻度の間に十分に相関があり、正しく１リクエストあたりの消費ＣＵＰ時間を推定することができるため、信頼度が高くなると考えられる。また、この信頼度と予測誤差の関係の目安を、実験環境における実験結果から求めると、信頼度「高」であれば予測誤差±５０％以内程度、信頼度「中」であれば予測誤差±１００％以内程度、信頼度「低」であれば±１００％以上の可能性が高い。但し、この結果はあくまでも実験結果に基づく目安であり、上記の精度（誤差範囲）を保障するものではない。
このようにすれば以上述べたように、各サーバ、各層、システム全体の遅延時間を、既に監視対象システム１００に存在する要素を用いて算出することができるようになる。また、遅延実測値との関係から、遅延時間を補正することも可能であり、さらにその信頼度をユーザに提示することも可能である。
次に、上で述べたようなモデルを用いた性能予測について説明する。
まず、リクエスト頻度変動時の遅延時間の変化の推定について図１２を用いて説明する。ここでは、ある時点ｉにおいて、リクエスト頻度がλであったとすると、リクエスト頻度がλからλ'に変化した場合の推定の平均遅延時間を算出するものとする。すなわち、入出力部１２１からλ'が入力され、遅延分析装置１２０の性能予測処理部１２１３が受け付ける（ステップＳ５０）。そして、性能予測処理部１２１３は、リクエスト頻度の変更に応じて、全てのサーバＳ(n,m)についてＣＰＵ使用率ρを変更し、ＣＰＵ使用率格納部１２０６に格納する（ステップＳ５１）。ＣＰＵ使用率ρについては以下のようにρ'に変更する。また、サーバ遅延時間算出部１２１０は、変更後のＣＰＵ使用率ρ'を用いて、変更後の各サーバの遅延時間Ｔ'i (n,m)を算出し、サーバ遅延時間格納部１２１４に格納する（ステップＳ５３）。ステップＳ５１及びＳ５３における計算は以下のとおりになる。
Figure 2006046297
そして、層遅延時間算出部１２１５は、サーバ遅延時間格納部１２１４に格納された変更後の各サーバの遅延時間Ｔ'i (n,m)を用いて、変更後の各層における遅延時間を算出し、層遅延時間格納部１２１６に格納する（ステップＳ５５）。さらに、システム遅延時間算出部１２１７は、層遅延時間格納部１２１６に格納された変更後の各層における遅延時間を用いて、変更後のシステム全体の遅延時間を算出し、システム遅延時間格納部１２１８に格納する（ステップＳ５７）。
その後、入出力部１２１は、変更前と変更後の各遅延時間などを出力する（ステップＳ５９）。これにより、ユーザは、リクエスト頻度の変動に応じた遅延時間の変化を考察することができるようになる。
次に、ＣＰＵ数変動時における性能予測について図１３を用いて説明する。ここでは、サーバＳ(n,m)のＣＰＵ個数をＣ(n,m)からＣ'(n,m)に変化させるものとする。従って、入出力部１２１からＣＰＵ個数Ｃ'(n,m)が入力され、遅延分析装置１２０の性能予測処理部１２１３が受け付ける（ステップＳ６１）。そして、性能予測処理部１２１３は、ＣＰＵ個数の変更に応じてＣＰＵ使用率ρを変更し、ＣＰＵ使用率格納部１２０６に格納する（ステップＳ６３）。ＣＰＵ使用率ρについては、ＣＰＵ個数の変更があったサーバについてのみ以下のようにρ'に変更する。また、サーバ遅延時間算出部１２１０は、変更後のＣＰＵ使用率ρ'を用いて、ＣＰＵ個数が変更された各サーバの遅延時間Ｔ'i (n,m)を算出し、サーバ遅延時間格納部１２１４に格納する（ステップＳ６５）。ステップＳ６３及びＳ６５における計算は以下のとおりになる。
Figure 2006046297
そして層遅延時間算出部１２１５は、サーバ遅延時間格納部１２１４に格納された変更後のサーバの遅延時間Ｔ'i (n,m)を用いて、変更に係る層における遅延時間を算出し、層遅延時間格納部１２１６に格納する（ステップＳ６７）。さらに、システム遅延時間算出部１２１７は、層遅延時間格納部１２１６に格納された各層における遅延時間を用いて、変更後のシステム全体の遅延時間を算出し、システム遅延時間格納部１２１８に格納する（ステップＳ６８）。
その後、入出力部１２１は、変更前と変更後の各遅延時間などを出力する（ステップＳ６９）。これにより、ユーザは、ＣＰＵ個数の変動に応じた遅延時間の変化を考察することができるようになる。例えばこの結果を用いてＣＰＵ個数を増加させた場合の効果を検討する。
次に、サーバ数変動時における性能予測について図１４を用いて説明する。ここでは、第ｎ層のサーバ数をＭnからＭ'nに変化させたときの推定遅延時間を求めるものとする。従って、入出力部１２１から第ｎ層のサーバ数Ｍ'nが入力され、遅延分析装置１２０の性能予測処理部１２１３が受け付ける（ステップＳ７１）。そして、性能予測処理部１２１３は、サーバ数の変更に応じて１リクエストあたりの消費ＣＰＵ時間を補正し、ＣＰＵ時間格納部１２０９に格納する（ステップＳ７３）。１リクエストあたりの消費ＣＰＵ時間１／μ(n,m)については、以下のように１／μ'(n,m)に変更する。また、性能予測処理部１２１３は、１リクエストあたりの消費ＣＰＵ時間の補正に応じて、ＣＰＵ使用率ρを補正し、ＣＰＵ使用率格納部１２０６に格納する（ステップＳ７５）。ＣＰＵ使用率ρについては、以下のようにρ'に変更する。
Figure 2006046297
 なお、α(n,m)は、１／μ(n,m)を算出する際に求めた切片であり、ＣＰＵ時間格納部１２０９に格納されているのでこれを用いる。
次に、サーバ遅延時間算出部１２１０は、ＣＰＵ使用率格納部１２０６に格納された変更後のＣＰＵ使用率ρ'及びＣＰＵ時間格納部１２０９に格納された変更後の１リクエストあたりの消費ＣＰＵ時間１／μ'(n,m)を用いて、変更後のサーバ遅延時間を算出し、サーバ遅延時間格納部１２１４に格納する（ステップＳ７７）。変更後のサーバ遅延時間Ｔ'i (n,m)は以下のように表される。
Figure 2006046297
そして、層遅延時間算出部１２１５は、サーバ遅延時間格納部１２１４に格納された変更後のサーバの遅延時間Ｔ'i (n,m)を用いて、各層における遅延時間を算出し、層遅延時間格納部１２１６に格納する（ステップＳ７９）。なお、本ステップにおいても性能予測処理部１２１３からのＭ'nを用いて以下のような計算を行う。
Figure 2006046297
なお、（１６）式からＬ'i nは、以下のようにも表わされる。
Figure 2006046297
さらに、システム遅延時間算出部１２１７は、層遅延時間格納部１２１６に格納された各層における遅延時間を用いて、変更後のシステム全体の遅延時間を算出し、システム遅延時間格納部１２１８に格納する（ステップＳ８１）。
その後、入出力部１２１は、変更前と変更後の各遅延時間などを出力する（ステップＳ８３）。これにより、ユーザは、サーバ個数の変動に応じた遅延時間の変化を考察することができるようになる。例えばこの結果を用いてサーバ個数を増加させた場合の効果を検討する。
以上本発明の実施例を説明したが、本発明はこれに限定するものではない。例えば、図４Ａ及び図４Ｂに示した機能ブロック図は一例であって、必ずしも実際のプログラム構成に対応しない場合もある。また、出力処理については、数値をそのまま表示するだけではなく、図１５に示すようなテーブル（１リクエストあたりの消費ＣＰＵ時間、ＣＰＵ使用率、サーバ毎の平均遅延時間、各層の平均遅延時間、遅延実測値、サーバ以外の推定遅延時間、各層の遅延時間の信頼度を単位時間ｉ毎に表示するテーブル）や、図１６に示すようなグラフ（横軸が時刻、縦軸が遅延時間を表し、Ｗｅｂサーバ（第１層）、アプリケーションサーバ（第２層）、ＤＢサーバ（第３層）、その他についての遅延時間の時間変化を表すグラフ）を生成して、表示させるようにしても良い。なお、図１６のグラフを見れば、９時から１２時の通常時には、ほぼＷｅｂサーバの遅延が全体の半分以上になっており（図１６中の部分Ａ）、１２時から１５時にＤＢサーバの一時的な負荷増大によりレスポンスが著しく低下しており（図１６中の部分Ｂ）、１８時以降サーバ以外の遅延時間が増加しており、何らかの問題が発生したかもしれないこと（図１６中の部分Ｃ）などを判断することができるようになる。
また、上で述べた遅延分析装置１２０は、コンピュータ装置であって、図１７に示すように、メモリ２５０１（記憶部）とＣＰＵ２５０３（処理部）とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。本発明の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。
本発明は、コンピュータ・システムのレスポンスに関する分析技術に関する。
ネットワークサービスの発展に伴い、サービスを提供するためのシステムが複雑、大規模化してきている。多くのサービスが多数のサーバを組み合わせて提供されるようになってきている。このようなシステムにおいては、それぞれのサーバのリソースの利用状況がユーザのレスポンスにどのような影響を与えているかを把握することが非常に困難になってきている。
従来、複数のサーバからなるシステムにおいて、それぞれのサーバにおける遅延が、ユーザが体感するレスポンスタイムに対してどのくらいの割合を占めるかを調査するには下記の２つの方法が知られていた。すなわち、（１）各サーバ間で送受信するメッセージに認識用の特別なタグを付けておき、そのタグを用いて遅延を計測するものである。（２）各サーバ間で送受信されるメッセージをパケットキャプチャにより採取し、その情報を解析するものである。
しかし、（１）の方法では、既存のシステムやサービスに変更を加えなければならず、本機能の導入は容易ではない。また、（２）の方法では、パケットキャプチャのための高価な機器や大容量のストレージが必要である。さらに、セキュリティの観点からもパケットキャプチャは好まれない。
また、特開２００４−２１７５６号公報には、情報システム上で動作する一つまたは複数のアプリケーションについて、種々の利用状況下での各アプリケーションの応答性能を、限られた実験回数で効果的に評価する技術が開示されている。より具体的には、アプリケーションの種々の利用状況に対応した負荷投入実験を複数回行う際、アプリケーションの利用状況に関する数量と、アプリケーションの応答性能に関する数量と、ハードウェア・リソースの利用状況に関する数量と、ハードウェア・リソースの応答性能に関する数量を取得し、数量間の依存関係を記述する推定式群を作成する事により、推定式群を用いたアプリケーションの応答性能の評価を可能にするものである。しかし、この技術は「実験」が必要であり、通常の処理を行いながら分析を行うことはできない。
特開２００４−２１７５６号公報
従って、本発明の目的は、分析対象（以下監視対象とも呼ぶ）のコンピュータ・システムから容易に取得できる情報を用いて当該コンピュータ・システムのレスポンスに関する分析を実施するための技術を提供するものである。
本発明に係る分析方法は、複数のサーバを含むコンピュータ・システムのレスポンスに関する分析を行う分析方法であって、上記コンピュータ・システムから上記複数のサーバの各々のＣＰＵ使用率のデータを取得し、ＣＰＵ使用率格納部に格納するステップと、上記コンピュータ・システムにおいて生成される処理履歴データを取得し、上記コンピュータ・システムのユーザによるリクエスト頻度のデータを生成し、リクエスト頻度データ格納部に格納するステップと、ＣＰＵ使用率格納部に格納された各サーバのＣＰＵ使用率とリクエスト頻度データ格納部に格納されたリクエスト頻度とを用いて、各サーバにおける平均遅延時間を推定し、サーバ遅延時間格納部に格納する推定ステップとを含む。
このように、ＣＰＵ使用率及び処理履歴データといった容易に取得できるデータを用いて処理を行うため、導入コストを軽減し、セキュリティ面でも問題を生じさせずに分析処理を実施することができる。
さらに、上で述べた推定ステップが、ＣＰＵ使用率格納部に格納された各サーバのＣＰＵ使用率とリクエスト頻度データ格納部に格納されたリクエスト頻度とを用いて、各サーバの１リクエストあたりの平均消費ＣＰＵ時間を推定し、消費ＣＰＵ時間格納部に格納する消費ＣＰＵ時間推定ステップと、消費ＣＰＵ時間格納部に格納された各サーバの１リクエストあたりの平均消費ＣＰＵ時間とＣＰＵ使用率格納部に格納された各サーバのＣＰＵ使用率とを用いて、各サーバにおける平均遅延時間を推定し、サーバ遅延時間格納部に格納するサーバ遅延時間推定ステップとを含むようにしてもよい。
また、上で述べた消費ＣＰＵ時間推定ステップにおいて、予め指定された時間帯における各サーバのＣＰＵ使用率とリクエスト頻度とを用いて回帰分析を実施することにより、各サーバの１リクエストあたりの平均消費ＣＰＵ時間を推定するようにしてもよい。このように予め指定された時間帯に限定することにより、ユーザによるリクエストをあまり処理していない時間帯を除外することができ、計算精度を向上させることができるようになる。
さらに、上で述べたサーバ遅延時間推定ステップにおいて、サーバの１リクエストあたりの平均消費ＣＰＵ時間と当該サーバにおける平均遅延時間との関係を表す係数値を当該係数値を決定する要素であるＣＰＵ使用率の所定単位毎及びＣＰＵ個数毎に格納するマトリクス格納部を参照して該当する係数値を読み出し、当該係数値と上記サーバの１リクエストあたりの平均消費ＣＰＵ時間とから上記サーバにおける平均遅延時間を算出するようにしてもよい。上記係数値はＣＰＵ使用率とＣＰＵ個数の関数となっているので、都度計算することも可能であるが、実際的には計算量が増加するため、処理速度を上げるため上で述べたようにマトリクス格納部に格納しておく場合もある。
また、上記コンピュータ・システムに含まれる複数のサーバが、実行する業務種別に応じてカテゴリ分けされている場合、当該カテゴリ毎に平均遅延時間を推定するステップをさらに含むようにしても良い。例えば層（レイヤ：Layer）が規定されているようなコンピュータでは、当該層をカテゴリとして層毎の平均遅延時間を算出することもある。例えば、業務毎に問題点を抽出するためである。
さらに、サーバ遅延時間格納部に格納されたデータを用いて、コンピュータ・システム全体の平均遅延時間を推定し、システム遅延時間格納部に格納するステップをさらに含むようにしてもよい。
また、上記コンピュータ・システムにおける、ユーザによるリクエストに対するレスポンス時間の平均実測値を取得し、平均実測値格納部に格納するステップと、平均実測値格納部に格納された平均実測値とシステム遅延時間格納部に格納された上記コンピュータ・システム全体の平均遅延時間との差により、サーバ以外の箇所で発生した遅延時間を推定するステップとをさらに含むようにしてもよい。サーバ以外の箇所で発生した遅延時間がコンピュータ・システム全体の平均遅延時間より短い場合には、何らかの理由により推定が不適切であり、そのような場合を検出することも可能となる。
さらに、カテゴリ毎に、平均消費ＣＰＵ時間の総和とリクエスト頻度との相関係数を算出し、当該相関係数に基づきカテゴリ毎の平均遅延時間の信頼度を決定し、信頼度データ格納部に格納するステップと、信頼度データ格納部に格納されたカテゴリ毎の平均遅延時間の信頼度に基づき、カテゴリ毎の平均遅延時間を補正し、記憶装置に格納する補正ステップとをさらに含むようにしてもよい。例えば信頼度が高い平均遅延時間をそのまま使用し、信頼度が低い平均遅延時間については補正を大きく加えるようにする。
さらに、上で述べた補正ステップが、カテゴリ毎の平均遅延時間を信頼度の高い順にソートするステップと、信頼度の高い順に前記カテゴリ毎の平均遅延時間を累積してゆき、累積された平均遅延時間が遅延実測値未満であって最大の値を有することとなる信頼度の順番を特定するステップと、特定された信頼度の順番の次の順番の遅延時間を、遅延実測値と信頼度の高い順にカテゴリ毎の平均遅延時間を特定された信頼度の順番まで累積することにより得られる値との差に補正するステップとを含むようにしてもよい。
また、リクエスト頻度が例えば試験的に変更された場合、当該変更後のリクエスト頻度に応じて各サーバのＣＰＵ使用率を変更し、記憶装置に格納するステップと、記憶装置に格納された変更後の各サーバのＣＰＵ使用率を用いて、各サーバにおける平均遅延時間を推定し、記憶装置に格納するステップと、サーバ遅延時間格納部及び記憶装置に格納された変更前後の各サーバの平均遅延時間を比較可能な態様で出力するステップとをさらに含むようにしてもよい。リクエスト頻度の変動に対して遅延時間がどのように変化するかを知ることができる。
また、ＣＰＵ数が例えば試験的に変更された場合、当該変更後のＣＰＵ数に応じて各前記サーバのＣＰＵ使用率を変更し、記憶装置に格納するステップと、記憶装置に格納された変更後の各サーバのＣＰＵ使用率と変更後のＣＰＵ数とを用いて、各サーバにおける平均遅延時間を推定し、記憶装置に格納するステップと、サーバ遅延時間格納部及び記憶装置に格納された変更前後の各サーバの平均遅延時間を比較可能な態様で出力するステップとをさらに含むようにしてもよい。ＣＰＵ数を例えば増加させた場合に遅延時間がどの程度減少するか試すことができ、その効果から投資の是非を判断できるようになる。
また、サーバ数が変更された場合、当該変更後のサーバ数に応じて各サーバの１リクエストあたりの平均消費ＣＰＵ時間を算出し、記憶装置に格納するステップと、ＣＰＵ個数と記憶装置に格納された変更後の各サーバの１リクエストあたりの平均消費ＣＰＵ時間とを用いて、変更後における各サーバのＣＰＵ使用率を算出し、記憶装置に格納するステップと、記憶装置に格納された変更後の各サーバの１リクエストあたりの平均消費ＣＰＵ時間と変更後における各サーバのＣＰＵ使用率とを用いて、変更後における各サーバの平均遅延時間を推定し、記憶装置に格納するステップとをさらに含むようにしてもよい。サーバ数を例えば増加させた場合に遅延時間がどの程度減少するかを試すことができ、その効果から投資の是非を判断できるようになる。
さらに、記憶装置に格納された変更後における各サーバの平均遅延時間と変更後のサーバ数とを用いて、コンピュータ・システムに含まれる複数のサーバを実行する業務種別に応じて分けることにより規定されるカテゴリ毎の平均遅延時間を推定し、記憶装置に格納するステップをさらに含むようにしてもよい。
上で述べた分析方法をコンピュータに実行させるためのプログラムを作成することができ、このプログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークなどを介してデジタル信号として配信される場合もある。尚、中間的な処理結果はメモリ等の記憶装置に一時保管される。
［本発明の原理］
Ａ．Ｗｅｂシステムモデルにおける平均遅延時間の理論値Ｘ^（Ｘの上に^を付した記号をＸ^とも示すものとする）の導出
Ａ−１．単一サーバの遅延時間のモデル化
まず、図１を用いて複数のＣＰＵを有する単一サーバＳにおける平均遅延時間を導出することを考える。図１に示すサーバＳはＣＰＵ＿１からＣＰＵ＿ＣまでのＣ個のＣＰＵを有し、外部からリクエスト頻度λ（req/sec）で入力されたリクエストは、待ち行列Ｓwに入れられた後にＣ個のＣＰＵで処理される。この際、ＣＰＵの使用率をρ（％）とする。そして、Ｍ／Ｍ／ｓ待ち行列モデルの解析結果より、サーバＳにおけるリクエストの平均滞在時間Ｔ（Ｃ，λ，ρ）は、以下のようになる。
Figure 2006046297
（１）式乃至（３）式より、サーバＳにおける平均滞在時間Ｔ（Ｃ，λ，ρ）は、以下の関係が成立する。なお、αはサーバＳに到達するリクエストの割合を表す。
Figure 2006046297
Ａ−２．第Ｎ層のサーバ層における遅延時間のモデル化
ここでは、単一サーバにおける遅延モデルを用いて、複数層における特定の単一層におけるリクエストの平均遅延時間を求める。前提となるシステム・モデルを図２に表す。第１層には、Ｍ1個のサーバＳ(1,1)、Ｓ(1,2)、．．．Ｓ(1,M1)が存在しており、第２層には、Ｍ2個のサーバＳ(2,1)、Ｓ(2,2)、．．．Ｓ(2,M2)が存在しており、さらに第Ｎ層には、ＭN個のサーバＳ(N,1)、Ｓ(N,2)、．．．Ｓ(N,MN)が存在している。また、αnは第ｎ層に到達するリクエストの割合を表し、各層におけるサーバにリクエストが均等に振り分けられ、本システムにλall（req/sec）というリクエスト頻度でリクエストが入力されると、第１層の各サーバには、λall／Ｍ1のリクエストが入力され、第１層から離脱するリクエストは（１−α2）λallであり、第２の層の各サーバには、α2λall／Ｍ2というリクエストが入力され、第２層から離脱するリクエストは（α2−α3）λallであり、第Ｎ−１層から離脱するリクエストは（αN-1−αN）λallであり、第Ｎ層の各サーバには、αNλall／ＭNのリクエストが入力され、第Ｎ層から出力されるリクエストはαNλallとなる。なお、１≦ｎ≦Ｎ、１≦ｍ≦Ｍnとする。
各層には、例えばユーザに対するフロントエンドとして用いられるＷｅｂサーバや、リクエストを動的に処理するためのアプリケーションサーバ等、それぞれ異なる役割が割り当てられている。
そして、第ｎ層のサーバＳ(n,m)に入ってくるリクエスト頻度をλ(n,m)とすると、サーバＳ(n,m)における平均遅延時間はＴ（Ｃ(n,m)，λ(n,m)，ρ(n,m)）と表すことができる。また、第ｎ層に入ってくるリクエストの総量はαnλallであり、それらがＭn個のサーバに均等に振り分けられるとすると、以下の式が成り立つ。
Figure 2006046297
リクエストは各サーバに均等に振り分けられるので、第ｎ層における全リクエストの平均遅延時間Ｗnは、第ｎ層に存在する全てのサーバの平均遅延時間の平均をとったものになる。
Figure 2006046297
ここで、（１）式乃至（４）式を用いると、Ｗnは下記のようになる。
Figure 2006046297
ここで表記を簡略化するためＨnを下記のように定義する。
Figure 2006046297
Ａ−３．システム全体における遅延時間のモデル化
ここでは、各層における遅延のモデルを用いて、システム全体における遅延時間のモデル化を行う。全てのリクエストのうち、第１層から第ｎ層までのサーバを利用した後、システムから離脱するリクエストの数Ｒnは、下記のようになる。
Figure 2006046297
また、第１層から第ｎ層までのサーバを利用した後、システムから離脱するリクエストの平均遅延Ｌnは、下記のようになる。
Figure 2006046297
また、定義より下記の関係が成り立つ。
Figure 2006046297
１リクエストあたりの平均遅延時間Ｘ^は、第１層から第ｉ層までのサーバを利用してからシステムを離脱するリクエストについて、それらの遅延と、全リクエストに対する割合の積で表すことができるので、下記のようになる。
Figure 2006046297
上記の結果より、全リクエストの平均遅延時間を考えた場合、Ｈnは各層で発生する遅延を表しており、その総和Ｘ^は、全リクエストに対するシステム全体での平均遅延時間を表していると言える。
［具体的処理］
図３に監視対象システム１００及び遅延分析装置１２０を含むシステムの概要を示す。監視対象システム１００は、ネットワークに接続されており、図２に示したようにＮ層（図３では説明を簡略化するため２層）の構成となっている。各層には、負荷分散装置１０１及び１０２が設けられており、当該負荷分散装置は、各層のサーバ群Ｓ(1,1)，Ｓ(1,2)及びＳ(1,M1)並びにサーバ群Ｓ(N,1)，Ｓ(N,2)及びＳ(N,MN)に対してほぼ均等にリクエストを分配する。第１層のサーバには、サーバログ１１１ａが設けられており、リクエストに対する処理を実施するとそのログデータが格納されるようになっている。また、各サーバには、ＣＰＵ（Central Processing Unit）使用率取得部１１２ａ及び１１２ｂが設けられており、本実施例ではＣＰＵ使用率を％単位で取得するようになっている。このＣＰＵ使用率取得部１１２ａ及び１１２ｂは、ＵＮＩＸ（登録商標） ＯＳ（Operating System）等の場合にはｓａｒ、ｍｐｓｔａｔ、ｉｏｓｔａｔなどのコマンドで実行される一般的なツールであって、近年のＯＳには同様の機能を有しているものが多い。
遅延分析装置１２０は、監視対象システム１００に接続されており、サーバログ１１１ａに格納されたログデータ及びＣＰＵ使用率を用いて処理を行う。このように従来とは異なり、監視対象システム１００内に特別の仕組みを組み込むことがないので遅延分析装置１２０の導入は容易であり、さらに監視対象システム１００内で処理される全てのパケットを解析するものでもないので、大容量のストレージを用いる必要は無く、セキュリティ上の問題も生じにくくなっている。遅延分析装置１２０は、表示装置、マウス、キーボードその他の入出力部１２１に接続されている。
図４Ａ及び図４Ｂに遅延分析装置１２０の機能ブロック図を示す。遅延分析装置１２０は、リクエスト頻度取得部１２０１と、ＣＰＵ使用率取得部１２０２と、ログデータ格納部１２０３と、リクエスト頻度格納部１２０４と、遅延実測値格納部１２０５と、ＣＰＵ使用率格納部１２０６と、システム構成データ格納部１２０７と、ＣＰＵ時間算出部１２０８と、ＣＰＵ時間格納部１２０９と、性能予測処理部１２１３と、サーバ遅延時間算出部１２１０と、Ｇテーブル格納部１２１１と、サーバ遅延時間格納部１２１４と、層遅延時間算出部１２１５と、層遅延時間格納部１２１６と、システム遅延時間算出部１２１７と、システム遅延時間格納部１２１８と、残余遅延時間算出部１２１９と、残余遅延時間格納部１２２０と、信頼度算出部１２２１と、信頼度格納部１２２２と、遅延時間補正部１２２３と、補正遅延時間格納部１２２４とを有する。
リクエスト頻度取得部１２０１は、監視対象システム１００のサーバログ１１１ａからログデータを受信しログデータ格納部１２０３に格納すると共に、入出力部１２１からの入力データに従ってログデータ格納部１２０３に格納されたログデータを処理してリクエスト頻度（req/sec）を算出し、リクエスト頻度格納部１２０４に格納する。また、ログデータ格納部１２０３に格納されたログデータを処理して平均遅延実測値を算出し、当該平均遅延実測値を遅延実測値格納部１２０５に格納する。ＣＰＵ使用率取得部１２０２は、監視対象システム１００のＣＰＵ使用率取得部１１２からＣＰＵ使用率のデータを取得し、当該データをＣＰＵ使用率格納部１２０６に格納する。
ＣＰＵ時間算出部１２０８は、リクエスト頻度格納部１２０４とＣＰＵ使用率格納部１２０６とシステム構成データ格納部１２０７とを参照して１リクエストあたりの消費ＣＰＵ時間を算出し、算出されたデータをＣＰＵ時間格納部１２０９に格納する。サーバ遅延時間算出部１２１０は、ＣＰＵ時間格納部１２０９とＧテーブル格納部１２１１とＣＰＵ使用率格納部１２０６とを参照してサーバ毎の遅延時間を算出し、算出されたデータをサーバ遅延時間格納部１２１４に格納する。なお、サーバ遅延時間算出部１２１０は、Ｇテーブル格納部１２１１を参照しない場合には、リクエスト頻度格納部１２０４とシステム構成データ格納部１２０７を参照することもある。
さらに層遅延時間算出部１２１５は、サーバ遅延時間格納部１２１４とシステム構成データ格納部１２０７とを参照して層毎の遅延時間を算出し、算出されたデータを層遅延時間格納部１２１６に格納する。システム遅延時間算出部１２１７は、層遅延時間格納部１２１６とシステム構成データ格納部１２０７とを参照してシステム全体の遅延時間を算出し、算出したデータをシステム遅延時間格納部１２１８に格納する。残余遅延時間算出部１２１９は、遅延実測値格納部１２０５とシステム遅延時間格納部１２１８とを参照してサーバ以外の他の装置により消費された残余の遅延時間を算出し、算出されたデータを残余遅延時間格納部１２２０に格納する。
また信頼度算出部１２２１は、残余遅延時間格納部１２２０とシステム構成データ格納部１２０７と遅延実測値格納部１２０５とリクエスト頻度格納部１２０４とＣＰＵ使用率格納部１２０６と層遅延時間格納部１２１６とを参照し、サーバ以外の他の装置により消費された残余の遅延時間が０未満である場合、各層の遅延時間について信頼度を算出し、算出された信頼度データを信頼度格納部１２２２に格納する。遅延時間補正部１２２３は、層遅延時間格納部１２１６と信頼度格納部１２２２とを参照して層毎の遅延時間を補正し、補正された遅延時間のデータを補正遅延時間格納部１２２４に格納する。
性能予測処理部１２１３は、ＣＰＵ使用率格納部１２０６とシステム構成データ格納部１２０７とＣＰＵ時間格納部１２０９とリクエスト頻度格納部１２０４とを用いて処理を行う。
なお、入出力部１２１は、遅延分析装置１２０内の格納部内のデータを表示装置などに出力することができるようになっている。
次に図５乃至図１６を用いて図３並びに図４Ａ及び図４Ｂに示したシステムの処理内容について説明する。まず、リクエスト頻度取得部１２０１は、監視対象システム１００のサーバログ１１１ａからログデータを取得してログデータ格納部１２０３に格納し、ＣＰＵ使用率取得部１２０２は監視対象システム１００のＣＰＵ使用率取得部１１２からＣＰＵ使用率のデータを受信し、ＣＰＵ使用率格納部１２０６に格納する（図５：ステップＳ１）。
ログデータ格納部１２０３に格納されるログデータの一例を以下に示す。
「192.168.164.108 - - [14/Sep/2004:12:27:50 +0900] "GET /~hoge/SSSS/SSSS__20040816.pdf HTTP/1.1" 200 147067 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)" 0.053」（Windowsは登録商標）
これは、Ａｐａｃｈｅ Ｗｅｂサーバにおいてカスタムログ形式で採取された１つのログの一例である。一般的には監視対象システム１００に含まれるＷｅｂサーバの/var/log/httpd/ディレクトリ配下などにサーバログ１１１ａとして格納されている。この第１項「192.168.164.108」はアクセス元クライアントのＩＰアドレスを表す。第２項及び第３項は省略されている。第４項「 [14/Sep/2004:12:27:50 +0900]」はアクセス時刻を表している。第５項「"GET /~hoge/SSSS/SSSS__20040816.pdf HTTP/1.1"」はアクセス内容を示す。第６項「200」はステータス（ここでは正常）を表す。第７項「147067」は送受信バイト数を表す。第８項「"-"」はリクエストされたＵＲＬパスを表す。第９項「"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)"」はアクセス元クライアントが使用しているブラウザを表す。第１０項「0.053」は、リクエストを扱うのにかかった時間（sec）を表す。
次に、入出力部１２１は、分析対象期間及びビジネス時間帯の設定入力を受け付け、例えばメインメモリ等の記憶装置に格納する（ステップＳ３）。ビジネス時間帯とは、ユーザからのリクエスト以外の処理にサーバが費やすＣＰＵ時間が少ない時間帯をいう。ビジネス時間帯を指定することにより、夜間など、リクエストが少ないときに多量のＣＰＵ時間がサーバで消費されることに起因する推定誤差を減らすことができる。
そして、リクエスト頻度取得部１２０１は、ログデータ格納部１２０３から指定分析対象期間及びビジネス時間帯におけるログデータを読み出し、例えば１時間毎にいくつのリクエストが処理されたかカウントし且つカウント値を３６００秒（＝１時間）で割ることにより１秒あたりのリクエスト頻度λ（req/sec）を算出し、リクエスト頻度格納部１２０４に格納する。また、リクエスト頻度取得部１２０１は、例えば１時間毎に全てのリクエストを取り扱うのにかかった時間を加算してリクエスト数で除することにより平均遅延実測値を算出し、遅延実測値格納部１２０５に格納する。さらに、ＣＰＵ使用率算出部１２０８は、ＣＰＵ使用率格納部１２０６に格納されたＣＰＵ使用率のデータに基づき、１時間毎に各サーバＳ(n,m)の平均ＣＰＵ使用率ρi (n,m)を算出し、ＣＰＵ使用率格納部１２０６に格納する（ステップＳ５）。１つのサーバが複数のＣＰＵを有する場合には、その複数のＣＰＵの平均ＣＰＵ使用率を算出して当該サーバのＣＰＵ使用率とする。なお、平均ＣＰＵ使用率ρi (n,m)におけるｉはｉ番目の単位時間（ここでは１時間毎）を表す。また、以下「平均」という文字を省略することもある。
ここまでの処理結果をまとめると、例えば図６に示すようになる。図６の例では、各時間帯につき、単位時間番号ｉと、リクエスト頻度λi（req/sec）と、遅延実測値Ａiと、ＣＰＵ使用率ρi (1,1)、ρi (1,2)、ρi (2,1)、ρi (3,1)とが示されている。
次に、ＣＰＵ時間算出部１２０８は、リクエスト頻度格納部１２０４とＣＰＵ使用率格納部１２０６とシステム構成データ格納部１２０７とを参照して、１リクエストあたりの消費ＣＰＵ時間を算出し、ＣＰＵ時間格納部１２０９に格納する（ステップＳ７）。各サーバで発生する遅延時間を算出するためには、まず、システム全体に対して外部から入ってくるリクエスト頻度λi（req/sec）に対して、各サーバで１リクエストあたりどれだけのＣＰＵ時間が消費されているか求める必要がある。しかし、単純に単位時間ｉにおけるサーバＳ(n,m)のＣＰＵ使用率ρi (n,m)とＣＰＵの個数Ｃ(n,m)との積をリクエスト頻度λiで割って、１リクエストあたりの平均消費ＣＰＵ時間を
Figure 2006046297
 として算出すると、以下のような不都合が生ずる。すなわち、サーバにおいては、通常、リクエストの処理以外にもシステムの維持等によって若干のＣＰＵ時間が消費されている。リクエスト頻度が極端に小さい場合、このようなＣＰＵ時間の割合が相対的に大きくなるため、１リクエストあたりの消費ＣＰＵ時間を大きく見積もってしまい、誤差の原因となる恐れがある。すなわち、図７（ａ）のように横軸をリクエスト頻度、縦軸をＣＰＵ使用率とすると、（１２）式をそのまま解釈するとリクエストがなければＣＰＵ使用率も０となるはずである。そこで、原点と各測定点とを結ぶ直線の傾きを１リクエストあたりの消費ＣＰＵ時間とすると、大きなバラツキが生ずる。
この問題を解決するために、１リクエストあたりの消費ＣＰＵ時間１／μ(n,m)が以下のように表されるものと仮定する。
Figure 2006046297
 そして１リクエストあたりの消費ＣＰＵ時間１／μ(n,m)を、回帰分析によって求め、以下の式で近似するものとする。
Figure 2006046297
図７（ｂ）に示すように、回帰計算を行えば、各測定点を結ぶ回帰直線の傾きを、１リクエストあたりの消費ＣＰＵ時間として算出することができ、より実際に近い値を得ることができる。
なお、回帰計算を行う際には、ユーザが指定したビジネス時間帯内のデータのみを用いる。これは、分析対象期間の全データを利用した場合、リクエスト数の小さい夜間にバッチ処理などが実行され、多量のＣＰＵ時間が消費されるなどの事象が発生すると、リクエスト数が小さい場合の方が、リクエスト数が多い場合よりＣＰＵ使用率が高いという現象が発生する。そうすると、回帰計算を用いた１リクエストあたりの消費ＣＰＵ時間推定において大きな誤差を生じさせる可能性がある。これは図８に示すように、夜間バッチ処理による測定点を黒丸で表すと、リクエスト頻度が小さいにもかかわらずＣＰＵ使用率が高くなるため縦軸の上の方にプロットされてしまい、日中のリクエスト処理についての測定値（白丸で表す）と合わせて回帰計算を行うと、実線のような回帰直線が得られてしまう場合がある。一方、日中のリクエスト処理についての測定値のみを用いれば点線のような傾きが正の正しい回帰直線が得られる。従って、ビジネス時間帯にデータを絞る必要がある。
上で述べた回帰計算をより詳しく述べると、分析対象期間のデータのうち、ユーザの指定したビジネス時間帯に該当するデータ（ＣＰＵ使用率ρ(n,m)，システム構成データであるＣＰＵ個数Ｃ(n,m)，リクエスト頻度λi）に対して、（１３）式のような直線を引いた場合に、偏差が最も少なくなるように最小二乗法により傾き１／μ(n,m)と切片α(n,m)を計算し、ＣＰＵ時間格納部１２０９に格納する。但し、α(n,m)が負となるときは、傾きを過大に見積もっている可能性が高いので、切片０として、再度以下の直線として回帰分析を実施して１／μ(n,m)を求める。
Figure 2006046297
また、傾き１／μ(n,m)が負となるときには、そのサーバでの１リクエストあたりの平均遅延時間は解析不能であると判断し、解析不能を表すコードをＣＰＵ時間格納部１２０９に格納する。このようなコードが格納されると、そのサーバが含まれる層で発生する平均遅延時間についても解析不能となる。
図５の説明に戻って、次にサーバ遅延時間算出部１２１０は、ＣＰＵ使用率格納部１２０６とシステム構成データ格納部１２０７とＣＰＵ時間格納部１２０９とＧテーブル格納部１２１１とを参照して、各サーバで発生する１リクエストあたりの平均遅延時間を算出し、算出された値をサーバ遅延時間格納部１２１４に格納する（ステップＳ９）。ｉ番目の単位時間において、各サーバで発生する１リクエストあたりの平均遅延時間Ｔi (n,m)は、以下の式で与えられる。
Figure 2006046297
 但し、ρ＝０のとき、Ｇ（Ｃ，０）＝１とする。
ここで１／μ(n,m)は１リクエストあたりの消費ＣＰＵ時間を表しているが、これは負荷が０％のときに発生する平均遅延時間に等しい。そして、負荷がρの時には、遅延が負荷０％のときのＧ（Ｃ，ρ）倍になることを意味している。
Ｇ（Ｃ，ρ）については、（３）式に示したように、サーバのＣＰＵ個数とＣＰＵ使用率によって算出される。但し、（３）式をそのまま計算すると比較的時間がかかるので、分析の粒度が決まっている場合には、サーバのＣＰＵ数及びＣＰＵ使用率を変動させ、事前に算出することも可能である。例えば、分析の粒度が、ＣＰＵ使用率においては１％単位で十分であり、且つ想定される１サーバあたりのＣＰＵの個数が５０個以下である場合、ＣＰＵ使用率が０乃至９９％（１％刻み）において、サーバのＣＰＵが１乃至５０個のそれぞれの場合におけるＧ（Ｃ，ρ）を予め算出しておき、それを１００×５０のマトリクスとしてＧテーブル格納部１２１１に格納しておく。そうすれば、システム構成データ格納部１２０７からＣＰＵ個数を取得し、ＣＰＵ使用率格納部１２０６からＣＰＵ使用率を取得し、Ｇテーブル格納部１２１１からＧ（Ｃ，ρ）の値を取得することができる。
最終的には、（１４）式に従って各サーバで発生する１リクエストあたりの平均遅延時間Ｔi (n,m)（以下、略して各サーバの平均遅延時間ともいう）が算出され、サーバ遅延時間格納部１２１４に格納される。
次に、層遅延時間算出部１２１５は、サーバ遅延時間格納部１２１４とシステム構成データ格納部１２０７とを参照して、各層における遅延時間Ｌi nを算出し、層遅延時間格納部１２１６に格納する（ステップＳ１１）。各層における遅延時間Ｌi nは、各層のサーバの平均遅延時間の和であり、以下のように表される。Ｍnについてはシステム構成データ格納部１２０７から取得する。
Figure 2006046297
そして、システム遅延時間算出部１２１７は、層遅延時間格納部１２１６とシステム構成データ格納部１２０７とを参照して、システム全体の遅延時間Ｄiを算出し、システム遅延時間格納部１２１８に格納する（ステップＳ１３）。システム全体の遅延時間Ｄiは、各層ｎにおける遅延時間Ｌi nの和であり、以下のように表される。Ｎについてはシステム構成データ格納部１２０７から取得する。
Figure 2006046297
その後、残余遅延時間算出部１２１９は、遅延実測値格納部１２０５とシステム遅延時間格納部１２１８とを参照して、サーバ以外の箇所でかかる遅延時間Ｅiを算出し、残余遅延時間格納部１２２０に格納する（ステップＳ１５）。遅延時間Ｅiは、システム全体の遅延時間Ｄiと遅延実測値Ａiの差であって、以下のように算出される。
Figure 2006046297
Ａi＜Ｄiということは、上で述べたような推定結果が適切ではないということであり、そのような場合にはＥi＝０に設定される。
そして主にＥi＝０となった場合に遅延時間の補正を行うため、信頼度算出部１２２１は、残余遅延時間格納部１２２０と層遅延時間格納部１２１６とシステム構成データ格納部１２０７とリクエスト頻度格納部１２０４とＣＰＵ使用率格納部１２０６と遅延実測値格納部１２０５とを参照して、各層の平均遅延時間の信頼度を算出処理を実施し、処理結果を信頼度格納部１２２２に格納する（ステップＳ１７）。この処理については図９を用いて説明する。まず、信頼度算出部１２２１は、第ｎ層の消費ＣＰＵ時間の総和ρとリクエスト頻度λとの間の相関係数を各層ｎの平均遅延時間の初期信頼度Ｒi nとして算出し、信頼度格納部１２２２に格納する（ステップＳ３１）。ｃｏｒｒｅｌを相関係数を求める関数とすると、以下のような式に従って信頼度Ｒi nを算出する。
Figure 2006046297
 （１５）式におけるｃｏｒｒｅｌ関数の第１項が第ｎ層における消費ＣＰＵ時間の総和である。なお、相関係数も後の計算で用いられるため、各層につき保持しておく。
そして相関係数Ｒi nが負であるか判断する（ステップＳ３３）。相関係数＜０であれば信頼度Ｒi n＝０と設定する（ステップＳ３７）。消費ＣＰＵ時間とリクエスト頻度の間には正の相関があることを仮定しており、負の相関に意味が無いためである。一方、相関係数≧０であれば、平均遅延実測値Ａiよりシステム全体の推定遅延時間Ｄiが長いか判断する（ステップＳ３５）。Ｄi＞Ａiが成り立つ場合には、あり得ない推定がなされており算出された遅延時間自体の信頼性が低いため、ステップＳ３７に移行する。すなわち、信頼度Ｒi n＝０と設定する。一方、Ｄi≦Ａiであれば、ステップＳ３１で算出された相関係数をそのまま信頼度として使用する。
図５の説明に戻って、遅延時間補正部１２２３は、信頼度格納部１２２２と層遅延時間格納部１２１６とを参照して、信頼度に応じた遅延時間の補正を行い、補正遅延時間格納部１２２４に格納する（ステップＳ１９）。なお、Ａi≧Ｄiであれば、本ステップはスキップされる。この処理については図１０を用いて説明する。まず、遅延時間補正部１２２３は、層遅延時間格納部１２１６と信頼度格納部１２２２とを参照して、各層の遅延時間を信頼度の高い順にソートし、補正遅延時間格納部１２２４に格納する（ステップＳ４１）。なお、信頼度が０の層が複数ある場合は、それらの相関係数の高い順にソートする。
そして、ソート結果に従って信頼度の高い順に層の遅延時間を加算し、当該加算値が平均遅延実測値未満の最大となるような信頼度の順番Ｂを特定する（ステップＳ４３）。ここでＰx＝ｎを、第ｎ層の信頼度Ｒi nの高さが上からｘ番目であるものとする。そうすると、Ｒi Px＞Ｒi Px+1が常に成り立つ。そしてステップＳ４３では以下の式を満たす最大のｙを求める。これがＢである。
Figure 2006046297
このようにして求められた信頼度Ｂ番目の層の遅延時間までについては補正は不要である。従って、信頼度Ｂ＋１番目の層の遅延時間を以下のように補正する（ステップＳ４５）。すなわち、第ＰB+1層の推定遅延時間Ｌi Px+1について補正を行い、その結果をＬ'i Px+1とする。補正結果及び補正不要の層（信頼度Ｂ番目までの層）の遅延時間は、補正遅延時間格納部１２２４に格納される。
Figure 2006046297
 この式は、遅延実測値と、各層の信頼度のうち、信頼度が高い方からＢ＋１番目までの遅延時間（推定平均値）の総和とが等しくなるように信頼度Ｂ＋１番目の層の遅延時間を補正する。
また、信頼度Ｂ＋１番目の層の信頼度を以下のように補正する（ステップＳ４７）。すなわち、第ＰB+1層の信頼度Ｒi Px+1について補正を行い、その結果をＲ'i Px+1とする。補正結果及び補正不要の層（信頼度Ｂ番目までの層）の信頼度データは、補正遅延時間格納部１２２４に格納される。
Figure 2006046297
 この式は、補正前の遅延時間と補正後の遅延時間の差が小さいほど、信頼度が高くなるように信頼度を補正している。
さらに、信頼度Ｂ＋２番目以降の層の遅延時間及び信頼度を以下のように補正する（ステップＳ４９）。補正結果は、補正遅延時間格納部１２２４に格納される。
Ｌ'i Pn＝０ （ｎ＞Ｂ＋１）
Ｒ'i Pn＝０ （ｎ＞Ｂ＋１）
このような補正処理の具体例を図１１（ａ）乃至（ｃ）を用いて説明する。まず、図１１（ａ）に遅延時間推定結果及び実測結果を示す。本例における監視対象システム１００の第１層はＷｅｂサーバであり、第２層はアプリケーションサーバであり、第３層はＤＢサーバである。ここで、第１層の推定遅延時間は１５０ｍｓｅｃであり、相関係数０．９で信頼度０である。第２層の推定遅延時間は６０ｍｓｅｃであり、相関係数０．８５で信頼度０．８５である。第３層の推定遅延時間は３０ｍｓｅｃであり、相関係数０．６で信頼度０．６である。なお、平均遅延実測値が１００ｍｓｅｃである。
そして、ステップＳ４１でソートすると、図１１（ｂ）に示すように、各層は、第２層、第３層、第１層の順番に並べられ、システム全体の遅延時間は明らかに平均遅延実測値を超えており、システム全体の推定遅延時間は第１層の途中で超えてしまっている。
従って、図１１（ｃ）に示すように、第２層及び第３層については、遅延時間及び信頼度についてはそのまま用い、第１層の推定遅延時間については平均遅延実測値と第２層及び第３層の遅延時間の和との差に減らされ、１０ｍｓｅｃとなる。また信頼度も０．０６（＝１０／１５０）に補正されている。
このようにして推定値を実測値に合わせるような補正がなされる。
図５の説明に戻って、入出力部１２１は、出力処理を実施する（ステップＳ２１）。入出力部１２１が出力するデータは、（１）各サーバで発生する遅延時間の推定値Ｔi (n,m)、（２）各層で発生する遅延時間の推定値Ｌi n、（３）システム全体で発生する遅延時間の推定値Ｄi、（４）サーバ以外の箇所の遅延時間Ｅi、（５）各層の遅延時間の信頼度などである。信頼度の場合、値そのものを出力しても良いし、信頼度Ｒi nを例えば以下の３つのレベルに分類し、分類結果を出力するようにしても良い。すなわち、Ｒi n＞０．７であれば信頼度「高」、０．７≧Ｒi n＞０．３であれば信頼度「中」、０．３≧Ｒi nであれば信頼度「低」である。
上で述べたような信頼度の高中低の分類は、相関係数における相関の強さの判断に一般的に用いられている値である。すなわち、一般的に、相関係数の絶対値が０．７以上であれば、２つのパラメータの間に強い相関があると判断され、０．３乃至０．７程度であれば、弱い相関があると判断され、０．３以下であればほとんど無相関であるとされている。これは、相関係数の二乗が変動の説明率であることに起因している。そして、相関係数が０．７のとき、説明率は０．４９（約５０％）となる。すなわち、従属変数の変化のうち、半分程度がその説明変数によって説明可能である。また、相関係数が０．３のときは、説明率は０．１（約１０％）となり、従属変数の変化のうち、説明変数に起因するものは約１割程度しかないため、説明変数と従属変数の間にはほとんど相関が無いとされる。
本実施例でも同様に考え、相関係数が０．７以上あれば、ＣＰＵ使用率とリクエスト頻度の間に十分に相関があり、正しく１リクエストあたりの消費ＣＰＵ時間を推定することができるため、信頼度が高くなると考えられる。また、この信頼度と予測誤差の関係の目安を、実験環境における実験結果から求めると、信頼度「高」であれば予測誤差±５０％以内程度、信頼度「中」であれば予測誤差±１００％以内程度、信頼度「低」であれば±１００％以上の可能性が高い。但し、この結果はあくまでも実験結果に基づく目安であり、上記の精度（誤差範囲）を保障するものではない。
このようにすれば以上述べたように、各サーバ、各層、システム全体の遅延時間を、既に監視対象システム１００に存在する要素を用いて算出することができるようになる。また、遅延実測値との関係から、遅延時間を補正することも可能であり、さらにその信頼度をユーザに提示することも可能である。
次に、上で述べたようなモデルを用いた性能予測について説明する。
まず、リクエスト頻度変動時の遅延時間の変化の推定について図１２を用いて説明する。ここでは、ある時点ｉにおいて、リクエスト頻度がλであったとすると、リクエスト頻度がλからλ'に変化した場合の推定の平均遅延時間を算出するものとする。すなわち、入出力部１２１からλ'が入力され、遅延分析装置１２０の性能予測処理部１２１３が受け付ける（ステップＳ５０）。そして、性能予測処理部１２１３は、リクエスト頻度の変更に応じて、全てのサーバＳ(n,m)についてＣＰＵ使用率ρを変更し、ＣＰＵ使用率格納部１２０６に格納する（ステップＳ５１）。ＣＰＵ使用率ρについては以下のようにρ'に変更する。また、サーバ遅延時間算出部１２１０は、変更後のＣＰＵ使用率ρ'を用いて、変更後の各サーバの遅延時間Ｔ'i (n,m)を算出し、サーバ遅延時間格納部１２１４に格納する（ステップＳ５３）。ステップＳ５１及びＳ５３における計算は以下のとおりになる。
Figure 2006046297
そして、層遅延時間算出部１２１５は、サーバ遅延時間格納部１２１４に格納された変更後の各サーバの遅延時間Ｔ'i (n,m)を用いて、変更後の各層における遅延時間を算出し、層遅延時間格納部１２１６に格納する（ステップＳ５５）。さらに、システム遅延時間算出部１２１７は、層遅延時間格納部１２１６に格納された変更後の各層における遅延時間を用いて、変更後のシステム全体の遅延時間を算出し、システム遅延時間格納部１２１８に格納する（ステップＳ５７）。
その後、入出力部１２１は、変更前と変更後の各遅延時間などを出力する（ステップＳ５９）。これにより、ユーザは、リクエスト頻度の変動に応じた遅延時間の変化を考察することができるようになる。
次に、ＣＰＵ数変動時における性能予測について図１３を用いて説明する。ここでは、サーバＳ(n,m)のＣＰＵ個数をＣ(n,m)からＣ'(n,m)に変化させるものとする。従って、入出力部１２１からＣＰＵ個数Ｃ'(n,m)が入力され、遅延分析装置１２０の性能予測処理部１２１３が受け付ける（ステップＳ６１）。そして、性能予測処理部１２１３は、ＣＰＵ個数の変更に応じてＣＰＵ使用率ρを変更し、ＣＰＵ使用率格納部１２０６に格納する（ステップＳ６３）。ＣＰＵ使用率ρについては、ＣＰＵ個数の変更があったサーバについてのみ以下のようにρ'に変更する。また、サーバ遅延時間算出部１２１０は、変更後のＣＰＵ使用率ρ'を用いて、ＣＰＵ個数が変更された各サーバの遅延時間Ｔ'i (n,m)を算出し、サーバ遅延時間格納部１２１４に格納する（ステップＳ６５）。ステップＳ６３及びＳ６５における計算は以下のとおりになる。
Figure 2006046297
そして層遅延時間算出部１２１５は、サーバ遅延時間格納部１２１４に格納された変更後のサーバの遅延時間Ｔ'i (n,m)を用いて、変更に係る層における遅延時間を算出し、層遅延時間格納部１２１６に格納する（ステップＳ６７）。さらに、システム遅延時間算出部１２１７は、層遅延時間格納部１２１６に格納された各層における遅延時間を用いて、変更後のシステム全体の遅延時間を算出し、システム遅延時間格納部１２１８に格納する（ステップＳ６８）。
その後、入出力部１２１は、変更前と変更後の各遅延時間などを出力する（ステップＳ６９）。これにより、ユーザは、ＣＰＵ個数の変動に応じた遅延時間の変化を考察することができるようになる。例えばこの結果を用いてＣＰＵ個数を増加させた場合の効果を検討する。
次に、サーバ数変動時における性能予測について図１４を用いて説明する。ここでは、第ｎ層のサーバ数をＭnからＭ'nに変化させたときの推定遅延時間を求めるものとする。従って、入出力部１２１から第ｎ層のサーバ数Ｍ'nが入力され、遅延分析装置１２０の性能予測処理部１２１３が受け付ける（ステップＳ７１）。そして、性能予測処理部１２１３は、サーバ数の変更に応じて１リクエストあたりの消費ＣＰＵ時間を補正し、ＣＰＵ時間格納部１２０９に格納する（ステップＳ７３）。１リクエストあたりの消費ＣＰＵ時間１／μ(n,m)については、以下のように１／μ'(n,m)に変更する。また、性能予測処理部１２１３は、１リクエストあたりの消費ＣＰＵ時間の補正に応じて、ＣＰＵ使用率ρを補正し、ＣＰＵ使用率格納部１２０６に格納する（ステップＳ７５）。ＣＰＵ使用率ρについては、以下のようにρ'に変更する。
Figure 2006046297
 なお、α(n,m)は、１／μ(n,m)を算出する際に求めた切片であり、ＣＰＵ時間格納部１２０９に格納されているのでこれを用いる。
次に、サーバ遅延時間算出部１２１０は、ＣＰＵ使用率格納部１２０６に格納された変更後のＣＰＵ使用率ρ'及びＣＰＵ時間格納部１２０９に格納された変更後の１リクエストあたりの消費ＣＰＵ時間１／μ'(n,m)を用いて、変更後のサーバ遅延時間を算出し、サーバ遅延時間格納部１２１４に格納する（ステップＳ７７）。変更後のサーバ遅延時間Ｔ'i (n,m)は以下のように表される。
Figure 2006046297
そして、層遅延時間算出部１２１５は、サーバ遅延時間格納部１２１４に格納された変更後のサーバの遅延時間Ｔ'i (n,m)を用いて、各層における遅延時間を算出し、層遅延時間格納部１２１６に格納する（ステップＳ７９）。なお、本ステップにおいても性能予測処理部１２１３からのＭ'nを用いて以下のような計算を行う。
Figure 2006046297
なお、（１６）式からＬ'i nは、以下のようにも表される。
Figure 2006046297
さらに、システム遅延時間算出部１２１７は、層遅延時間格納部１２１６に格納された各層における遅延時間を用いて、変更後のシステム全体の遅延時間を算出し、システム遅延時間格納部１２１８に格納する（ステップＳ８１）。
その後、入出力部１２１は、変更前と変更後の各遅延時間などを出力する（ステップＳ８３）。これにより、ユーザは、サーバ個数の変動に応じた遅延時間の変化を考察することができるようになる。例えばこの結果を用いてサーバ個数を増加させた場合の効果を検討する。
以上本発明の実施例を説明したが、本発明はこれに限定するものではない。例えば、図４Ａ及び図４Ｂに示した機能ブロック図は一例であって、必ずしも実際のプログラム構成に対応しない場合もある。また、出力処理については、数値をそのまま表示するだけではなく、図１５に示すようなテーブル（１リクエストあたりの消費ＣＰＵ時間、ＣＰＵ使用率、サーバ毎の平均遅延時間、各層の平均遅延時間、遅延実測値、サーバ以外の推定遅延時間、各層の遅延時間の信頼度を単位時間ｉ毎に表示するテーブル）や、図１６に示すようなグラフ（横軸が時刻、縦軸が遅延時間を表し、Ｗｅｂサーバ（第１層）、アプリケーションサーバ（第２層）、ＤＢサーバ（第３層）、その他についての遅延時間の時間変化を表すグラフ）を生成して、表示させるようにしても良い。なお、図１６のグラフを見れば、９時から１２時の通常時には、ほぼＷｅｂサーバの遅延が全体の半分以上になっており（図１６中の部分Ａ）、１２時から１５時にＤＢサーバの一時的な負荷増大によりレスポンスが著しく低下しており（図１６中の部分Ｂ）、１８時以降サーバ以外の遅延時間が増加しており、何らかの問題が発生したかもしれないこと（図１６中の部分Ｃ）などを判断することができるようになる。
また、上で述べた遅延分析装置１２０は、コンピュータ装置であって、図１７に示すように、メモリ２５０１（記憶部）とＣＰＵ２５０３（処理部）とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。本発明の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。
図１は、本発明の原理を説明するための図である。 図２は、本発明の原理を説明するための図である。 図３は、本発明の実施例におけるシステム全体を説明するための図である。 図４Ａは、本発明の実施例における遅延時間分析装置の機能ブロック図である。 図４Ｂは、本発明の実施例における遅延時間分析装置の機能ブロック図である。 図５は、本発明の実施例におけるメインの処理フローを示す図である。 図６は、取得データの一例を示す図である。 図７（ａ）及び（ｂ）は、回帰計算を説明するための図である。 図８は、ビジネス時間に回帰計算の対象を限定する理由を説明するための図である。 図９は、信頼度算出処理の処理フローを示す図である。 図１０は、信頼度に応じた遅延時間の補正処理の処理フローを示す図である。 図１１（ａ）乃至（ｃ）は、信頼度に応じた遅延時間の補正処理の具体例を説明するための図である。 図１２は、リクエスト頻度変動時の遅延時間変化の推定処理の処理フローを示す図である。 図１３は、ＣＰＵ数変動時の遅延時間変化の推定処理の処理フローを示す図である。 図１４は、サーバ数変動時の遅延時間変化の推定処理の処理フローを示す図である。 図１５は、処理結果のテーブル化の一例を示す図である。 図１６は、処理結果のグラフ化の一例を示す図である。 図１７は、コンピュータの機能ブロック図である。

Claims (15)

  1. 複数のサーバを含むコンピュータ・システムのレスポンスに関する分析を行う分析装置であって、
    前記コンピュータ・システムから前記複数のサーバの各々のＣＰＵ使用率のデータを取得し、ＣＰＵ使用率格納部に格納する手段と、
    前記コンピュータ・システムにおいて生成される処理履歴データを取得し、前記コンピュータ・システムのユーザによるリクエスト頻度のデータを生成し、リクエスト頻度データ格納部に格納する手段と、
    前記ＣＰＵ使用率格納部に格納された各サーバのＣＰＵ使用率と前記リクエスト頻度格納部に格納された前記リクエスト頻度とを用いて、各前記サーバにおける平均遅延時間を推定し、サーバ遅延時間格納部に格納する推定手段と、
    を有する分析装置。
  2. 前記推定手段は、
    前記ＣＰＵ使用率格納部に格納された各前記サーバのＣＰＵ使用率と前記リクエスト頻度格納部に格納された前記リクエスト頻度と用いて、各前記サーバの１リクエストあたりの平均消費ＣＰＵ時間を推定し、消費ＣＰＵ時間格納部に格納する消費ＣＰＵ時間推定手段と、
    前記消費ＣＰＵ時間格納部に格納された各前記サーバの１リクエストあたりの平均消費ＣＰＵ時間と前記ＣＰＵ使用率格納部に格納された各サーバのＣＰＵ使用率とを用いて、各前記サーバにおける平均遅延時間を推定し、前記サーバ遅延時間格納部に格納するサーバ遅延時間推定手段と、
    を含む請求項１記載の分析装置。
  3. 前記消費ＣＰＵ時間推定手段が、
    予め指定された時間帯における各前記サーバのＣＰＵ使用率と前記リクエスト頻度とを用いて回帰分析を実施することにより、各前記サーバの１リクエストあたりの平均消費ＣＰＵ時間を推定する
    ことを特徴とする請求項２記載の分析装置。
  4. 前記サーバ遅延時間推定手段が、
    前記サーバの１リクエストあたりの平均消費ＣＰＵ時間と当該サーバにおける平均遅延時間との関係を表す係数値を当該係数値を決定する要素である前記ＣＰＵ使用率の所定単位毎及びＣＰＵ個数毎に格納するマトリクス格納部を参照して該当する係数値を読み出し、当該係数値と前記サーバの１リクエストあたりの平均消費ＣＰＵ時間とから前記サーバにおける平均遅延時間を算出する
    ことを特徴とする請求項２記載の分析装置。
  5. 前記コンピュータ・システムに含まれる複数のサーバが、実行する業務種別に応じてカテゴリ分けされている場合、当該カテゴリ毎に平均遅延時間を推定する手段
    をさらに含む請求項１記載の分析装置。
  6. 前記サーバ遅延時間格納部に格納されたデータを用いて、前記コンピュータ・システム全体の平均遅延時間を推定し、システム遅延時間格納部に格納する手段
    をさらに含む請求項１記載の分析装置。
  7. 前記コンピュータ・システムにおける、ユーザによるリクエストに対するレスポンス時間の平均実測値を取得し、平均実測値格納部に格納する手段と、
    前記平均実測値格納部に格納された平均実測値と前記システム遅延時間格納部に格納された前記コンピュータ・システム全体の平均遅延時間との差により、サーバ以外の箇所で発生した遅延時間を推定する手段と、
    をさらに含む請求項６記載の分析装置。
  8. 前記カテゴリ毎に、平均消費ＣＰＵ時間の総和とリクエスト頻度との相関係数を算出し、当該相関係数に基づき前記カテゴリ毎の平均遅延時間の信頼度を決定し、信頼度データ格納部に格納する手段と、
    前記信頼度データ格納部に格納された前記カテゴリ毎の平均遅延時間の信頼度に基づき、前記カテゴリ毎の平均遅延時間を補正し、記憶装置に格納する補正手段と、
    をさらに含む請求項７記載の分析装置。
  9. 前記補正手段が、
    前記カテゴリ毎の平均遅延時間を信頼度の高い順にソートする手段と、
    前記信頼度の高い順に前記カテゴリ毎の平均遅延時間を累積してゆき、累積された平均遅延時間が前記遅延実測値未満であって最大の値を有することとなる信頼度の順番を特定する手段と、
    特定された前記信頼度の順番の次の順番の遅延時間を、前記遅延実測値と前記信頼度の高い順に前記カテゴリ毎の平均遅延時間を特定された前記信頼度の順番まで累積することにより得られる値との差に補正する手段と、
    を含む請求項８記載の分析装置。
  10. リクエスト頻度が変更された場合、当該変更後のリクエスト頻度に応じて各前記サーバのＣＰＵ使用率を変更し、記憶装置に格納する手段と、
    前記記憶装置に格納された変更後の各前記サーバのＣＰＵ使用率を用いて、各前記サーバにおける平均遅延時間を推定し、記憶装置に格納する手段と、
    前記サーバ遅延時間格納部及び前記記憶装置に格納された変更前後の各前記サーバの平均遅延時間を比較可能な態様で出力する手段と、
    をさらに含む請求項１記載の分析装置。
  11. ＣＰＵ数が変更された場合、当該変更後のＣＰＵ数に応じて各前記サーバのＣＰＵ使用率を変更し、記憶装置に格納する手段と、
    前記記憶装置に格納された変更後の各前記サーバのＣＰＵ使用率と前記変更後のＣＰＵ数とを用いて、各前記サーバにおける平均遅延時間を推定し、記憶装置に格納する手段と、
    前記サーバ遅延時間格納部及び前記記憶装置に格納された変更前後の各前記サーバの平均遅延時間を比較可能な態様で出力する手段と、
    をさらに含む請求項１記載の分析装置。
  12. サーバ数が変更された場合、当該変更後のサーバ数に応じて各前記サーバの１リクエストあたりの平均消費ＣＰＵ時間を算出し、記憶装置に格納する手段と、
    ＣＰＵ個数と前記記憶装置に格納された変更後の各前記サーバの１リクエストあたりの平均消費ＣＰＵ時間とを用いて、変更後における各前記サーバのＣＰＵ使用率を算出し、記憶装置に格納する手段と、
    前記記憶装置に格納された変更後の各前記サーバの１リクエストあたりの平均消費ＣＰＵ時間と前記変更後における各前記サーバのＣＰＵ使用率とを用いて、変更後における各前記サーバの平均遅延時間を推定し、記憶装置に格納する手段と、
    をさらに含む請求項２記載の分析装置。
  13. 前記記憶装置に格納された前記変更後における各前記サーバの平均遅延時間と変更後のサーバ数とを用いて、前記コンピュータ・システムに含まれる前記複数のサーバを実行する業務種別に応じて分けることにより規定されるカテゴリ毎の平均遅延時間を推定し、記憶装置に格納する手段
    をさらに含む請求項１２記載の分析装置。
  14. 請求項１乃至１３のいずれか１つ記載の分析装置における各手段をコンピュータに実現させるためのプログラム。
  15. 複数のサーバを含むコンピュータ・システムのレスポンスに関する分析を行う分析方法であって、
    前記コンピュータ・システムから前記複数のサーバの各々のＣＰＵ使用率のデータを取得し、ＣＰＵ使用率格納部に格納するステップと、
    前記コンピュータ・システムにおいて生成される処理履歴データを取得し、前記コンピュータ・システムのユーザによるリクエスト頻度のデータを生成し、リクエスト頻度データ格納部に格納するステップと、
    前記ＣＰＵ使用率格納部に格納された各サーバのＣＰＵ使用率と前記リクエスト頻度格納部に格納された前記リクエスト頻度とを用いて、各前記サーバにおける平均遅延時間を推定し、サーバ遅延時間格納部に格納する推定ステップと、
    を含み、コンピュータにより実行される分析方法。
JP2006542174A 2004-10-28 2004-10-28 分析方法及び装置 Expired - Fee Related JP4180638B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2004/016051 WO2006046297A1 (ja) 2004-10-28 2004-10-28 分析方法及び装置

Publications (2)

Publication Number Publication Date
JPWO2006046297A1 true JPWO2006046297A1 (ja) 2008-05-22
JP4180638B2 JP4180638B2 (ja) 2008-11-12

Family

ID=36227549

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006542174A Expired - Fee Related JP4180638B2 (ja) 2004-10-28 2004-10-28 分析方法及び装置

Country Status (4)

Country Link
US (1) US8560667B2 (ja)
EP (1) EP1806658B1 (ja)
JP (1) JP4180638B2 (ja)
WO (1) WO2006046297A1 (ja)

Families Citing this family (45)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4711672B2 (ja) * 2004-12-24 2011-06-29 富士通株式会社 情報処理方法及びプログラム
US20070136302A1 (en) * 2005-12-12 2007-06-14 Microsoft Corporation Automated device blog creation
JP2007310836A (ja) * 2006-05-22 2007-11-29 Daiwa Securities Group Inc 評価装置及び設計装置、評価方法及び設計方法、評価用プログラム及び設計用プログラム並びに情報記録媒体
US8171133B2 (en) 2006-07-10 2012-05-01 Nec Corporation Management apparatus and management method for computer system
US8914774B1 (en) 2007-11-15 2014-12-16 Appcelerator, Inc. System and method for tagging code to determine where the code runs
US8954989B1 (en) 2007-11-19 2015-02-10 Appcelerator, Inc. Flexible, event-driven JavaScript server architecture
US8260845B1 (en) 2007-11-21 2012-09-04 Appcelerator, Inc. System and method for auto-generating JavaScript proxies and meta-proxies
US8719451B1 (en) 2007-11-23 2014-05-06 Appcelerator, Inc. System and method for on-the-fly, post-processing document object model manipulation
US8566807B1 (en) 2007-11-23 2013-10-22 Appcelerator, Inc. System and method for accessibility of document object model and JavaScript by other platforms
US8819539B1 (en) 2007-12-03 2014-08-26 Appcelerator, Inc. On-the-fly rewriting of uniform resource locators in a web-page
US8806431B1 (en) 2007-12-03 2014-08-12 Appecelerator, Inc. Aspect oriented programming
US8756579B1 (en) 2007-12-03 2014-06-17 Appcelerator, Inc. Client-side and server-side unified validation
US8938491B1 (en) 2007-12-04 2015-01-20 Appcelerator, Inc. System and method for secure binding of client calls and server functions
US8527860B1 (en) 2007-12-04 2013-09-03 Appcelerator, Inc. System and method for exposing the dynamic web server-side
US8285813B1 (en) 2007-12-05 2012-10-09 Appcelerator, Inc. System and method for emulating different user agents on a server
US8639743B1 (en) 2007-12-05 2014-01-28 Appcelerator, Inc. System and method for on-the-fly rewriting of JavaScript
US8335982B1 (en) 2007-12-05 2012-12-18 Appcelerator, Inc. System and method for binding a document object model through JavaScript callbacks
US20090217282A1 (en) * 2008-02-26 2009-08-27 Vikram Rai Predicting cpu availability for short to medium time frames on time shared systems
US8224624B2 (en) * 2008-04-25 2012-07-17 Hewlett-Packard Development Company, L.P. Using application performance signatures for characterizing application updates
US8291079B1 (en) 2008-06-04 2012-10-16 Appcelerator, Inc. System and method for developing, deploying, managing and monitoring a web application in a single environment
US8880678B1 (en) * 2008-06-05 2014-11-04 Appcelerator, Inc. System and method for managing and monitoring a web application using multiple cloud providers
US20090307347A1 (en) * 2008-06-08 2009-12-10 Ludmila Cherkasova Using Transaction Latency Profiles For Characterizing Application Updates
US7596620B1 (en) 2008-11-04 2009-09-29 Aptana, Inc. System and method for developing, deploying, managing and monitoring a web application in a single environment
US8019858B2 (en) * 2008-09-09 2011-09-13 International Business Machines Corporation System and method for utilizing system lag to send facts to an end user
US7925748B2 (en) * 2008-10-24 2011-04-12 International Business Machines Corporation System and method for managing system resources in a network environment
US7930395B2 (en) * 2008-12-01 2011-04-19 International Business Machines Corporation System and method for managing system resources in a network environment
US20110153828A1 (en) * 2009-12-17 2011-06-23 Korea Advanced Institute Of Science And Technology Load balancing apparatus and method for regulating load using the same
JP5418250B2 (ja) * 2010-01-26 2014-02-19 富士通株式会社 異常検出装置、プログラム、及び異常検出方法
CA2806549C (en) 2010-07-26 2014-10-28 Seven Networks, Inc. Context aware traffic management for resource conservation in a wireless network
EP2599003B1 (en) * 2010-07-26 2018-07-11 Seven Networks, LLC Mobile network traffic coordination across multiple applications
CA2798523C (en) 2010-11-22 2015-02-24 Seven Networks, Inc. Aligning data transfer to optimize connections established for transmission over a wireless network
JP5871192B2 (ja) * 2010-12-24 2016-03-01 日本電気株式会社 監視データ分析装置、監視データ分析方法および監視データ分析プログラム
WO2012086444A1 (ja) * 2010-12-24 2012-06-28 日本電気株式会社 監視データ分析装置、監視データ分析方法および監視データ分析プログラム
CN103116524A (zh) * 2011-11-16 2013-05-22 鸿富锦精密工业（深圳）有限公司 Cpu使用率调整系统及方法
JP5794181B2 (ja) 2012-03-15 2015-10-14 富士通株式会社 プログラム、分析方法、情報処理装置
JP6075226B2 (ja) 2013-06-26 2017-02-08 富士通株式会社 プログラム、仮想マシン管理方法および情報処理装置
JP6079476B2 (ja) 2013-06-26 2017-02-15 富士通株式会社 分析支援プログラム、分析支援装置、および分析支援方法
US10169182B2 (en) 2014-07-31 2019-01-01 International Business Machines Corporation Monitoring levels of utilization of device
US9537740B2 (en) 2014-07-31 2017-01-03 International Business Machines Corporation Monitoring device usage
US9998347B2 (en) 2014-07-31 2018-06-12 International Business Machines Corporation Monitoring device usage
US10102103B2 (en) 2015-11-11 2018-10-16 International Business Machines Corporation System resource component utilization
JP6878068B2 (ja) * 2017-03-21 2021-05-26 株式会社エヌ・ティ・ティ・データ 識別情報付与システム及び識別情報付与方法
US10649876B2 (en) 2017-04-20 2020-05-12 International Business Machines Corporation Maintaining manageable utilization in a system to prevent excessive queuing of system requests
US10394643B2 (en) * 2017-08-16 2019-08-27 National Instruments Corporation Distributed run-time auto-calculation of measurement uncertainty
US11023280B2 (en) 2017-09-15 2021-06-01 Splunk Inc. Processing data streams received from instrumented software using incremental finite window double exponential smoothing

Family Cites Families (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS5255350A (en) 1975-10-30 1977-05-06 Nec Corp System recomposition control unit
JPS5851362A (ja) 1981-09-24 1983-03-26 Hitachi Ltd 計算機システムの性能予測方式
JPS6237763A (ja) * 1985-08-12 1987-02-18 Fujitsu Ltd キヤパシテイプランニングにおける捕捉率自動算出方式
JPH05324358A (ja) * 1992-05-20 1993-12-07 Hitachi Ltd 性能予測装置
JPH05334102A (ja) * 1992-05-28 1993-12-17 Nec Corp ジョブ実行状況予測装置
JPH0695931A (ja) * 1992-09-14 1994-04-08 Toshiba Corp システム実行性能評価支援装置
WO1994009429A1 (en) 1992-10-13 1994-04-28 Zitel Corporation Method and system for computer performance evaluation
JPH09305417A (ja) 1996-05-13 1997-11-28 Nec Corp Ｃｐｕ使用率最適化方式
US6230183B1 (en) * 1998-03-11 2001-05-08 International Business Machines Corporation Method and apparatus for controlling the number of servers in a multisystem cluster
JP3270012B2 (ja) * 1998-09-08 2002-04-02 富士通株式会社 ネットワークサーバ負荷検出装置、割当装置および方法
US6243105B1 (en) * 1998-11-19 2001-06-05 Ncr Corporation Drill-down method to historical data in a performance monitor using a platform independent program
JP4739472B2 (ja) * 1998-12-04 2011-08-03 新日鉄ソリューションズ株式会社 性能予測装置および方法、記録媒体
US6557035B1 (en) * 1999-03-30 2003-04-29 International Business Machines Corporation Rules-based method of and system for optimizing server hardware capacity and performance
JP3663968B2 (ja) * 1999-04-14 2005-06-22 日本電気株式会社 マルチタスクシステムの性能予測システム及び予測方法並びにその方法プログラムを記録した記録媒体
JP2001109638A (ja) * 1999-10-06 2001-04-20 Nec Corp 推定伸長率に基づくトランザクション負荷分散方法及び方式並びにコンピュータ可読記録媒体
JP2002099448A (ja) * 2000-09-21 2002-04-05 Ntt Data Corp 性能監視装置、及びその方法
JP2002132543A (ja) 2000-10-25 2002-05-10 Hitachi Ltd 計算機システムの管理方法
US6671658B2 (en) 2000-12-23 2003-12-30 Hewlett-Packard Development Company, L.P Method for service level estimation in an operating computer system
JP2002268922A (ja) 2001-03-09 2002-09-20 Ntt Data Corp Ｗｗｗサイトの性能監視装置
JP2002342182A (ja) * 2001-05-21 2002-11-29 Hitachi Ltd ネットワークシステムにおける運用管理の支援システム
JP2003032306A (ja) 2001-07-19 2003-01-31 Hitachi Electronics Service Co Ltd Ｗｅｂサーバの回線毎の応答性能予測システム
US6792393B1 (en) * 2001-12-03 2004-09-14 At&T Corp. System and method for diagnosing computer system operational behavior
JP2003178040A (ja) * 2001-12-10 2003-06-27 Hitachi Information Systems Ltd ウェブサイトの構成決定支援方法
JP2003263342A (ja) * 2002-03-07 2003-09-19 Telecommunication Advancement Organization Of Japan 情報処理装置の監視装置および監視方法並びにそのプログラム
US7222245B2 (en) * 2002-04-26 2007-05-22 Hewlett-Packard Development Company, L.P. Managing system power based on utilization statistics
JP2004005135A (ja) * 2002-05-31 2004-01-08 Nippon Telegr & Teleph Corp <Ntt> サーバ性能推定方法およびサーバ性能推定装置
JP2004021756A (ja) * 2002-06-19 2004-01-22 Hitachi Ltd 情報システム性能の統計的予測方法
JP2004046734A (ja) * 2002-07-15 2004-02-12 Fuji Electric Holdings Co Ltd Ｗｅｂシステム性能予測装置、Ｗｅｂシステム性能予測方法、及びプログラム
JP2004193816A (ja) * 2002-12-10 2004-07-08 Hitachi Ltd ネットワーク評価システム
JP2004272582A (ja) * 2003-03-07 2004-09-30 Toshiba Corp 計算機システムの性能予測プログラムおよび設計支援システム

Also Published As

Publication number Publication date
JP4180638B2 (ja) 2008-11-12
US8560667B2 (en) 2013-10-15
EP1806658A1 (en) 2007-07-11
EP1806658B1 (en) 2016-04-13
US20070214261A1 (en) 2007-09-13
EP1806658A4 (en) 2009-07-29
WO2006046297A1 (ja) 2006-05-04

Similar Documents

Publication Publication Date Title
JP4180638B2 (ja) 分析方法及び装置
US8296426B2 (en) System and method for performing capacity planning for enterprise applications
US7243049B1 (en) Method for modeling system performance
Gmach et al. Capacity management and demand prediction for next generation data centers
JP6571914B2 (ja) 情報の複数のドメインを組合せることによる仕事の実施データ内の異常の検知
US9772923B2 (en) Fast OLAP for real user measurement of website performance
US9389668B2 (en) Power optimization for distributed computing system
US20110016469A1 (en) Deleting data stream overload
CN107707431A (zh) 一种面向云平台的数据安全监测方法及系统
JP5954430B2 (ja) 運用管理装置、及び、運用管理方法
US20190026108A1 (en) Recommendations based on the impact of code changes
JP2002268922A (ja) Ｗｗｗサイトの性能監視装置
WO2004053726A2 (en) Apparatus and methods for classification of web sites
Zhang et al. Real-time performance prediction for cloud components
JP4843379B2 (ja) 計算機システムの開発プログラム
CN107844496B (zh) 统计信息输出方法及装置
Awad et al. On the predictive properties of performance models derived through input-output relationships
US20220050761A1 (en) Low overhead performance data collection
CN111274112A (zh) 应用程序压测方法、装置、计算机设备和存储介质
Jihan et al. PERF-Expert: Novel Approach for Dynamically Forecasting the Performance of Cloud-Based Integrations with Zero Performance Tests
CN117435509B (zh) 接口数据的动态比对方法、动态比对设备和存储介质
Bogárdi-Mészöly et al. Novel Models and Algorithms for Queue Limit Modeling
Casale et al. Versatile models of systems using map queueing networks
CN111400152A (zh) 数据处理方法以及第一服务器和第二服务器
CN117952312A (en) Cold and hot load prediction method and device, storage medium and computer equipment

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080513

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080710

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20080826

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20080827

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110905

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120905

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120905

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130905

Year of fee payment: 5

LAPS Cancellation because of no payment of annual fees