(57)【要約】【課題】応答時間を許容範囲内に維持できる多重度制限値の上限を判断する。【解決手段】判断手段２により、各トランザクションの応答時間が、予め指定された許容時間を超えているか否かが判断される。第１の計算手段３により、複数のトランザクションそれぞれのトランザクション情報に基づいて、集計区間内に特定の階層のサーバで並列に実行された処理の平均の多重度が計算される。第２の計算手段４により、応答時間が許容時間を超えていないトランザクションそれぞれのトランザクション情報に基づいて、集計区間の合計進行量が計算される。そして、決定手段５により、多重度の増加に伴って合計進行量が低下し始める多重度の閾値が決定される。【選択図】図１
2014038578.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータに、
複数階層システム内の複数のサーバで分析対象期間内に連携して実行された複数のトランザクションそれぞれのトランザクション情報に、各階層のサーバで実行された処理の実行期間が示されており、該トランザクション情報に基づいて、各トランザクションの応答時間が、予め指定された許容時間を超えているか否かを判断し、
前記複数のトランザクションそれぞれのトランザクション情報に基づいて、前記分析対象期間を細分化して得られる集計区間ごとに、集計区間内に特定の階層のサーバで並列に実行された処理の平均の多重度を計算し、
応答時間が前記許容時間を超えていないトランザクションそれぞれのトランザクション情報に基づいて、集計区間ごと、集計区間内に前記特定の階層のサーバで実行された処理のうち、応答時間が前記許容時間を超えていないトランザクションにおいて実行された処理それぞれの進行量を合計した合計進行量を計算し、
集計区間ごとの多重度と合計進行量とに基づいて、多重度の増加に伴って合計進行量が低下し始める、多重度の閾値を決定する、
処理を実行させるプログラム。
【請求項２】
前記コンピュータに、さらに、
集計区間ごとの多重度と合計進行量とに基づいて、多重度の増加に伴って、多重度の増加量に対する合計進行量の増加量が所定値以下となり始める、多重度の他の閾値を決定し、
前記特定の階層のサーバにおいて、並列で実行可能な処理の許容数の上限まで処理を並列実行したときの該サーバでの多重度が、前記閾値と前記他の閾値との間の時間となるように、該サーバに対して、並列で実行可能な処理の許容数を設定する、
処理を実行させる請求項１記載のプログラム。
【請求項３】
前記閾値の決定では、前記コンピュータに、
集計区間それぞれの多重度の最小値から最大値までの範囲を細分化して得られる細分化区間ごとに、細分化区間内の多重度を有する集計区間から合計進行量の平均値を計算し、複数の細分化区間の間で合計進行量の平均値を比較し、多重度の増加に伴って合計進行量が低下し始める多重度の閾値を決定する、
処理を実行させる請求項１または２のいずれかに記載のプログラム。
【請求項４】
前記コンピュータに、さらに、
集計区間ごとの多重度と合計進行量とに基づいて、多重度の増加量に対する合計進行量の増加量が所定値以下となる、多重度の他の閾値を決定する処理を実行させ、
前記閾値の決定では、前記コンピュータに、
複数の細分化区間の中から、前記他の閾値で示される多重度を含む細分化区間を選択し、多重度の増加に伴って、該選択した細分化区間との間で多重度の平均値に有意な差が生じ始める細分化区間を検出し、検出された細分化区間内の多重度を、前記閾値に決定する、
処理を実行させる請求項３記載のプログラム。
【請求項５】
多重度の平均値に有意な差が生じ始める細分化区間の検出では、前記コンピュータに、ｔ検定により有意な差の有無を判断する処理を実行させる請求項４記載のプログラム。
【請求項６】
集計区間で実行された処理の進行量は、該処理を依頼した処理要求に応じて実行される処理全体のうちの、該集計区間で実行された割合に、各処理種別に属する処理の低負荷時の処理時間に基づく重み付けを行った値であることを特徴とする請求項１乃至５のいずれかに記載のプログラム。
【請求項７】
前記特定の階層は、前記複数階層システムにおいて、処理能力の限界に達しているサーバが属する階層である請求項１乃至６のいずれかに記載のプログラム。
【請求項８】
コンピュータが、
複数階層システム内の複数のサーバで分析対象期間内に連携して実行された複数のトランザクションそれぞれのトランザクション情報に、各階層のサーバで実行された処理の実行期間が示されており、該トランザクション情報に基づいて、各トランザクションの応答時間が、予め指定された許容時間を超えているか否かを判断し、
前記複数のトランザクションそれぞれのトランザクション情報に基づいて、前記分析対象期間を細分化して得られる集計区間ごとに、集計区間内に特定の階層のサーバで並列に実行された処理の平均の多重度を計算し、
応答時間が前記許容時間を超えていないトランザクションそれぞれのトランザクション情報に基づいて、集計区間ごと、集計区間内に前記特定の階層のサーバで実行された処理のうち、応答時間が前記許容時間を超えていないトランザクションにおいて実行された処理それぞれの進行量を合計した合計進行量を計算し、
集計区間ごとの多重度と合計進行量とに基づいて、多重度の増加に伴って合計進行量が低下し始める多重度の閾値を決定する、
処理を実行する分析方法。
【請求項９】
複数階層システム内の複数のサーバで分析対象期間内に連携して実行された複数のトランザクションそれぞれのトランザクション情報に、各階層のサーバで実行された処理の実行期間が示されており、該トランザクション情報に基づいて、各トランザクションの応答時間が、予め指定された許容時間を超えているか否かを判断する判断手段と、
前記複数のトランザクションそれぞれのトランザクション情報に基づいて、前記分析対象期間を細分化して得られる集計区間ごとに、集計区間内に特定の階層のサーバで並列に実行された処理の平均の多重度を計算する第１の計算手段と、
応答時間が前記許容時間を超えていないトランザクションそれぞれのトランザクション情報に基づいて、集計区間ごと、集計区間内に前記特定の階層のサーバで実行された処理のうち、応答時間が前記許容時間を超えていないトランザクションにおいて実行された処理それぞれの進行量を合計した合計進行量を計算する第２の計算手段と、
集計区間ごとの多重度と合計進行量とに基づいて、多重度の増加に伴って合計進行量が低下し始める多重度の閾値を決定する決定手段と、
を有する情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータシステムの分析を行うプログラム、分析方法、および情報処理装置に関する。
【背景技術】
【０００２】
複数のコンピュータが階層的に処理を分担する複数階層システムにおいて、システム内の各階層が受け付ける処理の多重度（同時並行に実行する処理の個数）は、一般的には、事前に設定された多重度制限値を上回らない範囲で動的に変化する。多重度制限値は、同時に実行が許される処理の最大数である。なお、処理の多重度が多重度制限値に固定される場合もある。いずれの場合も、各階層のサーバでは、多重度制限値を超えて処理の多重度を上げることができない。しかも、複数階層システムでは、各階層における多重度制限値は、階層間での設定値の組み合わせによって、システム全体の処理性能に大きな影響を及ぼす。例えば、ある階層のサーバにおける多重度制限値が少なすぎた場合、その階層がボトルネックとなり、システム全体の処理性能を低下させてしまう。そのため、各階層において多重度制限値を適切に設定することは重要である。
【０００３】
多重度制限値の適切な設定値を求める手法の１つとしては、負荷生成器でのベンチマークを繰り返す手法が考えられる。例えば、対象サーバーシステムの各処理多重度におけるスループットとレスポンスを計測し、対象サーバーシステムのトランザクション密度曲線を取得することが考えられている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００４−３０２５４７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで、システムの最大性能を発生させるために必要な多重度は、様々な条件によって細かく変動する。従来技術で求めた最適値に多重度制限値を設定した場合、様々な変動要因によって、最大性能を達成できないことが発生し得る。例えば、いずれかの階層での処理時間が動的に変化したり、複数階層システムへの負荷が一定ではなくて乱高下しながら到着したりする場合などである。このような場合には、多めの多重度制限値が余裕として寄与して、システムの性能が安定するという側面がある。
【０００６】
ただし、多重度制限値が大きすぎれば、並列効果を最大限発揮できる範囲を超えて多重度が高くなったときに、限られたハードウェア資源をその高い多重度の処理で分配することになる。その結果、応答時間が平均的に悪化する。多重度制限値を上げたことによって増加する応答時間は、例えそれが２倍になったとしても、エンドユーザにおいて１０ｍｓ→２０ｍｓというような増加であれば、人間にはその違いが体感できないので問題とはならない。従って、応答時間が許容範囲内に抑えられていれば、サーバの多重度制限値を最適値よりも大きくし、これによりシステムの安定性を向上させることができる。
【０００７】
しかし、従来の技術では、応答時間を許容範囲内に維持できる多重度制限値の上限を見つけ出すことができない。そのため、多重度制限値に対して、性能を最大限発揮させる最適値よりも大きな値を設定しようとしても、応答時間を許容範囲内に維持したまま、どの程度まで多重度制限値を大きくすることが可能なのが不明である。
【０００８】
１つの側面では、本発明は、応答時間を許容範囲内に維持できる多重度制限値の上限を判断するプログラム、分析方法、および情報処理装置を提供することを目的とする。
【課題を解決するための手段】
【０００９】
１つの案では、コンピュータに以下の処理を実行させるプログラムを提供する。該プログラムに基づいて、コンピュータは、複数階層システム内の複数のサーバで、分析対象期間内に連携して実行された複数のトランザクションそれぞれのトランザクション情報に、各階層のサーバで実行された処理の実行期間が示されており、該トランザクション情報に基づいて、各トランザクションの応答時間が、予め指定された許容時間を超えているか否かを判断する。次にコンピュータは、前記複数のトランザクションそれぞれのトランザクション情報に基づいて、前記分析対象期間を細分化して得られる集計区間ごとに、集計区間内に特定の階層のサーバで並列に実行された処理の平均の多重度を計算する。次にコンピュータは、応答時間が前記許容時間を超えていないトランザクションそれぞれのトランザクション情報に基づいて、集計区間ごと、集計区間内に前記特定の階層のサーバで実行された処理のうち、応答時間が前記許容時間を超えていないトランザクションにおいて実行された処理それぞれの進行量を合計した合計進行量を計算する。そしてコンピュータは、集計区間ごとの多重度と合計進行量とに基づいて、多重度の増加に伴って合計進行量が低下し始める、多重度の閾値を決定する。
【発明の効果】
【００１０】
１態様によれば、応答時間を許容範囲内に維持できる多重度制限値の上限を判断できる。
【図面の簡単な説明】
【００１１】
【図１】第１の実施の形態に係る情報処理装置の機能構成の一例を示す図である。
【図２】第２の実施の形態のシステムの全体構成を示す図である。
【図３】第２の実施の形態に用いる分析サーバのハードウェアの一構成例を示す図である。
【図４】第２の実施の形態に係る分析サーバの機能の一例を示すブロック図である。
【図５】分析処理の手順の一例を示すフローチャートである。
【図６】キャプチャデータ記憶部のデータ構造の一例を示す図である。
【図７】性能分析処理の手順の一例を示すフローチャートである。
【図８】メッセージデータ記憶部のデータ構造の一例を示す図である。
【図９】抽象化ルール記憶部のデータ構造の一例を示す図である。
【図１０】ＨＴＴＰのプロトコルのジョブ種の例を示す図である。
【図１１】ＤＢのプロトコルのジョブ種の例を示す図である。
【図１２】ジョブ種が識別されたメッセージフローの一例を示す図である。
【図１３】メッセージフロー情報記憶部のデータ構造の一例を示す図である。
【図１４】階層別性能分析処理の手順の一例を示すフローチャートである。
【図１５】集計区間への分割例を示す図である。
【図１６】実行期間の集計区間への振り分け例を示す図である。
【図１７】並列で処理が実行される状況を示す図である。
【図１８】スループット・多重度算出処理の手順の一例を示すフローチャートである。
【図１９】性能分析時の集計区間情報記憶部のデータ構造の一例を示す図である。
【図２０】正規化スループット値記憶部のデータ構造の一例を示す図である。
【図２１】スループットの時系列推移の一例を示す図である。
【図２２】多重度の時系列推移の一例を示す図である。
【図２３】多重度とスループットとの関係の一例を示す散布図である。
【図２４】飽和多重度算出処理の一例を示すフローチャートである。
【図２５】ボトルネック判定処理の手順の一例を示すフローチャートである。
【図２６】多重度制御処理の手順の一例を示すフローチャートである。
【図２７】ＳＬＡ充足スループット計算処理の手順の一例を示すフローチャートである。
【図２８】ＳＬＡ充足スループット算出から除外されるジョブの例を示す図である。
【図２９】多重度分析時の集計区間情報記憶部のデータ構造の一例を示す図である。
【図３０】多重度とＳＬＡ充足スループットとの関係を示す散布図である。
【図３１】多重度制限値の下限値算出処理の手順の一例を示すフローチャートである。
【図３２】多重度制限値の上限値の算出時にｔ検定が行われる多重度区間の一例を示す図である。
【図３３】多重度制限値の上限値算出処理の手順の一例を示す図である。
【図３４】多重度設定処理の手順の一例を示すフローチャートである。
【発明を実施するための形態】
【００１２】
以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第１の実施の形態〕
第１の実施の形態は、応答時間が許容時間以下のトランザクションの処理のみから処理の合計進行量を計算し、多重度の増加に伴って合計進行量が低下し始める多重度の閾値を求めるようにしたものである。このようにして求められた閾値は、応答時間を許容範囲内に維持できる多重度制限値の上限である。
【００１３】
図１は、第１の実施の形態に係る情報処理装置の機能構成の一例を示す図である。情報処理装置は、記憶手段１、判断手段２、第１の計算手段３、第２の計算手段４、および決定手段５を有する。
【００１４】
記憶手段１は、複数階層システム内の複数のサーバで、分析対象期間内に連携して実行された複数のトランザクションそれぞれのトランザクション情報６を記憶する。トランザクション情報６には、各階層のサーバで実行された処理の実行期間が示されている。
【００１５】
判断手段２は、トランザクション情報６に基づいて、各トランザクションの応答時間が、予め指定された許容時間を超えているか否かを判断する。トランザクションの応答時間は、例えば複数階層システムの最上位層のサーバがリクエストを受信してからレスポンスを送信するまでの時間である。許容時間は、例えば、ユーザが処理の応答を待たされても気にならない程度の時間が設定される。
【００１６】
第１の計算手段３は、複数のトランザクションそれぞれのトランザクション情報に基づいて、分析対象期間を細分化して得られる集計区間ごとに、集計区間内に特定の階層のサーバで並列に実行された処理の平均の多重度を計算する。多重度は、並列に実行された処理の数である。平均の多重度は、例えば集計区間内で実行された処理それぞれの実行に費やされた時間を合計した合計処理時間を、集計区間の時間幅で除算することで求めることができる。特定の階層は、例えば、複数階層システムにおいて、処理能力の限界に達しているサーバが属する階層である。第１の計算手段３は、計算した多重度を、例えば集計区間に対応付けて管理テーブル７に設定する。管理テーブル７は、例えば、メモリに記憶された情報テーブルである。
【００１７】
第２の計算手段４は、応答時間が前記許容時間を超えていないトランザクションそれぞれのトランザクション情報に基づいて、集計区間ごと、合計進行量を計算する。合計進行量は、集計区間内に特定の階層のサーバで実行された処理のうち、応答時間が許容時間を超えていないトランザクションにおいて実行された処理それぞれの進行量の合計である。第２の計算手段４は、例えば集計区間に対応付けて、合計進行量を管理テーブル７に設定する。
【００１８】
決定手段５は、集計区間ごとの多重度と合計進行量とに基づいて、多重度の増加に伴って合計進行量が低下し始める多重度の閾値を決定する。例えば決定手段５は、管理テーブル７を参照することで、集計区間ごとの多重度と合計進行量とを取得する。決定手段５は、例えば集計区間それぞれの多重度の最小値から最大値までの範囲を細分化して得られる細分化区間ごとに、細分化区間内の多重度を有する集計区間から合計進行量の平均値を計算する。そして決定手段５は、複数の細分化区間の間で合計進行量の平均値を比較し、多重度の増加に伴って合計進行量が低下し始める多重度の閾値を決定する。
【００１９】
このような機能を有する情報処理装置によれば、判断手段２により、各トランザクションの応答時間が、予め指定された許容時間を超えているか否かが判断される。例えば図１の例では、トランザクション情報６ａに示されるトランザクションの応答時間は、許容時間を超過している。またトランザクション情報６ｂに示されるトランザクションの応答時間は、許容時間以内である。
【００２０】
また第１の計算手段３により、複数のトランザクションそれぞれのトランザクション情報に基づいて、集計区間内に特定の階層のサーバで並列に実行された処理の平均の多重度が計算される。図１の例では、データベース（ＤＢ）層のサーバの多重度が計算されている。
【００２１】
さらに第２の計算手段４により、応答時間が許容時間を超えていないトランザクションそれぞれのトランザクション情報に基づいて、集計区間の合計進行量が計算される。例えばトランザクション情報６ａで示されたトランザクションは応答時間が許容時間を超過しているため、合計進行量の計算には使用されない。トランザクション情報６ｂで示されたトランザクションは応答時間が許容時間以下であるため、トランザクション情報６ｂ内のＤＢサーバにおける処理により進行量は、合計進行量に加算される。
【００２２】
そして、決定手段５により、多重度の増加に伴って合計進行量が低下し始める多重度の閾値が決定される。
このようにして決定された閾値は、応答時間を許容範囲内に維持できる多重度制限値の上限である。すなわち、応答時間が許容時間を超過したトランザクションが発生していない集計区間については、最大性能を発揮する多重度よりも多重度が多くなると、各処理の処理時間が平均的に増加する。このとき、並行して実行している処理の数も多いため、処理時間が増加しても合計進行量の変動は少ない。
【００２３】
応答時間が許容時間を超過したトランザクションが発生している集計区間については、応答時間が許容時間を超過したトランザクションに属する処理の進行量を除外して、合計進行量が計算される。他方、多重度の計算には、応答時間が許容時間を超過したトランザクションに属する処理も含まれている。そのため多重度の増加に伴い、応答時間が許容時間を超過するトランザクションが発生しだすと、合計進行量が低下し始める。換言すると、合計進行量が低下し始めた多重度の閾値が、応答時間が許容時間を超過したトランザクションが発生し始めた多重度であり、要求される応答時間を満たすことができる多重度制限値の上限値である。
【００２４】
このようにして、システムに要求される性能に応じ、その性能を満たす範囲での多重度の上限値を求めることができる。ここで、システムの最大性能を発生させる最低限の多重度以上で、決定した上限値以下の範囲でサーバの多重度制限値を設定すれば、システムに要求される性能を維持できる範囲内での、処理要求の増加に対するシステムの許容度を高めることができる。
【００２５】
なお図１に示した判断手段２、第１の計算手段３、第２の計算手段４、および決定手段５は、情報処理が有するＣＰＵ（Central Processing Unit）により実現することができる。また記憶手段１は、情報処理装置が有するＲＡＭ（Random Access Memory）やハードディスクドライブ（ＨＤＤ:Hard Disk Drive）などにより実現することができる。
【００２６】
また、図１に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。
〔第２の実施の形態〕
次に第２の実施の形態について説明する。なお、以下の説明では、第１の実施の形態における合計進行量の一例として、サーバにおけるスループットを用いる。また第１の実施の形態における許容時間の一例として、ＳＬＡ（Service Level Agreement）を用いる。ＳＬＡは、ユーザに対するサービスの保証内容である。第２の実施の形態では、ＳＬＡにおいて、ユーザからの処理要求に対する応答時間に対する許容時間が指定されているものとする。さらに第２の実施の形態では、第１の実施の形態における処理の一例として、各サーバでのジョブを用いる。
【００２７】
まず、第２の実施の形態において解決する課題について説明する。
従来の技術では、サーバーシステムにおいて最も好ましい性能を発揮することができる多重度制限値が求められていた。しかし、性能を最大限に発揮する多重度となるように、各サーバの多重度制限値を設定すると、以下のような問題が生じる。
【００２８】
第１の問題は、サーバーシステムにおいて最も好ましい性能を発揮することができる多重度より各サーバでの多重度制限値を多く設定することができる、許容範囲が不明なことである。
【００２９】
一般に、ハードウェアの性能にゆとりがある状況や、システムが想定通りにスムーズに動作している場合は、多重度制限値は小さく設定しておくのがよい。なぜならば、第１に、並列効果が出る範囲を超えて多重度が高くなると、限られたハードウェア資源をその高い多重度の処理で分配することになるので、その分だけ平均的に応答時間が悪化するからである。また、第２に、多重度が高くなると様々なオーバヘッドが生じて、スループットが悪化することがあるからである。
【００３０】
一方で、最大スループットを発生させるために必要な多重度は、様々な条件によって細かく変動する。多重度制限値を最適値に設定した場合、様々な変動要因によって、最大スループットを達成できないことが発生し得る。例えば、いずれかの階層での処理時間が動的に変化したり、複数階層システムへの負荷が一定ではなくて乱高下しながら到着したりする場合などである。このような場合には、多めの多重度制限値が余裕として寄与して、システムの性能が安定するという側面がある。この場合、多重度制限値を上げたことによって、処理の多重度が増加し、応答時間増加する。増加する応答時間は、例えそれが２倍になったとしても、エンドユーザにおいて１０ｍｓ→２０ｍｓというような増加であれば、人間にはその違いが体感できないので問題とはならない。一般に、このエンドユーザにおけるリクエスト当たりの許容可能な応答時間はＳＬＡとして規定されるので、それを満たしている範囲においては、応答時間の増加は問題ないと考えることができる。つまり、処理の多重度の増加に伴って応答時間が増加した時に、上記のＳＬＡを満たさないリクエストが発生し始めるまでは、各階層における多重度の増加は問題にならない。
【００３１】
このように、既存技術には、このような許容可能な多重度制限値の上限を見積もることができないという問題がある。
第２の問題は、もし既存の技術で、許容可能な多重度制限値の上限値を見積もろうとしても、適切な多重度制限値を見つけるために必要な性能測定回数が膨大となることである。
【００３２】
最適な多重度制限値を見つけるために繰り返す必要のある性能測定回数は、以下の２つの積となる。
・１つの多重度制限値において、その設定における最大性能を求めるために入力多重度を上げていきながら繰り返す性能測定
・各階層の多重度制限値を変更しながら上記を繰り返し実行し、性能指標が最適となる各階層の多重度制限値の組み合わせを求める性能測定
この２番目の性能測定は、各階層の多重度制限値の組み合わせなので、階層数が増えるにつれて爆発的に増加する。色々な既存の最適解探索手法を用いて組み合わせ数を削減しても、２番目の性能測定回数が多大な数になることは避けられない。このような２番目の性能測定回数と、１番目の性能測定回数との積が、全体の性能測定回数なので、必要な測定回数は膨大になるのが避けられない。
【００３３】
そこで、第２の実施の形態では、上記の問題点を解決するために、次のような手段をとる。
まず、第２の実施の形態では、前提として以下の技術を実現する。
・各階層における多重度とスループットの関係の精密な測定
・各階層間で、１つのユーザリクエストによって生成されたシステム内の一連の処理の、プロトコルを跨ってメッセージ間の紐付け
・ボトルネックとなっている階層の特定
第２の実施の形態では、ボトルネックとなっている階層を対象に、許容条件を満たす多重度制限値の範囲（下限値と上限値）を見つける。ボトルネックとなっている階層の多重度制限値だけに注力する理由は下記の通りである。
【００３４】
第１の理由は、複数階層システム全体で、どの階層にもボトルネックが発生していない状態では処理能力に余裕があって短時間で処理が終わることである。そのため、各階層共に同時に実行されるジョブの数は少なくなり、多重度制限値をどのように設定しておいても、複数階層システム全体に与える性能影響は大きくない。
【００３５】
第２の理由は、ボトルネックが発生している状態では、ボトルネック層の多重度制限値は、複数階層システム全体の性能に大きな影響を与えるが、他の階層の多重度制限値はあまり大きな影響を与えないことである。ボトルネック層より下位の階層は、処理能力に余裕があるので同時に実行されるジョブの数は少なくなり、多重度制限値をどのような値に設定していても性能には殆ど影響がない。ボトルネック層より上の階層では、ボトルネック層の多重度制限値よりも一定の割合で多い多重度制限値にしておけば問題ない。すなわち、ボトルネック層よりも上の階層においては、処理能力に余裕が残っているので、多重度制限値を大きく設定しておいてオーバヘッドが発生したとしても、それが複数階層システム全体の性能に与える影響は無視できるほど小さい。
【００３６】
第２の実施の形態では、複数階層システムの中でボトルネックとなっている階層について、以下の手順で、許容できる範囲の多重度制限値を求める。
１．ボトルネックとなっている階層について、多数の測定データを得る。
２．それぞれの測定データに対して、それぞれ多重度とＳＬＡ充足スループットを計算する。
３．得られた（多重度、ＳＬＡ充足スループット）の組から両者の関係を求め、ＳＬＡ充足スループットが最大値を記録する範囲を、多重度の適切な範囲（下限値と上限値）とする。
【００３７】
ここで、多重度とＳＬＡ充足スループットの定義は下記の通りである。
・多重度
その区間において同時処理されたジョブ数の平均値である。
・ＳＬＡ充足スループット
スループット算出時に、各ジョブの生成元となっている最上位階層のユーザリクエストに対する応答時間を調べ、それがＳＬＡを充足しているか調べる。充足していない場合は、そのユーザリクエストに基づいてボトルネック層で実行されたジョブを、ボトルネック層で実行されたジョブ群から除外する。そして、除外されずに残存したボトルネック層のジョブから算出した、ボトルネック層におけるスループットを、ＳＬＡ充足スループットとする。
【００３８】
上記１．２．３．の手順によって、適切な多重度制限値の下限値と上限値が求められる理由は下記の通りである。
・下限値
多重度とスループットの関係は、多重度が増えるにつれて、並列効果が生じている間はスループットが増加するが、並列効果が生じなくなるとスループットは増加しなくなる。多重度の増加に伴うスループットの増加がなくなった時点での多重度は、最大スループットを発生させるための最低限の多重度である。従って、この多重度を、多重度制限値の下限値とする。このことは、スループットが前述したＳＬＡ充足スループットとなっても同じことである。
・上限値
並列効果が発生する範囲を超えて多重度が増加すると、スループットは増加せずに多重度だけが上がっていくことになる。この状態においては、多重度の増加は単に各ジョブの応答時間を平均的に増加させるだけである。その結果として、上位階層における待ち時間を増やし、最終的には最上位の階層における、エンドユーザの発行したリクエストに対する応答時間が増加する結果となる。ただし、この応答時間の増加は、それがＳＬＡを満たしている範囲では問題とはならない。すなわち、どこまで多重度を増やして大丈夫かということは、最上位の階層において応答時間がＳＬＡを満たさないリクエストが発生してくる範囲まで、と考えることができる。ＳＬＡ充足スループットは、最上位の階層における応答時間のＳＬＡ違反を各階層のスループットに反映させたものであり、これが最大値を記録する多重度の範囲が、許容可能な多重度制限値の上限値となる。
【００３９】
第２の実施の形態で上記機能を実現するために、ネットワーク上でのアプリケーションの外部挙動を観測するアプローチを採用する。第２の実施の形態では、ネットワークタップや、スイッチ装置のポートミラーリング機能を使ってネットワークを流れるＩＰ（Internet Protocol）パケットをキャプチャし、そこからプロトコルメッセージを再現することによって情報を得る。ポートミラーリング機能とは、スイッチ装置上の特定のポートを流れるＩＰパケットをコピーして、指定した別のポートへ転送する機能である。ネットワークタップとは、ネットワークを介して伝送される信号を分岐し、分岐して取り出した信号をモニタ用ポートから出力する装置である。ここで、プロトコルメッセージは、所定のプロトコルに準拠した情報である。以下、プロトコルメッセージを、単に「メッセージ」と呼ぶ。
【００４０】
なお、コンピュータの単位時間当たりの処理能力は、スループットと呼ばれる。そこで、第２の実施の形態では、第１の実施の形態に示した合計進行量に相当する値を、スループットと呼ぶこととする。
【００４１】
また第２の実施の形態では、複数階層システムとしてＷｅｂ３階層システムを例として説明する。Ｗｅｂ３階層システムとは、Ｗｅｂサーバ、アプリケーションサーバ（以降、Ａｐｐサーバ）、データベースサーバ（以降、ＤＢサーバ）からなる複数階層コンピュータシステムである。エンドユーザのコンピュータ上のブラウザが出力する処理要求は、ＷｅｂサーバがＨＴＴＰ（Hyper Text Transfer Protocol）に従ったメッセージで受ける。処理要求が静的コンテンツの取得であれば、Ｗｅｂサーバが、保持しているコンテンツを直接エンドユーザのコンピュータへ返信する。他方、処理要求がプログラムによって生成される動的コンテンツの取得の場合、Ｗｅｂサーバは、処理をＡｐｐサーバへ依頼する。処理の依頼を受けたＡｐｐサーバは、Ｊａｖａ（登録商標）などで記述されたプログラムによってその処理要求を実行する。Ａｐｐサーバは、処理の過程において使用されるデータを、それを保持するＤＢサーバに対して処理要求を発行して取得する。
【００４２】
第２の実施の形態では、対象とするＷｅｂ３階層システムから、以下の情報を取得する機能を備えている。
・定めた一定の時間枠内での、各階層のサーバにおける正確な多重度とスループット
・各階層の各ジョブの生成元となったＨＴＴＰリクエストの応答時間
第２の実施の形態では、各サーバに入力されるリクエストと、出力されるレスポンスとを分析サーバでキャプチャする。そして分析サーバが、キャプチャした情報に基づいて、各階層における多重度とスループットとを解析する。
【００４３】
また階層の各ジョブの生成元となったＨＴＴＰリクエストの応答時間を得るために、分析サーバは、キャプチャした情報に基づいて、異なる階層のジョブ間の呼び出し関係を特定する。さらに分析サーバは、ジョブの呼び出し関係に基づいて、一連のトランザクションに属するメッセージ送受関係を正確に特定する。そして分析サーバは、その際にＨＴＴＰリクエストの応答時間を取得する。正確な多重度を求めるためにも、各ジョブの開始時刻と終了時刻、すなわちメッセージ送受が行われた時刻を精密に特定する。
【００４４】
図２は、第２の実施の形態のシステムの全体構成を示す図である。このシステムは、分析サーバ１００、Ｗｅｂサーバ２１，２２，２３、Ａｐｐサーバ２４，２５、ＤＢサーバ２６、およびロードバランサ２７を有する。Ｗｅｂサーバ２１，２２，２３と、Ａｐｐサーバ２４，２５とは、スイッチ装置３１を介して相互に接続されている。Ａｐｐサーバ２４，２５とＤＢサーバ２６とは、スイッチ装置３２を介して相互に接続されている。ロードバランサ２７は、Ｗｅｂサーバ２１，２２，２３それぞれと、ネットワークタップ３３，３４，３５を介して接続されている。
【００４５】
スイッチ装置３１，３２は、ポートミラーリング機能を有している。スイッチ装置３１，３２それぞれのポートミラーリング用のポートには、スイッチ装置３６が接続されている。スイッチ装置３１は、ポートミラーリングにより、Ｗｅｂサーバ２１，２２，２３とＡｐｐサーバ２４，２５との間で送受信されるパケットをコピーし、スイッチ装置３６に送信する。スイッチ装置３２は、ポートミラーリングにより、Ａｐｐサーバ２４，２５とＤＢサーバ２６との間で送受信されるパケットをコピーし、スイッチ装置３６に送信する。
【００４６】
ネットワークタップ３３，３４，３５のモニタ用ポートには、スイッチ装置３６が接続されている。ネットワークタップ３３は、Ｗｅｂサーバ２１とロードバランサ２７との間で通信されるパケットをコピーし、スイッチ装置３６に送信する。ネットワークタップ３４は、Ｗｅｂサーバ２２とロードバランサ２７との間で通信されるパケットをコピーし、スイッチ装置３６に送信する。ネットワークタップ３５は、Ｗｅｂサーバ２３とロードバランサ２７との間で通信されるパケットをコピーし、スイッチ装置３６に送信する。
【００４７】
スイッチ装置３６には、分析サーバ１００が接続されている。スイッチ装置３６は、他のスイッチ装置３１，３３や、ネットワークタップ３３，３４，３５から送られたパケットを、分析サーバ１００に転送する。
【００４８】
ロードバランサ２７は、ネットワーク１０を介して端末装置２９ａ，２９ｂ，・・・に接続されている。ロードバランサ２７は、端末装置２９ａ，２９ｂ，・・・からＷｅｂサーバ２１，２２，２３宛に出された処理要求を、いずれかのＷｅｂサーバに転送する。例えばロードバランサ２７は、各Ｗｅｂサーバ２１，２２，２３の処理量が均等になるように、処理要求のＷｅｂサーバ２１，２２，２３への振り分けを行う。
【００４９】
端末装置２９ａ，２９ｂ，・・・は、ネットワーク１０およびロードバランサ２７を介してＷｅｂサーバ２１，２２，２２にアクセス可能である。端末装置２９ａ，２９ｂ，・・・のユーザは、Ｗｅｂサーバ２１，２２，２３が提供するＧＵＩ（Graphical User Interface）を端末装置２９ａ，２９ｂ，・・・から操作してシステムを利用できる。
【００５０】
分析サーバ１００は、Ｗｅｂサーバ２１，２２，２３、Ａｐｐサーバ２４，２５およびＤＢサーバ２６の稼働状況を管理する。分析サーバ１００は、稼働状況を管理するための情報をスイッチ装置３６を介して取得することができる。すなわち、分析サーバ１００は、スイッチ装置３６から送信される通信パケットを受信して、記憶する（パケットキャプチャ）。分析サーバ１００は、スイッチ装置３６を介して転送されてくるＩＰパケットを受信可能なネットワークインタフェースを有している。そして分析サーバ１００は、転送されてきたＩＰパケット格納用の十分に大きなハードディスクを有している。さらに、分析サーバ１００は、ＩＰパケットをキャプチャするのに十分なＣＰＵ性能を保有していることが望ましい。転送されてきたＩＰパケットは、分析サーバ１００上でキャプチャされ、その後にメッセージを抽出するための処理が実施される。
【００５１】
Ｗｅｂサーバ２１，２２，２３は、Ｗｅｂブラウザを実行する端末装置２９ａ，２９ｂ，・・・から出力された処理要求（メッセージ）を受け付ける。ここで、Ｗｅｂサーバ２１，２２，２３と端末装置２９ａ，２９ｂ，・・・とのメッセージ交換は、例えばＨＴＴＰによって行われるものとする。ただし、他のプロトコルが用いられてもよい。
【００５２】
以下では、端末装置２９ａ，２９ｂ，・・・からＷｅｂサーバ２１，２２，２３へ送信する処理要求をＨＴＴＰリクエストと呼ぶこととする。また、それに対する応答をＨＴＴＰレスポンスと呼ぶこととする。なお、リクエスト／レスポンスともに処理要求の一例である。
【００５３】
Ｗｅｂサーバ２１，２２，２３は、端末装置２９ａ，２９ｂ，・・・から受信したＨＴＴＰリクエストに基づいて、静的コンテンツに関しては自装置でＨＴＴＰレスポンスを生成し、端末装置２９ａ，２９ｂ，・・・に送信する。なお、動的コンテンツに関しては、Ａｐｐサーバ２４，２５に依頼すべき処理の処理要求（メッセージ）を生成して、Ａｐｐサーバ２４，２５に送信する。
【００５４】
ここで、Ｗｅｂサーバ２１，２２，２３とＡｐｐサーバ２４，２５とのメッセージ交換は、ＩＩＯＰ（Internet Inter-ORB（Object Request Broker） Protocol）によって行われるものとする。ただし、他のプロトコルが用いられてもよい。
【００５５】
以下では、Ｗｅｂサーバ２１，２２，２３からＡｐｐサーバ２４，２５へ送信する処理要求をＩＩＯＰリクエストと呼ぶこととする。また、それに対する応答をＩＩＯＰレスポンスと呼ぶこととする。
【００５６】
Ｗｅｂサーバ２１，２２，２３は、ＩＩＯＰリクエストに対するＩＩＯＰレスポンスを受信すると、その内容に基づいてＨＴＴＰレスポンスを生成して、端末装置２９ａ，２９ｂ，・・・に送信する。
【００５７】
Ａｐｐサーバ２４，２５は、Ｗｅｂサーバ２１，２２，２３から受信したＩＩＯＰリクエストに基づいてＤＢサーバ２６に依頼すべき処理のクエリを生成し、ＤＢサーバ２６に送信する。
【００５８】
ここで、Ａｐｐサーバ２４，２５が生成するクエリは、例えばＳＱＬ（Structured Query Language）文によって表記され、ＤＢサーバに固有のプロトコルでＤＢサーバへと送信される。以下では、Ａｐｐサーバ２４，２５がＤＢサーバ２６に送信するクエリをＤＢリクエストと呼ぶこととする。また、それに対する応答をＤＢレスポンスと呼ぶこととする。
【００５９】
Ａｐｐサーバ２４，２５は、ＤＢリクエストに対するＤＢレスポンスを受信すると、その内容に基づいてＩＩＯＰレスポンスを生成してＷｅｂサーバ２１，２２，２３に送信する。
【００６０】
ＤＢサーバ２６は、Ａｐｐサーバ２４，２５から受信したＤＢリクエストに含まれるＳＱＬ文を実行してＤＢの参照や更新等の処理を実行する。ＤＢサーバ２６は、その処理結果に基づいてＤＢレスポンスを生成し、Ａｐｐサーバ２４，２５に送信する。
【００６１】
なお、Ｗｅｂ層、Ａｐｐ層、ＤＢ層の階層間を跨って送受信されるメッセージを取得する手法には何通りか考えられるが、第２の実施の形態では、ネットワーク上を流れるＩＰパケットから情報を取得するものとする。
【００６２】
また、以下では各サーバという場合、Ｗｅｂサーバ２１，２２，２３、Ａｐｐサーバ２４，２５およびＤＢサーバ２６を示すものとする。さらに、Ｗｅｂサーバ２１，２２，２３は、Ａｐｐサーバ２４，２５およびＤＢサーバ２６よりも上位層のサーバであるとする。また、Ａｐｐサーバ２４，２５は、ＤＢサーバ２６よりも上位層のサーバであるとする。このような階層関係を定義する情報は、分析サーバ１００に予め格納される。
【００６３】
図３は、第２の実施の形態に用いる分析サーバのハードウェアの一構成例を示す図である。分析サーバ１００は、ＣＰＵ１０１、ＲＯＭ（Read Only Memory）１０２、ＲＡＭ１０３、ＨＤＤ１０４、グラフィック処理装置１０５、入力インタフェース１０６、記録媒体読取装置１０７および通信インタフェース１０８を有する。
【００６４】
ＣＰＵ１０１は、分析サーバ１００全体を制御する。
ＲＯＭ１０２は、分析サーバ１００上のＢＩＯＳ（Basic Input / Output System）のプログラムなどを記憶する。
【００６５】
ＲＡＭ１０３は、ＣＰＵ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションのプログラムの少なくとも一部を一時的に記憶する。また、ＲＡＭ１０３は、ＣＰＵ１０１による処理に必要な各種データを記憶する。
【００６６】
ＨＤＤ１０４は、ＯＳのプログラム、アプリケーションのプログラムを記憶する。また、ＨＤＤ１０４はＣＰＵ１０１による処理に必要な各種データを記憶する。なお、ＨＤＤ１０４に代えて（または、ＨＤＤ１０４と併せて）、ＳＳＤ（Solid State Drive）など他の種類の記憶装置を用いてもよい。
【００６７】
グラフィック処理装置１０５は、モニタ１１と接続される。グラフィック処理装置１０５は、ＣＰＵ１０１からの命令に従って画像をモニタ１１の画面に表示させる。
入力インタフェース１０６は、キーボード１２とマウス１３と接続される。入力インタフェース１０６は、キーボード１２やマウス１３から送られてくる信号をＣＰＵ１０１に送信する。
【００６８】
記録媒体読取装置１０７は、記録媒体１４に記憶されたデータを読み取る読取装置である。例えば、分析サーバ１００が有すべき機能は、その機能の処理内容を記述したプログラムをコンピュータに実行させることで実現できる。そのようなプログラムは、コンピュータ読み取り可能な記録媒体１４に記録して配布することができる。また、スイッチ装置３６に接続されたプログラム配信サーバ（図示せず）にそのプログラムを格納してもよい。この場合、分析サーバ１００は、スイッチ装置３６を介してプログラム配信サーバからプログラムをダウンロードすることができる。
【００６９】
記録媒体１４としては、例えば、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリを使用できる。磁気記録装置には、ＨＤＤ、フレキシブルディスク（ＦＤ：Flexible Disk）、磁気テープなどがある。光ディスクには、ＣＤ（Compact Disc）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−Ｒ／ＲＷ／ＲＡＭなどがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。半導体メモリには、ＵＳＢ（Universal Serial Bus）メモリなどのフラッシュメモリがある。
【００７０】
通信インタフェース１０８は、ＴＰ（Twisted Pair）ケーブルや光ケーブル等によってスイッチ装置３６と接続される。通信インタフェース１０８は、スイッチ装置３６を介して他の情報処理装置とデータ通信する。また、通信インタフェース１０８は、各サーバの間で送受信される通信パケットをスイッチ装置３６から受信する。
【００７１】
以上のようなハードウェア構成によって、第２の実施の形態の処理機能を実現することができる。なお、図３には分析サーバ１００のハードウェア構成を示したが、Ｗｅｂサーバ２１，２２，２３、Ａｐｐサーバ２４，２５、ＤＢサーバ２６、および複数の端末装置２９ａ，２９ｂ，・・・も、分析サーバ１００と同様のハードウェア構成で実現することができる。なお、第１の実施の形態に示した情報処理装置も、図３に示したコンピュータと同様のハードウェアにより実現することができる。
【００７２】
図４は、第２の実施の形態に係る分析サーバの機能の一例を示すブロック図である。分析サーバ１００は、キャプチャ部１１１、キャプチャデータ記憶部１１２、メッセージ解析部１２１、メッセージデータ記憶部１２２、抽象化ルール記憶部１３１、メッセージフロー検出部１３２、メッセージフロー情報記憶部１３３、集計部１４１、集計区間情報記憶部１４２、正規化スループット値記憶部１４３、性能分析部１４４、および多重度制御部１４５を有する。
【００７３】
キャプチャ部１１１は、スイッチ装置３１，３２のミラーポートまたはネットワークタップ３３〜３５から出力された通信パケットを、スイッチ装置３６を介して受信する。キャプチャ部１１１は、受信した通信パケットを、キャプチャデータ記憶部１１２に格納する。この際、キャプチャ部１１１は、例えば、格納する通信パケットに対して、現在の時刻を示す情報（タイムスタンプ）を付与し、時刻情報が付与された通信パケット情報をキャプチャデータ記憶部１１２に格納する。
【００７４】
キャプチャデータ記憶部１１２は、キャプチャ部１１１がキャプチャした通信パケットを記憶する。例えば分析サーバ１００のＲＡＭ１０３またはＨＤＤ１０４の記憶領域の一部が、キャプチャデータ記憶部１１２として使用される。
【００７５】
メッセージ解析部１２１は、受信したパケットを解析し、Ｗｅｂサーバ２１，２２，２３、Ａｐｐサーバ２４，２５、ＤＢサーバ２６および端末装置２９ａ，２９ｂ，・・・において通信されたメッセージを再構成する。そしてメッセージ解析部１２１は、再構成したメッセージを、メッセージデータ記憶部１２２に格納する。
【００７６】
メッセージデータ記憶部１２２は、再構成されたメッセージを記憶する。例えばＲＡＭ１０３またはＨＤＤ１０４の記憶領域の一部がメッセージデータ記憶部１２２として使用される。
【００７７】
抽象化ルール記憶部１３１は、リクエストメッセージの内容を抽象化するルール（抽象化ルール）を記憶する。例えば、抽象化ルール記憶部１３１には、同じ種類（ジョブ種）の処理（ジョブ）を依頼するリクエストメッセージを、同じ内容に抽象化するルールが記憶される。抽象化ルールに基づいて各リクエストメッセージを抽象化することで、抽象化後の内容が共通のリクエストメッセージを、同じジョブ種に関するリクエストメッセージと判断することが可能となる。抽象化ルール記憶部１３１としては、例えばＲＡＭ１０３またはＨＤＤ１０４の記憶領域の一部が使用される。
【００７８】
メッセージフロー検出部１３２は、メッセージデータ記憶部１２２に格納された時系列データで示されるメッセージによって実行される処理（ジョブ）の種別を、抽象化ルール記憶部１３１に格納された抽象化ルールに基づいて判断する。例えばメッセージフロー検出部１３２は、リクエストメッセージを抽象化ルールに従って抽象化し、同じ内容に抽象化されたリクエストメッセージを、同種のジョブに関するリクエストメッセージと判断する。
【００７９】
またメッセージフロー検出部１３２は、抽象化処理後のメッセージから、Ｗｅｂサーバ２１，２２，２３、Ａｐｐサーバ２４，２５、およびＤＢサーバ２６で実行されたトランザクション（一連の処理）のメッセージを検出する。例えば、メッセージフロー検出部１３２は、予めトランザクションモデルを有しており、トランザクションモデルに合致するメッセージの組み合わせ（メッセージフロー）を、メッセージデータ記憶部１２２から抽出する。
【００８０】
さらにメッセージフロー検出部１３２は、メッセージデータ記憶部１２２から抽出したメッセージフローを、メッセージフロー情報としてメッセージフロー情報記憶部１３３に格納する。格納されるメッセージフロー情報のリクエストメッセージには、そのリクエストメッセージに応じて実行されるジョブの種類（ジョブ種）が設定される。
【００８１】
メッセージフロー情報記憶部１３３は、メッセージフロー情報を記憶する。例えばＲＡＭ１０３またはＨＤＤ１０４の記憶領域の一部が、メッセージフロー情報記憶部１３３として使用される。
【００８２】
集計部１４１は、分析対象期間を細かい粒度（短い時間間隔）で分割し、複数の集計区間を生成する。そして、集計部１４１は、メッセージフロー情報記憶部１３３に格納された情報を、集計区間ごとに集計する。例えば、集計部１４１は、メッセージフロー情報記憶部１３３に格納された情報に基づいて、階層ごとに、分析対象の期間を細かい粒度で分割して得られる集計区間それぞれのスループットと多重度とを計算する。集計部１４１は、計算したスループットと多重度とを、集計区間情報記憶部１４２に格納する。
【００８３】
集計区間情報記憶部１４２は、集計区間それぞれにおける、階層ごとのスループットと多重度との組を記憶する。例えばＲＡＭ１０３またはＨＤＤ１０４の記憶領域の一部が、集計区間情報記憶部１４２として使用される。
【００８４】
正規化スループット値記憶部１４３は、ジョブ種ごとの、１ジョブ当たりの正規化されたスループット値を記憶する。例えばＲＡＭ１０３またはＨＤＤ１０４の記憶領域の一部が、正規化スループット値記憶部１４３として使用される。
【００８５】
性能分析部１４４は、飽和多重度を決定する。飽和多重度は、多重度の増加に伴ってスループットが増加する範囲と、多重度が増加しているのにスループットが増加しないか、微少な増加しかしない範囲との境界の多重度である。すなわち、それ以上多重度を上げてもスループットの十分な上昇が見込めない多重度が、飽和多重度である。
【００８６】
また性能分析部１４４は、複数階層システムに含まれるサーバのうち、処理のボトルネックとなっているサーバを判定する。例えば性能分析部１４４は、飽和多重度よりも多重度が多い期間の割合が、所定値を超えた階層のサーバについて、ボトルネックになっていると判断する。そして、性能分析部１４４は判断結果を出力する。例えば性能分析部１４４は、ボトルネックとなっている階層（またはサーバ）を示す情報を、多重度制御部１４５に通知する。
【００８７】
多重度制御部１４５は、ボトルネックとなっている階層のサーバで許容可能な多重度の範囲を分析する。許容可能な多重度の範囲は、下限値と上限値とで表される。下限値は、多重度の増加に伴ってスループットが増加する範囲と、多重度が増加しているのにスループットが増加しないか、微少な増加しかしない範囲との境界の多重度である。換言すると、下限値は、多重度を増加させたときに、スループットが飽和してそれ以上増加しなくなる多重度（飽和多重度）である。上限値は、多重度を増加させたときに、ＳＬＡ充足スループットが減少し始める多重度である。
【００８８】
また多重度制御部１４５は、許容可能な多重度制限値の範囲内の多重度が、ボトルネックとなっているサーバの最大多重度となるように、ボトルネックとなっているサーバに処理を依頼する上位のサーバに対して、処理要求の多重度の設定を行う。例えばＤＢサーバ２６がボトルネックとなっている場合を考える。この場合、多重度制御部１４５は、２台のＡｐｐサーバ２４，２５からＤＢサーバ２６に並列に出力されるリクエストの合計が、ＤＢサーバ２６において許容可能な多重度制限値の範囲内となるように、Ａｐｐサーバ２４，２５に対して設定する。なお、許容可能な多重度制限値の範囲内の多重度としては、例えば許容可能な多重度制限値の範囲の上限値と下限値との中間とすることができる。
【００８９】
なお、図４に示した各機能間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。
次に、図４に示した各機能が行う処理について、詳細に説明する。
【００９０】
図５は、分析処理の手順の一例を示すフローチャートである。なお図５では、ＵＭＬ（Unified Modeling Language）のアクティビティ図で用いられる同期バー３７，３８を用いて、並列処理を表している。同期バー３７は、特にフォークと呼ばれ、１つの処理が２つ以上の並列処理に分割されることを示す。同期バー３８は、特にジョインと呼ばれ、２つ以上の処理の流れを１つに統合することを示す。
【００９１】
以下、図５に示す処理をステップ番号に沿って説明する。
［ステップＳ１０１］キャプチャ部１１１は、スイッチ装置３１，３２のミラーポートやネットワークタップ３３〜３５から出力されたＩＰパケットをキャプチャする。キャプチャ部１１１は、例えばキャプチャしたＩＰパケットを、一時的にＲＡＭ１０３に格納する。この際、キャプチャ部１１１は、受信したＩＰパケットに受信時刻を付与する。
【００９２】
［ステップＳ１０２］キャプチャ部１１１は、キャプチャの開始、またはキャプチャデータの前回のファイル出力から、所定のファイル出力周期が経過したか否かを判断する。ファイル出力周期は、例えば１８０秒といった値が予めキャプチャ部１１１に設定されている。キャプチャ部１１１は、ファイル出力周期が経過した場合、処理をステップＳ１０３に進める。またキャプチャ部１１１は、ファイル出力周期が経過していなければ、処理をステップＳ１０１に進め、ＩＰパケットのキャプチャを継続する。
【００９３】
［ステップＳ１０３］キャプチャ部１１１は、ＲＡＭ１０３などに一時的に保管してあるキャプチャデータを、ファイル１１２ａに出力する。例えばキャプチャ部１１１は、新規のファイルを作成し、作成したファイル１１２ａにキャプチャデータを出力する。そしてキャプチャ部１１１は、キャプチャデータを含むファイルをキャプチャデータ記憶部１１２に格納する。
【００９４】
［ステップＳ１０４］キャプチャ部１１１は、停止コマンドが入力されたか否かを判断する。停止コマンドは、例えば管理者が、キーボード１２やマウス１３を操作して分析サーバ１００に入力する。キャプチャ部１１１は、停止コマンドが入力された場合、キャプチャ処理を終了する。またキャプチャ部１１１は、停止コマンドが入力されていなければ、処理をステップＳ１０１に進める。
【００９５】
このようにして、ファイル出力周期ごとにキャプチャしたデータを含むファイル１１２ａが生成され、順次キャプチャデータ記憶部１１２に格納される。
［ステップＳ１０５］メッセージ解析部１２１は、キャプチャデータ記憶部１１２から、性能分析処理を行っていない、未処理のファイル１１２ａがあるか否かを判断する。未処理のファイルは、キャプチャ部１１１により、ファイル出力周期で定期的にキャプチャデータ記憶部１１２に順次格納されている。従って、メッセージ解析部１２１は、ファイル出力周期で、未処理のファイルを検出できる。メッセージ解析部１２１は、未処理のファイル１１２ａがあれば、処理をステップＳ１０６に進める。またメッセージ解析部１２１は、未処理のファイルがなければ、ステップＳ１０５の処理を繰り返し、未処理のファイルがキャプチャデータ記憶部１１２に格納されるのを待つ。
【００９６】
［ステップＳ１０６］メッセージ解析部１２１は、キャプチャデータ記憶部１１２内の未処理のファイル１１２ａからキャプチャデータを読み込む。
［ステップＳ１０７］分析サーバ１００内の各機能が連携して性能分析を行う。この処理の詳細は後述する（図７参照）。
【００９７】
［ステップＳ１０８］多重度制御部１４５は、性能分析により、ボトルネックとなっている階層が検出されたか否かを判断する。例えば多重度制御部１４５は、性能分析部１４４から、ボトルネックとなっている階層の通知を受けたとき、ボトルネックとなっている階層が検出されたと判断する。多重度制御部１４５は、ボトルネックとなっている階層がある場合、処理をステップＳ１０９に進める。また多重度制御部１４５は、ボトルネックとなっている階層がなければ、処理をステップＳ１１０に進める。
【００９８】
［ステップＳ１０９］多重度制御部１４５は、ボトルネックとなっている階層で許容可能な多重度の範囲の分析を行う。そして多重度制御部１４５は、ボトルネックとなっている階層のサーバに対して、分析結果として得られた許容可能な多重度制限値の範囲内の多重度を、そのサーバにおける多重度制限値として設定する。多重度制限値の設定は、例えば、分析サーバ１００からの他のサーバへのリモートアクセスにより実行される。この処理の詳細は後述する。
【００９９】
［ステップＳ１１０］メッセージ解析部１２１は、停止コマンドが入力されたか否かを判断する。停止コマンドは、例えば管理者が、キーボード１２やマウス１３を操作して分析サーバ１００に入力する。メッセージ解析部１２１は、停止コマンドが入力された場合、分析処理を終了する。またメッセージ解析部１２１は、停止コマンドが入力されていなければ、処理をステップＳ１０５に進める。
【０１００】
このように、キャプチャされたデータは、一定時間分（例えば１８０秒間）だけ貯められて、一定時間間隔で、その一定時間分のデータを使用して性能分析処理が行われる。このとき、データの収集処理（ステップＳ１０１〜Ｓ１０４）と分析処理（ステップＳ１０５〜Ｓ１１０）は切り離して非同期で行ってもよい。ただし、図５に示すようにデータの収集処理（ステップＳ１０１〜Ｓ１０４）と分析処理（ステップＳ１０５〜Ｓ１１０）を同期して動作させることで、不適切な多重度制限値をリアルタイムに検出し、動的に修正することが可能となる。
【０１０１】
図６は、キャプチャデータ記憶部のデータ構造の一例を示す図である。キャプチャデータ記憶部１１２には、複数のファイル１１２ａ，１１２ｂ，１１２ｃ，・・・が格納されている。
【０１０２】
ファイル１１２ａには、複数のＩＰパケット１１２ｄ−１〜１１２ｄ−７が含まれている。またＩＰパケット１１２ｄ−１〜１１２ｄ−７それぞれには、受信時刻１１２ｅ−１〜１１２ｅ−７が付与されている。他のファイル１１２ｂ，１１２ｃ，・・・も、ファイル１１２ａと同様に、受信時刻が付与されたＩＰパケットを含んでいる。
【０１０３】
＜性能分析処理＞
次に、性能分析処理について詳細に説明する。
図７は、性能分析処理の手順の一例を示すフローチャートである。以下、図７に示す処理をステップ番号に沿って説明する。
【０１０４】
［ステップＳ１２１］メッセージ解析部１２１は、取得したファイルに含まれるＩＰパケットに基づいて、メッセージを再構築する。メッセージ解析部１２１は、再構築したメッセージを、メッセージデータ記憶部１２２に時系列に格納する。
【０１０５】
［ステップＳ１２２］メッセージフロー検出部１３２は、メッセージデータ記憶部１２２に格納されたメッセージから、１つの業務処理リクエストに応じて複数階層システム内で発行された一連のメッセージ送受関係を示すメッセージフローを検出する。
【０１０６】
第２の実施の形態では、メッセージは階層ごとに異なるプロトコルが使われている。端末装置２９ａ，２９ｂ，・・・からの１つのリクエストに関連して、複数階層システム内の各階層で発行される異なるプロトコルのメッセージ間には、それらを関連付けるための情報が含まれていない場合が多い。そこで第２の実施の形態では、これらの異なるプロトコル間のメッセージを、既知のモデルと照合することで関連付ける。例えばメッセージフロー検出部１３２は、予め用意されたメッセージフローのモデルと、メッセージデータ記憶部１２２に格納されたメッセージとを比較し、モデルに合致するメッセージの組み合わせを作成する。そしてメッセージフロー検出部１３２は、作成されたメッセージの組み合わせをメッセージフローとする。
【０１０７】
［ステップＳ１２３］メッセージフロー検出部１３２は、検出したメッセージフローに含まれるリクエストメッセージに応じて、各階層のサーバで実行される処理のジョブ種を判定する。例えばメッセージフロー検出部１３２は、抽象化ルール記憶部１３１に格納されている抽象化ルールに従って、リクエストメッセージを抽象化する。そしてメッセージフロー検出部１３２は、抽象化後の内容が同じリクエストメッセージ同士をまとめて、１つのジョブ種とする。検出されたジョブ種には、識別名（ジョブ種名）が付与される。そしてメッセージフロー検出部１３２は、リクエストメッセージにジョブ種名が付与されたメッセージフローを、メッセージフロー情報記憶部１３３に格納する。
【０１０８】
［ステップＳ１２４］性能分析部１４４は、未処理の階層を選択する。例えば性能分析部１４４には、複数階層システムを構成する各階層のサーバに入力するリクエストメッセージのプロトコル名が予め設定されている。Ｗｅｂ３階層であれば、例えばプロトコル名「ＨＴＴＰ」、「ＩＩＯＰ」、「ＤＢ」の各プロトコル名が性能分析部１４４に設定されている。性能分析部１４４は、設定されているプロトコル名に対応する階層を順に選択する。
【０１０９】
［ステップＳ１２５］性能分析部１４４が、選択したプロトコル名に対応する階層の性能分析処理を行う。この処理の詳細は後述する（図１４参照）。
［ステップＳ１２６］性能分析部１４４は、すべての階層について階層別の性能分析処理を実行したか否かを判断する。例えば性能分析部１４４は、予め設定されているプロトコル名で示されるすべての階層が選択済みであれば、未処理の階層なしと判断する。未処理の階層がある場合、性能分析部１４４は、処理をステップＳ１２４に進める。未処理の階層がなければ、性能分析部１４４は、性能分析処理を終了する。
【０１１０】
このように、性能分析処理では、まずメッセージが再構築され、メッセージデータ記憶部１２２に格納される。
図８は、メッセージデータ記憶部のデータ構造の一例を示す図である。メッセージデータ記憶部１２２には、復元された複数のメッセージが、時系列に格納されている。このように時系列に並べられたメッセージが、時系列データである。図８では、各メッセージの左に、メッセージデータ記憶部１２２内での行番号を示している。なお、メッセージデータ記憶部１２２には、各階層間の処理要求および応答に関連するメッセージ以外のメッセージに関しては図示を省略している。
【０１１１】
各行に示されるメッセージには、日付フィールド１２２ａ、時刻フィールド１２２ｂ、セッション番号フィールド１２２ｃ、送信元アドレスフィールド１２２ｄ、送信先アドレスフィールド１２２ｅ、コマンド種別フィールド１２２ｆおよびメッセージフィールド１２２ｇが含まれる。
【０１１２】
日付フィールド１２２ａは、メッセージをキャプチャした日付を示すフィールドである。
時刻フィールド１２２ｂは、メッセージをキャプチャした時刻を示すフィールドである。
【０１１３】
セッション番号フィールド１２２ｃは、業務システムにおけるメッセージの送受信に用いるリソースを管理するためのセッション番号を示すフィールドである。
送信元アドレスフィールド１２２ｄは、メッセージの送信元のコンピュータのＩＰ（Internet Protocol）アドレスおよびポート番号を示すフィールドである。
【０１１４】
送信先アドレスフィールド１２２ｅは、メッセージの送信先のコンピュータのＩＰアドレスおよびポート番号を示すフィールドである。
コマンド種別フィールド１２２ｆは、コマンドのリクエスト／レスポンス属性やプロトコル（ＨＴＴＰ、ＩＩＯＰおよびＤＢクエリ用等）の種別を示すフィールドである。
【０１１５】
メッセージフィールド１２２ｇは、コマンド種別フィールド１２２ｆに示されたリクエスト等のメッセージ内容を示すフィールドである。
このようなメッセージデータ記憶部１２２内のメッセージを参照することで、いずれのサーバに対して、どのようなメッセージが送信されたかを検出することができる。
【０１１６】
ここで、メッセージデータ記憶部１２２内のメッセージ中のその他のＩＰアドレスと各装置との対応関係は次の通りである。
“１９４．２３．５．２２６”は、Ｗｅｂサーバ２１のＩＰアドレスを示す。“１９４．２３．７．１６８”は、Ａｐｐサーバ２４のＩＰアドレスを示す。“１９４．２３．８．１９８”は、ＤＢサーバのＩＰアドレスを示す。“１９４．１８５．３９．２４”は、端末装置２９ａのＩＰアドレスを示す。
【０１１７】
なお、日付フィールド１２２ａおよび時刻フィールド１２２ｂの情報として、メッセージ解析部１１０が通信パケットをキャプチャしたタイミングにおけるタイムスタンプを設定するものとしたが、設定方法はこれに限らない。例えば、通信パケット中に各サーバにおけるパケットの生成時刻や送信時刻の情報が含まれている場合には、その日時を日付フィールド１２２ａおよび時刻フィールド１２２ｂの情報としてもよい。その場合、各サーバで精度良く時刻同期が行われていることが望ましい。
【０１１８】
メッセージが再構築されると、メッセージフロー検出部１３２は、検出されたメッセージフロー内のリクエストメッセージに関し、そのリクエストメッセージによって実行されるジョブのジョブ種を識別する。ここでいうジョブ種は、同様の処理内容のリクエストをグループ化したものである。メッセージフロー検出部１３２は、ジョブ種を識別する場合、抽象化ルール記憶部１３１に設定された抽象化ルールに基づいて、リクエストメッセージを抽象化する。
【０１１９】
図９は、抽象化ルール記憶部のデータ構造の一例を示す図である。抽象化ルール記憶部１３１には、プロトコルごとの抽象化ルールが格納されている。
例えばプロトコルがＨＴＴＰのメッセージの場合は、メッセージフロー検出部１３２は、コマンド名と、ＵＲＬ内のローカルアドレス部分に、残すべきと指定されたＣＧＩ（Common Gateway Interface）パラメータを連結したもので、ジョブ種を区別する。コマンド名は、ＧＥＴやＰＯＳＴ等である。ＵＲＬ内のローカルアドレス部分は、ＵＲＬから“プロトコル名://ホスト名:ポート番号”の部分を削除したものである。そしてＨＴＴＰ用の抽象化ルール１３１ａには、残すべきＣＧＩパラメータが定義されている。例えば、図９の例では、「type」、「comment＿table」の各パラメータを残し、他のパラメータは削除することが示されている。
【０１２０】
またＤＢプロトコルのメッセージの場合は、メッセージフロー検出部１３２は、使用するＤＢプロトコル固有のコマンド名とＳＱＬ文とを、正規表現で記述したルールで置換する。そしてメッセージフロー検出部１３２は、置換によって抽象化されたメッセージによりジョブ種を区別する。ＤＢプロトコル用の抽象化ルール１３１ｂには、正規表現を用いた置換規則が定義されている。図９の例では、Ｐｅｒｌと同じ記法による置換規則が定義されている。例えば１行目の置換規則「s/INSERT INTO ([^ \(]+).*/INSERT INTO $1 VALUES (..)/」の先頭の「s」は、置換処理であることを示している最初の「/」と２つめの「/」で囲われた文字列「INSERT INTO ([^ \(]+).*」が、置換元の文字列である。また２つめの「/」と３つめの「/」で囲われた文字列「INSERT INTO $1 VALUES (..)」が、置換後の文字列である。置換元の文字列の「（」と「）」とで囲われた文字列は、変数として記憶される。１行目の置換規則の「（」、「）」で囲われた文字列「[^ \(]+」は、「(」以外の文字の１回以上の繰り返しが、正規表現で示されている。「（」と「）」とで囲われた文字列は、左から順に記憶される。ｋ番目（ｋは、１以上の整数）に記憶された文字列には、「$k」という変数名が与えられる。変数に記憶された文字列は、置換後の文字列内に、変数名で指定された位置に挿入される。
【０１２１】
このような抽象化ルールに従ってリクエストメッセージが抽象化される。そして、抽象化された後の、内容が同じリクエストメッセージ同士が、同じジョブ種となる。
図１０は、ＨＴＴＰのプロトコルのジョブ種の例を示す図である。図１０の例では、ＨＴＴＰのプロトコルに関するジョブ種名に対応付けて、コマンド名と、抽象化されたジョブ内容とが示されている。例えば、ジョブ種名「Ｗ１」のジョブ種は、コマンド名「GET」であり、ジョブ内容が「/RUBBOS/SERVLET/EDU.RICE.RUBBOS.SERVLETS.STORIESOFTHEDAY」である。
【０１２２】
図１１は、ＤＢのプロトコルのジョブ種の例を示す図である。図１１の例では、ＤＢのプロトコルに関するジョブ種名に対応付けて、コマンド名と、抽象化されたジョブ内容とが示されている。例えば、ジョブ種名「Ｄ１」のジョブ種は、コマンド名「EXECREADREQ」であり、ジョブ内容が「SELECT .. FROM STORIES, USERS WHERE ..」である。
【０１２３】
メッセージの抽象化が終了すると、メッセージフロー検出部１３２によりメッセージ同士の関連付けが行われ、関連付けられたメッセージを時系列に並べたメッセージフローが検出される。メッセージフローは、各階層のプロトコル間のメッセージにおいて、同一のトランザクションによって発行された、関連するメッセージ同士を紐付けたものである。例えば上位層のプロトコルによって、その下の階層のサーバに送られたメッセージと、その処理に伴って生成された下位層のプロトコルのメッセージとの間が紐付けされる。このようなメッセージ間の紐付けをすべての階層のプロトコル間で行うことによって、最上位層から最下位層までの間で、一連のトランザクションを構成するすべてのメッセージ送受の関係が再現される。
【０１２４】
図１２は、ジョブ種が識別されたメッセージフローの一例を示す図である。なお図１２では、各サーバがジョブに関する処理を実行している期間を実線で示し、ジョブに関する処理を実行していない期間を破線で示している。サーバがジョブに関する処理を実行していない期間とは、例えば、下位層のサーバにリクエストメッセージを送信し、そのリクエストメッセージに対するレスポンスメッセージを待っている期間である。
【０１２５】
図１２の例では、Ｗｅｂサーバ２１では、ＨＴＴＰリクエストメッセージ４１に応じて、ジョブ種「Ｗ１」のジョブ６１が実行されている。Ｗｅｂサーバ２１は、ジョブ種「Ｗ１」のジョブ６１の実行途中で、Ａｐｐサーバ２４に対してＩＩＯＰリクエストメッセージ４２を送信している。
【０１２６】
Ａｐｐサーバ２４では、ＩＩＯＰリクエストメッセージ４２に応じて、ジョブ種「Ａ１」のジョブ６２が実行されている。Ａｐｐサーバ２４は、ジョブ種「Ａ１」のジョブ６２の実行途中で、ＤＢサーバ２６に対してＤＢリクエストメッセージ４３を送信している。
【０１２７】
ＤＢサーバ２６では、ＤＢリクエストメッセージ４３に応じて、ジョブ種「Ｄ１」のジョブ６３が実行されている。ＤＢサーバ２６は、ジョブ種「Ｄ１」のジョブ６３の実行が終了すると、Ａｐｐサーバ２４に対してＤＢレスポンスメッセージ４４を送信している。
【０１２８】
以後、Ａｐｐサーバ２４からＤＢサーバ２６へのＤＢリクエストメッセージ４５，４７，４９の送信と、ＤＢサーバ２６からＡｐｐサーバ２４へのＤＢレスポンスメッセージ４６，４８，５０とが繰り返し行われる。ＤＢサーバ２６では、ＤＢリクエストメッセージ４５，４７，４９に応じたジョブ６４〜６６が実行されている。
【０１２９】
Ａｐｐサーバ２４では、ＤＢレスポンスメッセージ５０に応じて、ジョブ種「Ａ１」のジョブ６２の実行が再開されている。Ａｐｐサーバ２４は、ジョブ種「Ａ１」のジョブ６１の処理が終了すると、Ｗｅｂサーバ２１に対してＩＩＯＰレスポンスメッセージ５１を送信している。Ｗｅｂサーバ２１では、ＩＩＯＰレスポンスメッセージ５１に応じて、ジョブ種「Ｗ１」のジョブ６１の実行が再開されている。Ｗｅｂサーバ２１は、ジョブ種「Ｗ１」のジョブ６１の処理が終了すると、ＨＴＴＰリクエストメッセージ４１を送信した端末装置に対してＨＴＴＰレスポンスメッセージ５２を送信する。
【０１３０】
メッセージフロー検出部１３２は、ジョブ種を識別したメッセージフローに関するメッセージフロー情報を、メッセージフロー情報記憶部１３３に格納する。
図１３は、メッセージフロー情報記憶部のデータ構造の一例を示す図である。メッセージフロー情報記憶部１３３には、トランザクションごとのメッセージフロー情報１３３ａ，１３３ｂ，１３３ｃ，・・・が格納されている。
【０１３１】
メッセージフロー情報１３３ａには、項番を示す項目、時刻を示す項目、セッション番号を示す項目、プロトコルを示す項目、Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅを示す項目、およびジョブ種を示す項目が設けられている。各項目の横方向に並べられた情報同士が互いに関連付けられて、１つのメッセージに関する情報を示す。
【０１３２】
項番を示す項目には、レコードを識別する番号が設定される。時刻を示す項目には、メッセージに対応する通信パケットをキャプチャした時刻が設定される。セッション番号を示す項目には、メッセージを送信するために用いられたセッションを識別するセッション番号が設定される。プロトコルを示す項目には、メッセージがいずれのプロトコルによるものかを示す情報が設定される。Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅを示す項目には、そのメッセージがリクエスト／レスポンスのいずれのものであるかを示す情報が設定される。ジョブ種を示す項目には、リクエストメッセージで要求している処理のジョブ種の名称（ジョブ種名）が設定される。メッセージフロー情報１３３ａには、例えば、項番が“１”、時刻が“０１：５８：１９．９８７”、セッション番号が“１５２２９０”、プロトコルが“ＨＴＴＰ”、Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅが“Ｒｅｑｕｅｓｔ”、ジョブ種が“Ｗ１”という情報が設定される。
【０１３３】
図１３の例では、時刻には、ミリ秒までの時間単位で設定している。この点、さらに短い時間単位（例えば、マイクロ秒単位）で時刻を取得してもよい。また、セッション番号には図８に示したセッション番号フィールド１２２ｃに含まれる情報のうち、リクエスト／レスポンスの組を特定するために必要な最低限の情報を設定している。以下、セッション番号という場合、メッセージフロー情報１３３ａのセッション番号を示す項目に設定された情報を示すものとする。
【０１３４】
メッセージフロー情報には、各メッセージの通信時刻が設定されている。すなわち、キャプチャしたパケットに基づいて、メッセージフローを構成する各メッセージの通信時刻が測定されている。また、ある階層へ処理要求のメッセージが到着して、その処理に関連して下位層へ処理を要求するメッセージが送信された場合に、それらの間の関連付けは、メッセージフロー内の連続するメッセージに基づいて判断できる。すなわち、プロトコル「ＩＩＯＰ」のリクエストメッセージの後に、プロトコル「ＤＢ」のリクエストメッセージがあれば、「ＩＩＯＰ」のリクエストメッセージに関連して「ＤＢ」のリクエストメッセージが出力されたことが分かる。また、上位層のリクエストメッセージからレスポンスメッセージまでの時間帯内の下位層の各リクエストメッセージは、その上位層のリクエストメッセージに応じて実行された処理に関連して実行されていることが分かる。
【０１３５】
このように第２の実施の形態では、ネットワーク上を流れるＩＰパケットをキャプチャして、そこからメッセージ送受の情報を取得することで、一連の処理を示すメッセージフロー情報を生成している。この方法の利点としては、観測対象のシステムに余計な負荷を与えないので正確な挙動を観測できるということがある。また、１か所のサーバでキャプチャしてその際にタイムスタンプを付与できるのでサーバ間の時計誤差を気にしなくてよいという利点もある。
【０１３６】
なお第２の実施の形態では、各メッセージ上にそれらを関連付ける情報が付加されてない場合を想定している。そのため、メッセージフロー検出部１３０によるトランザクションモデルとの適合の有無の判定などが行われている。他方、各メッセージ上にそれらを関連付ける情報が付加されている場合もあり得る。例えば、最上位のサーバ（Ｗｅｂサーバ２１，２２，２３）に入力されたリクエストメッセージに応じて実行されるトランザクションの識別情報が、そのトランザクションで通信される各メッセージに付与しているような場合である。このような場合、メッセージフロー検出部１３０は、同一の識別情報が付与されたメッセージを抽出して、メッセージフローを生成することができる。
【０１３７】
なお、メッセージフロー情報の作成手法は上記の方法に限定されるものではない。すなわち、個々の業務処理に関する複数階層間を跨った一連のメッセージフローを測定し、その中での各メッセージの正確な送受時刻を取得する手法は何通りか考えられる。
【０１３８】
他の方法としては、例えば、Ｗｅｂ３階層システムを構成する各Ｗｅｂサーバ２１，２２，２３、Ａｐｐサーバ２４，２５、およびＤＢサーバ２６でファイルなどに記録したメッセージ送信／受信ログを利用する方法がある。この方法を適用する場合、Ｗｅｂサーバ２１，２２，２３、Ａｐｐサーバ２４，２５、およびＤＢサーバ２６が、受信メッセージとその処理に関連した送信メッセージの関連付けを行い、ログ情報としてＨＤＤなどの記録装置に記録する。分析サーバ１００は、Ｗｅｂサーバ２１，２２，２３、Ａｐｐサーバ２４，２５、およびＤＢサーバ２６から、記録した情報を取得する。この手法では、Ｗｅｂサー２１，２２，２３、Ａｐｐサーバ２４，２５、およびＤＢサーバ２６が、受信したリクエストメッセージと、そのリクエストメッセージに応じた処理により下位の層のサーバへ出力したリクエストメッセージとを関連付けている。そのため、分析サーバ１００では、１つのトランザクションを構成する上位層のメッセージと下位層のメッセージとを容易に関連付けることができ、メッセージフロー情報の作成が容易となる。ただし、この方法を適用する場合、Ｗｅｂサーバ２１，２２，２３、Ａｐｐサーバ２４，２５、およびＤＢサーバ２６各サーバの内部時計を、正確に同期させておくことが好ましい。
【０１３９】
なお、メッセージフロー情報は、複数階層システムにおいて実行されたトランザクションにおける、各サーバのジョブ間でのリクエストメッセージとレスポンスメッセージとの送受信時刻を示すものである。このメッセージフロー情報によって、トランザクションにおいて各サーバで実行されたジョブの処理期間を把握できる。従って、メッセージフロー情報は、第１の実施の形態に示したトランザクション情報の一例である。
【０１４０】
メッセージデータ記憶部１２２に格納されたメッセージから検出可能なすべてのメッセージフローがメッセージフロー情報記憶部１３３に格納された後、Ｗｅｂ三階層システムの階層ごとの性能分析が行われる。
【０１４１】
図１４は、階層別性能分析処理の手順の一例を示すフローチャートである。以下、図１４に示す処理をステップ番号に沿って説明する。
［ステップＳ１３１］集計部１４１は、分析対象期間を、十分に細かい粒度で分割する。分析対象期間は、キャプチャデータ記憶部１１２内の現在処理対象となっている時系列データの生成元となったＩＰパケットの採取期間である。また分析対象期間を分割することで生成された複数の期間を、集計区間とする。例えば、集計区間情報記憶部１４２には、集計区間と、各集計区間の期間を示す情報とが予め格納されている。
【０１４２】
［ステップＳ１３２］集計部１４１は、各集計区間のスループットと多重度とを算出する。この処理の詳細は後述する（図１８参照）。
［ステップＳ１３３］性能分析部１４４は、飽和多重度を算出する。この処理の詳細は後述する（図２４参照）。
【０１４３】
［ステップＳ１３４］性能分析部１４４は、性能分析対象となっている階層がボトルネックとなっているか否かを判定する。この処理の詳細は後述する（図２５参照）。その後、階層別性能分析処理が終了する。
【０１４４】
次に、図１４に示す各ステップの処理を詳細に説明する。
＜＜集計区間への分割＞＞
分析対象期間の集計区間への分割処理について説明する。集計部１４１は、分析対象期間を、十分に細かい粒度の集計区間に分割する。
【０１４５】
なお、第２の実施の形態の手法を実施する場合、細分化した１つの集計区間の長さは十分に短くするのが適切である。なぜならば、多重度はジョブの平均処理時間に近い極短時間で大きく変化するためである。例えば、集計区間の長さは「１００ｍｓ」とする。
【０１４６】
図１５は、集計区間への分割例を示す図である。図１５の例では、１００ｍｓの集計区間長で、分析対象期間が分割されている。なお第２の実施の形態では、集計区間長は、例えば、予め集計部１４１に設定されている。
【０１４７】
図１５に示すように、分析対象期間の分割に伴い、各ジョブの実行期間は、いずれかの集計区間に振り分けられる。これにより、集計区間ごとに、非常に短い時系列データが構成される。
【０１４８】
図１６は、実行期間の集計区間への振り分け例を示す図である。Ｗｅｂサーバ２１で実行されたジョブ６１は、２回の実行期間６１ａ，６１ｂにおいて、処理が実行されている。１回目の実行期間６１ａは、「集計区間１」の時間帯に含まれているため、「集計区間１」に振り分けられる。また実行期間６１ｂは、「集計区間２」の時間帯に含まれているため、「集計区間２」に振り分けられる。
【０１４９】
Ａｐｐサーバ２４，２５で実行されたジョブ６２は、５回の実行期間６２ａ，６２ｂ，６２ｃ，６２ｄ，６２ｅにおいて、処理が実行されている。１回目と２回目との実行期間６２ａ，６２ｂは、「集計区間１」の時間帯に含まれているため、「集計区間１」に振り分けられる。３回目〜５回目の実行期間６２ｃ，６２ｄ，６２ｅは、「集計区間２」の時間帯に含まれているため、「集計区間２」に振り分けられる。
【０１５０】
ＤＢサーバ２６で実行されたジョブ６３〜６６は、各ジョブが１回ずつの実行期間で実行されている。ジョブ６３は、「集計区間１」の時間帯に実行されているため、「集計区間１」に振り分けられる。ジョブ６５，６６は、「集計区間２」の時間帯に実行されているため、「集計区間２」に振り分けられる。
【０１５１】
ジョブ６４は、「集計区間１」と「集計区間２」とに跨って実行されている。このように、実行期間が複数の集計区間を跨り、複数の集計区間に属する実行期間も存在する。この場合、複数の集計区間に属する実行期間が、各集計区間に属する期間ごとに分割される。例えばジョブ６４の全体の実行期間は、「集計区間１」に属する実行期間６４ａと「集計区間２」に属する実行期間６４ｂとに分割される。そして分割後の各実行期間６４ａ，６４ｂが、各集計区間に振り分けられる。
【０１５２】
なお図１５、図１６には、１つの業務処理に応じて行われた一連の処理について示しているが、複数の業務処理が、各階層のサーバにおいて並列で実行される場合もある。
図１７は、並列で処理が実行される状況を示す図である。図１７の例では、「集計区間１」と「集計区間２」との間に、３つの業務処理が並列で実行されている。ジョブ６１〜６６によって１つの業務処理が実行され、ジョブ７１〜７５によって１つの業務処理が実行され、ジョブ８１〜８３によって１つの業務処理が実行されている。なお、図１７において、各ジョブを示す矩形内の文字は、各ジョブのジョブ種を示している。
【０１５３】
このように複数の業務処理が並列で実行される場合も、図１６に示したように、各ジョブの実行期間が、その実行期間を包含する集計区間に振り分けられる。
次にスループットと多重度との算出処理について詳細に説明する。
【０１５４】
図１８は、スループット・多重度算出処理の手順の一例を示すフローチャートである。以下、図１８に示す処理をステップ番号に沿って説明する。
［ステップＳ１４１］集計部１４１は、未処理の集計区間を１つ選択する。例えば集計部１４１は、集計区間情報記憶部１４２に設定されている集計区間を、先頭のエントリから順に選択する。
【０１５５】
［ステップＳ１４２］集計部１４１は、選択した集計区間のスループットを計算する。例えば集計部１４１は、ジョブ種ごとの１ジョブ当たりの正規化したスループット値により、各ジョブに重み付けを行うことで、処理負荷の異なる複数のジョブを処理する場合のスループット算出の正確性を向上させる。集計部１４１は、計算したスループットを、例えば集計区間情報記憶部１４２に格納する。
【０１５６】
［ステップＳ１４３］集計部１４１は、選択した集計区間の多重度を計算する。例えば集計部１４１は、処理中の階層のサーバで選択した集計区間内に存在しているジョブの、集計区間内での処理時間の合計を求める。そして集計部１４１は、求めた合計を集計区間長で除算し、除算結果を集計区間の多重度とする。この多重度は、集計区間内の平均的な多重度を表している。集計部１４１は、計算した多重度を、例えば集計区間情報記憶部１４２に格納する。
【０１５７】
［ステップＳ１４４］集計部１４１は、未処理の集計区間があるか否かを判断する。例えば集計部１４１は、集計区間情報記憶部１４２に設定されている集計区間の最後のエントリの処理が終了した場合、未処理の集計区間はないと判断する。未処理の集計区間がある場合、集計部１４１は、処理をステップＳ１４１に進める。未処理の集計区間がなければ、集計部１４１は、スループット・多重度算出処理を終了する。
【０１５８】
図１９は、性能分析時の集計区間情報記憶部のデータ構造の一例を示す図である。集計区間情報記憶部１４２には、階層ごとの集計区間管理テーブル１４２ａ，１４２ｂ，１４２ｃが格納されている。例えば集計区間管理テーブル１４２ａは、ＤＢサーバ２６の階層に対応する。
【０１５９】
集計区間管理テーブル１４２ａには、集計区間、期間、スループット、および多重度の欄が設けられている。集計区間の欄には、集計区間の名称が設定される。期間の欄には、集計区間の期間が設定される。スループットの欄には、集計区間のスループットが設定される。多重度の欄には、集計区間の多重度が設定される。
【０１６０】
＜＜スループット・多重度計算＞＞
次に、スループットの計算と多重度の計算とについて、詳細に説明する。
＜＜＜スループット計算＞＞＞
まず、スループット計算処理について詳細に説明する。集計部１４１は、集計区間ごとに、その集計区間に属するジョブの処理時間に基づいて、スループットを計算する。この際、集計部１４１は、ジョブ種間の差異を考慮した重み付けを行って、正規化したスループットを計算する。
【０１６１】
ここで、スループットの正規化の有用性について説明する。第２の実施の形態では、分析対象期間を短い集計区間に細分化する。ここで、正規化を行わずに多重度とスループットの関係を求めようとすると、下記の２つの要素が両者の関係における揺らぎとなって、関連性を失わせる可能性がある。すると、多重度とスループットとの関連性を用いたボトルネック判定の信頼性が低下してしまう。
１．異種ジョブ間でのハードウェア資源消費量の差異
２．同種ジョブの個々のジョブ間でのハードウェア資源消費量の差異
特に１．は差異の絶対量が大きく、また、短い時間区間に区切ると、各区間同士の間でジョブ種の混合割合が偏るので、結果として大きな影響を及ぼすことになる。一方、２．の方は、同種ジョブということで、ある程度は平均化した分布（正規分布など）となることが期待できる。
【０１６２】
そこで、第２の実施の形態では、低負荷時に測定したジョブ種ごとの平均処理時間を利用して、異種ジョブ間でのハードウェア資源消費量の差異を正規化することによって、１．の問題を解決した正確なスループットを得る。ジョブ種間の差異を考慮した重みの判断指標となる情報は、予め正規化スループット値記憶部１４３に格納されている。
【０１６３】
図２０は、正規化スループット値記憶部のデータ構造の一例を示す図である。正規化スループット値記憶部１４３には、正規化スループット値テーブル１４３ａが格納されている。正規化スループット値テーブル１４３ａには、ジョブ種、低負荷時の平均処理時間、および正規化されたスループット値の欄が設けられている。
【０１６４】
ジョブ種の欄には、Ｗｅｂ三階層システムのいずれかのサーバで実行されるジョブのジョブ種名が設定される。
低負荷時の平均処理時間の欄には、対応するジョブ種のジョブを、サーバが低負荷時に実行した場合の平均処理時間が設定される。図２０の例では、低負荷時の平均処理時間の欄に、「ｍｓ」単位の数値が設定されている。低負荷時の平均処理時間は、例えば、システムの管理者が、予めＷｅｂ三階層システムの負荷が少ない状態で計測し、正規化スループット値テーブル１４３ａに設定する。
【０１６５】
正規化されたスループット値の欄には、各ジョブ種の１ジョブ当たりの正規化されたスループット値が設定される。例えば階層ごとに、代表ジョブ種が１つずつ選択される。図２０の例では、Ｗｅｂサーバ２１，２２，２３で実行されるジョブ種に関しては、ジョブ種名「Ｗ１」のジョブ種が、代表ジョブ種である。Ａｐｐサーバ２４，２５で実行されるジョブ種に関しては、ジョブ種名「Ａ１」のジョブ種が、代表ジョブ種である。ＤＢサーバ２６で実行されるジョブ種に関しては、ジョブ種名「Ｄ１」のジョブ種が、代表ジョブ種である。各階層の代表ジョブ種に関しては、１ジョブ当たりの正規化されたスループット値は「１．００」である。
【０１６６】
代表ジョブ種以外のジョブ種に関しては、同じ階層の代表ジョブ種と比較し場合に、低負荷時の平均処理時間が何倍となるかを示す数値が、そのジョブ種の１ジョブ当たりの正規化されたスループット値となる。例えばジョブ種名「Ｗ２」のジョブ種は、低負荷時の平均処理時間が、代表ジョブ種（ジョブ種名「Ｗ１」）の平均処理時間の０．６０４倍（１３．４ｍｓ／２２．２ｍｓ）である。従って、ジョブ種名「Ｗ２」のジョブ種の１ジョブ当たりの正規化されたスループット値は、「０．６０４」となる。
【０１６７】
このような１ジョブ当たりの正規化されたスループット値を用いて、集計部１４１は、細分化した各集計区間について、その集計区間内の平均スループットを計算する。すなわち集計部１４１は、低負荷時に収集したジョブ種ごとの平均処理時間を利用して、スループットの重み付けを行う。例えば集計部１４１は、各ジョブの処理（要求を受けてから返信を返すまで）に関し、スループットの基準スコアを「１」とする。そして集計部１４１は、基準スコアに、低負荷時のジョブ種別ごとの平均処理時間を元に計算された１ジョブ当たりの正規化されたスループット値による重み付けを行い、ジョブごとの１ジョブ当たりのスコアを求める。さらに集計部１４１は、ジョブ全体の実行期間のうち、各集計区間に属している割合に応じた比率で、１つのジョブのスコアを、そのジョブの実行期間が属する集計区間に分配する。そして集計部１４１は、分配したスコアを、各集計区間のスループットに加算する。このようなスループットを集計区間ごとに求めることで、スループットの時系列推移が得られる。
【０１６８】
図２１は、スループットの時系列推移の一例を示す図である。図２１では、ＤＢサーバ２６の階層におけるスループットの時系列推移をグラフで表している。図２１に示したグラフは、横軸が時刻、縦軸がスループットである。横軸の１目盛が各集計区間に対応する。
【０１６９】
＜＜＜多重度計算＞＞＞
次に多重度計算処理について詳細に説明する。第２の実施の形態における多重度は、その集計区間内で平均すると、同時に何件のジョブが同時に実行されていたかを示す値である。この多重度は、次の式で求めることができる。
多重度＝集計区間内でのすべてのジョブの処理時間の合計÷集計区間の長さ
最下位の階層以外の階層における多重度の計算では、「ジョブの処理時間」には、その階層において処理が行われている時間だけを含め、他の階層へ処理を送ってから返信を待っている間の時間は含めない。
【０１７０】
図１６の例を用い、多重度の計算例を示す。Ｗｅｂサーバ２１，２２，２３の階層の「集計区間１」の多重度は「０．１４」（＝１４／１００）、「集計区間２」の多重度は「０．１１」（＝１１／１００）である。Ａｐｐサーバ２４，２５の階層の「集計区間１」の多重度は「０．２８」（＝（１９＋９）／１００）、「集計区間２」の多重度は「０．４３」（＝（１０＋１２＋２１）／１００）である。ＤＢサーバ２６の階層の「集計区間１」の多重度は「０．１９」（＝（９＋１０）／１００）、「集計区間２」の多重度は「０．３９」（＝（２４＋８＋７）／１００）である。
【０１７１】
なお図１７の場合のように、複数の業務処理が並列実行されている場合にも、この計算法は変わらない。すなわち、集計区間に存在する複数の業務処理のジョブを区別することなく、各ジョブの処理時間の総和を計算して、計算された総和を集計区間長で割ればよい。
【０１７２】
このような多重度を集計区間ごとに求めることで、多重度の時系列推移が得られる。
図２２は、多重度の時系列推移の一例を示す図である。図２２では、ＤＢサーバ２６の階層における多重度の時系列推移をグラフで表している。図２２に示したグラフは、横軸が時刻、縦軸が多重度である。横軸の１目盛が各集計区間に対応する。
【０１７３】
＜＜飽和多重度算出＞＞
次に、飽和多重度算出処理について詳細に説明する。
性能分析部１４４は、スループットと多重度との関係から、飽和多重度を動的に求める。例えば性能分析部１４４は、各集計区間について計算されたスループットと多重度とから、両者の関係を求め、多重度の上昇に伴うスループットの上昇が止まる飽和多重度の値を求める。
【０１７４】
多重度の上昇に伴うスループットの上昇が止まる位置があることは、例えば、各集計区間の多重度とスループットとの関係を散布図で表すことで容易に理解できる。
図２３は、多重度とスループットとの関係の一例を示す散布図である。図２３に示した散布図は、横軸（Ｘ軸）に多重度、縦軸にスループットを採っている。そして各集計区間のスループットと多重度とに応じた点を、図中にプロットしている。
【０１７５】
図２３に示した散布図からも分かるように、多重度がある程度の値までは、多重度の上昇に伴ってスループットは上昇するが、それ以降は多重度が上昇してもスループットは上昇しなくなる。性能分析部１４４は、この境界となる多重度を飽和多重度として求める。
【０１７６】
図２４は、飽和多重度算出処理の一例を示すフローチャートである。以下、図２４に示す処理をステップ番号に沿って説明する。
［ステップＳ１５１］性能分析部１４４は、多重度の最小値と最大値とを求める。例えば性能分析部１４４は、現在処理対象となっている階層の集計区間管理テーブルの多重度の欄から、設定されている値の最小値と最大値とを抽出する。
【０１７７】
［ステップＳ１５２］性能分析部１４４は、多重度の最小値と最大値との間を、等間隔に細分化する。細分化して得られた多重度の細分化区間を、多重度区間とする。ここで各多重度区間内の下限値をその多重度区間の多重度の区間開始値とし、多重度区間内の上限値をその多重度区間の多重度の終了値とする。
【０１７８】
例えば性能分析部１４４は、多重度の最小値と最大値の間を、所定数（例えば１００）の多重度区間に分割する。なお所定数に分割するのではなく、一定間隔ごと（例えば多重度０．１ごと）に分割してもよい。例えば、最少多重度「０」、最大多重度「５０」であれば、多重度「０」から多重度「５０」の間を０．５刻みで１００分割する。
【０１７９】
［ステップＳ１５３］性能分析部１４４は、多重度が少ない方から順に多重度区間を選択する。
［ステップＳ１５４］性能分析部１４４は、選択した多重度区間に含まれる多重度を有する集計区間の平均多重度ｌｄiと、それらの集計区間の平均スループットとを計算する。
【０１８０】
［ステップＳ１５５］性能分析部１４４は、直前に選択した多重度区間（隣接する多重度区間）との間の、多重度増加に伴うスループットの上昇率（傾き）を計算する。スループットの傾きは、例えば直前に選択した多重度区間との比較における平均スループットの変化量を、直前に選択した多重度区間との比較における平均多重度ｌｄiの変化量で除算した値である。
【０１８１】
ｉ番目（ｉは１以上１００以下の整数）に選択された多重度区間の傾きδiの計算を式で表すと、例えば以下のような式となる。
【０１８２】
【数１】
2014038578.tif 000003
【０１８３】
［ステップＳ１５６］性能分析部１４４は、ステップＳ１５５で計算した傾きが、閾値より小さいか否かを判断する。傾きの閾値としては、例えば平均多重度が最も小さな多重度区間の傾きδ1に、１未満の所定の係数を掛けた値（例えば０．２δ1）とする。性能分析部１４４は、傾きが所定の閾値より小さければ、処理をステップＳ１５９に進める。また性能分析部１４４は、傾きが所定の閾値以上であれば、処理をステップＳ１５７に進める。
【０１８４】
［ステップＳ１５７］性能分析部１４４は、未処理の多重度区間があるか否かを判断する。性能分析部１４４は、未処理の多重度区間があれば、処理をステップＳ１５３に進める。また性能分析部１４４は、すべての多重度区間の処理が終了していれば、処理をステップＳ１５８に進める。
【０１８５】
［ステップＳ１５８］性能分析部１４４は、すべての多重度区間において、傾きが閾値以上だった場合、飽和多重度をステップＳ１５１で求められた多重度の最大値に設定し、飽和多重度算出処理を終了する。
【０１８６】
［ステップＳ１５９］性能分析部１４４は、現在選択している多重度区間の多重度の区間開始値を飽和多重度に決定する。
例えば多重度「０」から多重度「５０」の間を０．５刻みで１００分割した場合において、１＜ｉ≦９の範囲まで傾きが閾値を下回らなかったとする。この場合、１０番目の多重度区間の多重度の範囲「４．５〜５．０」の区間開始値「４．５」（＝０．５×９）が、飽和多重度に決定される。
【０１８７】
このように、分割した多重度が小さな多重度区間から順番に、傾きの値が一定の閾値（例えば０．２δ1）を下回らないかどうかが調べられ、最初に下回る多重度区間が求められる。そして求められた多重度区間の多重度における区間開始値が飽和多重度となる。
【０１８８】
＜＜ボトルネック判定＞＞
次に、飽和多重度に基づくボトルネック判定処理について説明する。性能分析部１４４は、飽和多重度を超えていない集計区間の割合に応じて、各階層の処理能力の余力を算出する。そして性能分析部１４４は、飽和多重度を超えていない集計区間の割合が所定の値より少ない階層を検出すると、その階層がボトルネックになっていると判断する。
【０１８９】
すなわち、図２３に示した散布図の各ドットは、１つ１つの集計区間に相当する。これらの集計区間の中で、多重度が飽和多重度を下回っていた区間は、その階層の処理能力に余力が残っていたと考えられる。そのような集計区間が、集計区間の総数に占める割合を求め、それを処理能力の余力とする。例えば、１８０秒分の時系列データを同時に処理する場合は、その中には１８００の集計区間が存在する（集計区間長が１００ｍｓの場合）。ここで１８００の集計区間の内の３８５の集計区間で多重度が飽和多重度を下回っていた場合、２１．４％（＝３８５／１８００×１００）の区間で余力を有していたという計算になる。
【０１９０】
例えば、第２の実施の形態では、性能分析部１４４は、飽和多重度を超えていない集計区間が第１の閾値を下回った場合に、その階層の処理能力の限界を超えた完全飽和状態であると判断する。そして、性能分析部１４４は、完全飽和状態となった階層をボトルネック原因と判定して報告する。
【０１９１】
また性能分析部１４４は、飽和多重度を超えていない集計区間の割合が、予め設定した第１の閾値より高い第２の閾値を下回った場合に、その階層は部分的に処理能力の限界を超えている半飽和状態であると判断する。これは、複数の階層が同時に半飽和状態に陥って、複数階層システム全体としてはボトルネック状態となっている可能性があるためである。
【０１９２】
以下に、ボトルネック判定処理の手順について説明する。
図２５は、ボトルネック判定処理の手順の一例を示すフローチャートである。以下、図２５に示す処理をステップ番号に沿って説明する。
【０１９３】
［ステップＳ１６１］性能分析部１４４は、集計区間を１つ選択する。例えば性能分析部１４４は、処理対象となっている階層に対応する集計区間管理テーブル（図１９参照）の上位から順に、集計区間を選択する。
【０１９４】
［ステップＳ１６２］性能分析部１４４は、選択した集計区間の多重度が、飽和多重度以下か否かを判断する。性能分析部１４４は、飽和多重度以下であれば、処理をステップＳ１６３に進める。また性能分析部１４４は、飽和多重度より大きければ、処理をステップＳ１６４に進める。
【０１９５】
［ステップＳ１６３］性能分析部１４４は、未飽和区間数をカウントアップする。なお未飽和区間数は、ボトルネック判定処理の開始時に「０」に初期化されている。
［ステップＳ１６４］性能分析部１４４は、未処理の集計区間があるか否かを判断する。性能分析部１４４は、未処理の集計区間があれば、処理をステップＳ１６１に進める。性能分析部１４４は、未処理の集計区間がなければ、処理をステップＳ１６５に進める。
【０１９６】
［ステップＳ１６５］性能分析部１４４は、集計区間の総数に対する未飽和区間の割合が第１の閾値未満か否かを判断する。第１の閾値は、予め性能分析部１４４に設定されている。例えば性能分析部１４４は、未飽和区間数を集計区間の総数で除算し、未飽和区間の割合を求める。そして性能分析部１４４は、未飽和区間の割合と第１の閾値を比較し、未飽和区間の割合が第１の閾値未満か否かを判断する。性能分析部１４４は、未飽和区間の割合が第１の閾値未満であれば、処理をステップＳ１６６に進める。また性能分析部１４４は、未飽和区間の割合が第１の閾値以上であれば、処理をステップＳ１６７に進める。
【０１９７】
［ステップＳ１６６］性能分析部１４４は、現在の処理対象となっている階層が、ボトルネック要因であると判定する。性能分析部１４４は、例えば判定結果をモニタ１１などに出力する。その後、ボトルネック判定処理が終了する。
【０１９８】
［ステップＳ１６７］性能分析部１４４は、集計区間の総数に対する未飽和区間の割合が第２の閾値未満か否かを判断する。第２の閾値は、第１の閾値より大きな値であり、予め性能分析部１４４に設定されている。性能分析部１４４は、未飽和区間の割合が第２の閾値未満であれば、処理をステップＳ１６８に進める。また性能分析部１４４は、未飽和区間の割合が第２の閾値以上であれば、ボトルネック判定処理を終了する。
【０１９９】
［ステップＳ１６８］性能分析部１４４は、現在の処理対象となっている階層が、複合的なボトルネック要因の候補であると判定する。複合的なボトルネック要因とは、他の階層との複合的要因によって発生しているボトルネックである。性能分析部１４４は、例えば判定結果をモニタ１１などに出力する。その後、ボトルネック判定処理が終了する。
【０２００】
このようにして、処理能力が残存していた集計区間（未飽和の集計区間）の割合に応じて、その階層が、複数階層システムのボトルネックになっているかどうかを判定することができる。
【０２０１】
＜多重度制御処理＞
ボトルネック判定処理の結果、少なくとも１つの階層でボトルネック要因であると判定されると、ボトルネック要因と判定された階層が、性能分析部１４４から多重度制御部１４５に通知される。すると多重度制御部１４５は、ボトルネック有りと認識する。多重度制御部１４５は、ボトルネックがある場合、他の機能と連携して許容多重度分析処理を実行し、ボトルネック層において許容可能な多重度の設定範囲を分析する。
【０２０２】
図２６は、多重度制御処理の手順の一例を示すフローチャートである。以下、図２６に示す処理をステップ番号に沿って説明する。
［ステップＳ２０１］メッセージ解析部１２１は、取得したファイルに含まれるＩＰパケットに基づいて、メッセージを再構築する。メッセージ解析部１２１は、再構築したメッセージを、メッセージデータ記憶部１２２に時系列に格納する。
【０２０３】
［ステップＳ２０２］メッセージフロー検出部１３２は、メッセージデータ記憶部１２２に格納されたメッセージから、１つの業務処理リクエストに応じて複数階層システム内で発行された一連のメッセージ送受関係を示すメッセージフローを検出する。この処理の詳細は、性能分析におけるメッセージフロー検出処理（図７のステップＳ１２２）と同様である。
【０２０４】
［ステップＳ２０３］メッセージフロー検出部１３２は、検出したメッセージフローに含まれるリクエストメッセージに応じて、各階層のサーバで実行される処理のジョブ種を判定する。この処理の詳細は、性能分析におけるジョブ種判定処理（図７のステップＳ１２３）の処理と同様である。
【０２０５】
なおステップＳ２０１〜Ｓ２０３の処理は、多重度制御処理において改めて実行せずに、性能分析処理におけるステップＳ１２１〜Ｓ１２３で実行された処理結果を使用することもできる。その場合、ステップＳ１２１〜Ｓ１２３の処理によりメッセージフロー情報記憶部１３３に格納されたメッセージフロー情報を、ステップＳ２０１〜Ｓ２０３の処理結果として用いる。
【０２０６】
［ステップＳ２０４］集計部１４１は、分析対象期間を、十分に細かい粒度で分割する。この処理の詳細は、性能分析における集計区間への分割処理（図１４のステップＳ１３１）と同様である。
【０２０７】
［ステップＳ２０５］集計部１４１は、各集計区間のＳＬＡ充足スループットを計算する。この処理の詳細は後述する（図２７参照）。
［ステップＳ２０６］多重度制御部１４５は、多重度制限値の下限値を算出する。この処理の詳細は後述する（図３１参照）。
【０２０８】
［ステップＳ２０７］多重度制御部１４５は、多重度制限値の上限値を算出する。この処理の詳細は後述する（図３４参照）。
多重度制限値の下限値から上限値までの範囲が、ボトルネックとなっている階層におけるサーバで許容可能な多重度の範囲である。
【０２０９】
［ステップＳ２０８］多重度制御部１４５は、ボトルネックとなっている階層のサーバにおける多重度が、許容可能な多重度の範囲内となるように、ボトルネックとなっている階層のサーバ、またはそのサーバの上位層のサーバに対して多重度制限値の設定を行う。サーバへの多重度制限値の設定では、そのサーバで並列実行可能なジョブ数の最大値（最大多重度）が設定される。この処理の詳細は後述する（図３４参照）。
【０２１０】
このような手順で多重度分析が行われる。以下、多重度制御処理におけるステップＳ２０５〜Ｓ２０８の処理を詳細に説明する。
＜＜ＳＬＡ充足スループット計算＞＞
次に、ＳＬＡ充足スループット計算処理について説明する。
【０２１１】
図２７は、ＳＬＡ充足スループット計算処理の手順の一例を示すフローチャートである。以下、図２７に示す処理をステップ番号に沿って説明する。
［ステップＳ２１１］集計部１４１は、未選択の集計区間を１つ選択する。
【０２１２】
［ステップＳ２１２］集計部１４１は、選択した集計区間内でのボトルネック層の平均多重度を計算する。例えば集計部１４１は、処理中の階層のサーバで選択した集計区間内に存在しているジョブの、集計区間内での処理時間の合計を求める。そして集計部１４１は、求めた合計を集計区間長で除算し、除算結果を集計区間の多重度とする。これを式で表すと、以下の式になる。
多重度＝集計区間内でのすべてのジョブの処理時間の合計÷集計区間の長さ
集計部１４１は、計算した多重度を、例えば集計区間情報記憶部１４２に格納する。
【０２１３】
［ステップＳ２１３］集計部１４１は、選択した集計区間内にボトルネック層で実行されたジョブを含むトランザクションのＳＬＡ充足性をチェックする。例えば集計部１４１は、メッセージフロー情報記憶部１３３内の各メッセージフロー情報から、選択した集計区間内に実行されたボトルネック層のジョブを抽出する。次に集計部１４１は、抽出したジョブを含むメッセージフロー情報に基づいて、ＨＴＴＰリクエストからＨＴＴＰレスポンスまでの時間（応答時間）を計算する。集計部１４１は、応答時間が、予め設定されたＳＬＡ以下であれば、抽出したジョブを含むトランザクションは、ＳＬＡを充足していると判断する。他方、集計部１４１は、応答時間が、予め設定されたＳＬＡを超えていれば、抽出したジョブを含むトランザクションは、ＳＬＡを充足していないと判断する。
【０２１４】
［ステップＳ２１４］集計部１４１は、ＳＬＡ非充足トランザクションにおける、ボトルネック層のジョブを消去する。例えば集計部１４１は、メッセージフロー情報記憶部１３３内のＳＬＡ非充足トランザクションに対応するメッセージフロー情報から、ボトルネック層のジョブに関するリクエストとレスポンスとを削除する。なお多重度制御処理では、ボトルネック層以外のジョブに関する情報は利用しない。そのため、集計部１４１は、メッセージフロー情報記憶部１３３内のＳＬＡ非充足トランザクションに対応するメッセージフロー情報を、メッセージフロー情報記憶部１３３から削除してもよい。
【０２１５】
［ステップＳ２１５］集計部１４１は、選択した集計区間内の残存したジョブを利用して、スループット（ＳＬＡ充足スループット）を計算する。例えば集計部１４１は、メッセージフロー情報記憶部１３３内の各メッセージフロー情報から、選択した集計区間内に実行されたボトルネック層の残存するジョブを抽出する。そして集計部１４１は、集計区間ごとに、その集計区間に属するジョブの処理時間に基づいて、ＳＬＡ充足スループットを計算する。この際、集計部１４１は、ジョブ種間の差異を考慮した重み付けを行って、正規化したＳＬＡ充足スループットを計算する。ジョブ種間の差異を考慮した重みの判断指標となる情報は、予め正規化スループット値記憶部１４３に格納されている。
【０２１６】
［ステップＳ２１６］集計部１４１は、未選択の集計区間があるか否かを判断する。集計部１４１は、未選択の集計区間があれば、処理をステップＳ２１１に進める。また集計部１４１は、未選択の集計区間がなければ、ＳＬＡ充足スループット計算処理を終了する。
【０２１７】
このようにＳＬＡ充足スループット計算処理では、まずメッセージフローごとに、ＳＬＡ充足性の有無が判定される。すなわち集計部１４１は、ボトルネック階層において、各集計区間内で実行されたすべてのジョブに関して、スループットを計算する前に、各ジョブの生成元となったＨＴＴＰリクエストの応答時間をログの中から調べる。そして集計部１４１は、該当するＨＴＴＰリクエストの応答時間が、予め定められていたＳＬＡ（もしくはそれに類する目標値）を充足しているか確認する。もし充足していない場合は、集計部１４１は、ＳＬＡを充足しないＨＴＴＰリクエストに応じて実行された、ボトルネック層のジョブについては、ＳＬＡ充足スループット算出時に、そのジョブを包含する集計区間内で実行されたジョブ群から除外する。
【０２１８】
図２８は、ＳＬＡ充足スループット算出から除外されるジョブの例を示す図である。図２８には、図１２に示したメッセージフローで表されたトランザクションと同種のトランザクションの実行時に、ＤＢ層がボトルネックとなっていた場合の例が示されている。
【０２１９】
図２８に示すトランザクションでは、端末装置からのＨＴＴＰリクエストに応じて、Ｗｅｂサーバ２１でジョブ９１が実行されている。ジョブ９１の実行過程で、Ｗｅｂサーバ２１ａは、Ａｐｐサーバ２４に対してＩＩＯＰリクエストを送信している。Ａｐｐサーバ２４では、ＩＩＯＰリクエストに応じてジョブ９２が実行されている。ジョブ９２の実行過程で、Ａｐｐサーバ２４は、ＤＢサーバ２６に対して、ＤＢリクエストを４回送信している。ＤＢサーバ２６では、ＤＢリクエストそれぞれに応じて、ジョブ９３，９４，９５，９６が実行されている。
【０２２０】
ＤＢ層ボトルネックになった場合、ＤＢサーバ２６で実行されるジョブの実行期間が長くなる。その結果、図２８のトランザクションは、図１２に示したトランザクションに比べて、ＤＢサーバ２６におけるジョブ９３，９４，９５，９６の実行期間が長くなっている。その結果、Ｗｅｂサーバ２１へのＨＴＴＰリクエストの入力から、ＨＴＴＰレスポンスの出力までの時間（応答時間）が長期化している。
【０２２１】
ここで、ＳＬＡで要求される応答時間が１秒であるものとする。図２８の例では、応答時間が１以上となっている。この場合、ＤＢサーバ２６のジョブ９３，９４，９５，９６は、すべてＳＬＡスループット充足スループットの算出時に、ジョブ９３，９４，９５，９６を包含する集計区間内で実行されたジョブ群から除外される。すなわち、ジョブ９３，９４，９５，９６については、ＤＢサーバ２６で実行されていないものとして、ＳＬＡ充足スループットの計算が行われる。
【０２２２】
次に、ＳＬＡ充足スループットの計算処理について説明する。
ＳＬＡ充足スループットの計算は、ＳＬＡ充足性の有無が判定の結果、除外されずに残ったジョブの処理時間に基づいて行われる。
【０２２３】
以下、図１６に示した集計区間のＳＬＡ充足スループット計算例を示す。なお図１６に示したように、各階層のジョブ６１〜６６のうち、各階層のサーバで処理を行っている期間のみが実行期間となり、他の階層へリクエストメッセージを送信してからレスポンスメッセージを待っている期間は、実行期間から除外される。
【０２２４】
まずＷｅｂサーバ２１の階層におけるＳＬＡ充足スループットの計算例を示す。図１６の例では、ジョブ６１の２つの実行期間６１ａ，６１ｂのうち、１回目の実行期間６１ａのみが「集計区間１」に含まれ、２回目の実行期間は「集計区間２」に含まれる。実行期間６１ａの長さ（処理時間）は「１４ｍｓ」であり、実行期間６１ｂの長さ（処理時間）は「１１ｍｓ」である。するとジョブ６１の合計の処理時間は「２５ｍｓ」である。またジョブ６１のジョブ種は「Ｗ１」であり、正規化スループット値テーブル１４３ａ（図２０参照）では、１ジョブ当たりの正規化されたスループット値は「１．００」である。正規化されたスループット値で示されるスコア「１．００」が、「集計区間１」と「集計区間２」とに含まれる処理時間比率で分配される。すると「集計区間１」のスコアが「０．５６」（＝１．００×１４／２５）、「集計区間２」のスコアが「０．４４」（＝１．００×１１／２５）となる。得られたスコアが、Ｗｅｂサーバ２１，２２，２３の階層における各集計区間のＳＬＡ充足スループットに加算される。
【０２２５】
次にＡｐｐサーバ２４，２５の階層におけるＳＬＡ充足スループットの計算例を示す。図１６の例では、ジョブ６２の５つの実行期間６２ａ，６２ｂ，６２ｃ，６２ｄ，６２ｅのうち、２つの実行期間６２ａ，６２ｂが「集計区間１」に含まれ、３つの実行期間６２ｃ，６２ｄ，６２ｅが「集計区間２」に含まれる。実行期間６２ａの長さは「１９ｍｓ」、実行期間６２ｂの長さは「９ｍｓ」、実行期間６２ｃの長さ（処理時間）は「１０ｍｓ」、実行期間６２ｄの長さは「１２ｍｓ」、実行期間６１ｅの長さは「２１ｍｓ」である。するとジョブ６２の合計の処理時間は「７１ｍｓ」である。またジョブ６２のジョブ種は「Ａ１」であり、正規化スループット値テーブル１４３ａ（図２０参照）では、１ジョブ当たりの正規化されたスループット値は「１．００」である。正規化されたスループット値で示されるスコア「１．００」が「集計区間１」と「集計区間２」とに含まれる処理時間比率で分配される。すると「集計区間１」のスコアが「０．３９４」（＝１．００×（１９＋９）／７１）、「集計区間２」のスコアが「０．６０６」（＝１．００×（１０＋１２＋２１）／７１）となる。得られたスコアが、Ａｐｐサーバ２４，２５の階層における各集計区間のＳＬＡ充足スループットに加算される。
【０２２６】
次にＤＢサーバ２６の階層におけるＳＬＡ充足スループットの計算例を示す。図１６の例では、ジョブ６３の実行期間は、全体が「集計区間１」に含まれ、処理時間は「９ｍｓ」である。またジョブ６３のジョブ種は「Ｄ１」であり、正規化スループット値テーブル１４３ａ（図２０参照）では、１ジョブ当たりの正規化されたスループット値は「１．００」である。そこで、正規化されたスループット値で示されるスコア「１．００」が、ＤＢサーバ２６の階層における「集計区間１」のＳＬＡ充足スループットに加算される。
【０２２７】
ジョブ６４の実行期間は、図１６の例では、前半の実行期間６４ａが「集計区間１」に含まれ、後半の実行期間６４ｂは「集計区間２」に含まれる。実行期間６４ａの長さ（処理時間）は「１０ｍｓ」であり、実行期間６４ｂの長さは「２４ｍｓ」である。するとジョブ６４の合計の処理時間は「３４ｍｓ」である。またジョブ６４のジョブ種は「Ｄ２」であり、正規化スループット値テーブル１４３ａ（図２０参照）では、１ジョブ当たりの正規化されたスループット値は「３．７２」である。正規化されたスループット値で示されるスコア「３．７２」が、「集計区間１」と「集計区間２」とに含まれる処理時間比率で分配される。すると「集計区間１」のスコアが「１．０９」（＝３．７２×１０／３４）、「集計区間２」のスコアが「２．６３」（＝３．７２×２４／３４）となる。得られたスコアが、ＤＢサーバ２６の階層における各集計区間のＳＬＡ充足スループットに加算される。
【０２２８】
ジョブ６５の実行期間は、図１６の例では、全体が「集計区間２」に含まれ、処理時間は「８ｍｓ」である。またジョブ６５のジョブ種は「Ｄ３」であり、正規化スループット値テーブル１４３ａ（図２０参照）では、１ジョブ当たりの正規化されたスループット値は「０．７９６」である。そこで、正規化されたスループット値で示されるスコア「０．７９６」が、ＤＢサーバ２６の階層における「集計区間２」のＳＬＡ充足スループットに加算される。
【０２２９】
ジョブ６６の実行期間は、図１６の例では、全体が「集計区間２」に含まれ、処理時間は「７ｍｓ」である。またジョブ６６のジョブ種は「Ｄ３」であり、正規化スループット値テーブル１４３ａ（図２０参照）では、１ジョブ当たりの正規化されたスループット値は「０．７９６」である。そこで、正規化されたスループット値で示されるスコア「０．７９６」が、ＤＢサーバ２６の階層における「集計区間２」のＳＬＡ充足スループットに加算される。
【０２３０】
以上よりＤＢサーバ２６の階層における「集計区間１」のＳＬＡ充足スループットは、ジョブ６３に基づくスコアと、ジョブ６４の実行期間６４ａに基づくスコアとの合計となり、「２．０９」となる。またＤＢサーバ２６の階層における「集計区間２」のＳＬＡ充足スループットは、ジョブ６４の実行期間６４ｂに基づくスコア、および２つのジョブ６５，６６それぞれに基づくスコアの合計となり、「４．２２２」となる。
【０２３１】
なお、図１７に示したように、複数の業務処理が並列実行されている場合は、階層ごとに、各集計区間において、各業務処理に関するジョブによるスコアの総和が求められ、得られた総和が、各階層の集計区間ごとのＳＬＡ充足スループットとなる。
【０２３２】
なお、このようなＳＬＡ充足スループットの計算と同様の方法で、性能分析時のスループット計算（図１８のステップＳ１４２）も行うことができる。ただし、性能分析時のスループット計算では、各ジョブが属するトランザクションのＳＬＡの充足の有無に関係なく、すべてのジョブに基づいてスループットが計算される。他方、多重度制御処理時のＳＬＡ充足スループット計算では、ＳＬＡを充足するトランザクションに属するジョブのみに基づいてＳＬＡ充足スループットが計算される。また性能分析時のスループット計算では、すべての階層に関してスループットが計算されるが、多重度分析時のＳＬＡ充足スループット計算では、ボトルネックとなる階層のＳＬＡ充足スループットのみが計算される。
【０２３３】
図２９は、多重度分析時の集計区間情報記憶部のデータ構造の一例を示す図である。多重度分析時には、集計区間情報記憶部１４２に、ボトルネック層の集計区間管理テーブル１４２ｄ格納されている。図２９には、ＤＢ層がボトルネックとなっている場合の例が示されており、集計区間管理テーブル１４２ｄはＤＢサーバ２６の階層に対応する。
【０２３４】
集計区間管理テーブル１４２ｄには、集計区間、期間、ＳＬＡ充足スループット、および多重度の欄が設けられている。集計区間の欄には、集計区間の名称が設定される。期間の欄には、集計区間の期間が設定される。ＳＬＡ充足スループットの欄には、集計区間のＳＬＡ充足スループットが設定される。多重度の欄には、集計区間の多重度が設定される。
【０２３５】
＜＜多重度制限値の下限値算出＞＞
次に多重度制限値の下限値算出処理について詳細に説明する。ボトルネック層での各集計区間の多重度とＳＬＡ充足スループットを時系列推移で表すと、それぞれ図２１、図２２に示した２つのグラフとなる。いずれも、Ｘ軸の１目盛が各集計区間（ここでは１００ｍｓ）に対応する。これらの２つのグラフ上の、各集計区間における平均多重度とＳＬＡ充足スループットの値をそれぞれＸ軸とＹ軸にとって、散布図を描くと、図３０のようになる。
【０２３６】
図３０は、多重度とＳＬＡ充足スループットとの関係を示す散布図である。図３０に示すように、多重度がある程度の値までは、多重度の上昇に伴ってスループットは上昇するが、それ以降は多重度が上昇してもスループットは上昇しなくなる。この境界となる多重度は、例えば、性能分析処理と同様の飽和多重度として求めることができる。すなわち、飽和多重度を多重度の下限値とすることができる。
【０２３７】
なお性能分析における飽和多重度算出処理（図２４参照）では、多重度の増加に対するスループットの上昇率（傾き）を求め、その傾きが閾値より小さくなったときの多重度を、飽和多重度としているが、他の手法で飽和多重度を算出することもできる。例えば、様々な統計的手法を用いることで、飽和多重度をより正確に求めることができる。以下に、統計的手法を用いた飽和多重度の算出例を示す。
【０２３８】
以下に示す手法では、多重度とＳＬＡ充足スループットとの間の関係の特徴を利用している。すなわち多重度の値が低い時は多重度とＳＬＡ充足スループットとは正比例に近い関係となり、多重度の増加に対するＳＬＡ充足スループットの増加を示す傾きの値の分散は小さい。その階層の処理能力が限界（ボトルネック）に近づくと、多重度とＳＬＡ充足スループットとのそれ以前の関係が急激に崩れ、分散が大きくなり、傾きの値の統計的信頼区間が広がる。このような特徴を利用し、多重度とＳＬＡ充足スループットとの関係が変化する境界を、統計的手法を用いて検出ることによって、データの細かなバラつきに影響されずに、飽和多重度を求めることができる。
【０２３９】
例えば多重度制御部１４５は、多重度の最小値と最大値の間を、一定数（例えば１００）もしくは一定間隔ごと（例えば多重度０．１ごと）に分割する。図３０の場合だと、例えば０と５０の間を０．５刻みで１００分割されている。なお以下の説明では、５０を超えている多重度は無視するものとする。
【０２４０】
分割した多重度区間ごとに、その範囲に属する多重度を持つすべての組（多重度とＳＬＡ充足スループットとの組）から、平均多重度と平均ＳＬＡ充足スループットを計算する（１≦ｉ≦１００）。
【０２４１】
次に多重度制御部１４５は、隣接する多重度区間の間で、両者の平均多重度と平均ＳＬＡ充足スループットの変化量から、変化量の傾きδiを求める。傾きδiは、性能分析時における傾き計算（図２４のステップＳ１５５）と同様に、以下の式によって算出できる。
【０２４２】
【数２】
2014038578.tif 000004
【０２４３】
分割した多重度区間の小さな方から順にＮ（Ｎは１＜Ｎ≦１００の整数）個の区間について、先に求めた傾きを使って、その統計上の信頼区間を以下の式で計算していく。
【０２４４】
【数３】
2014038578.tif 000005
【０２４５】
ここで、１．９６は９５％信頼区間の定数である。
この信頼区間の下限が、予め定めておいた閾値を下回らない範囲で最大となるＮを求め、そのときの多重度を飽和多重度とする。なお信頼区間の下限とは、式３において「±」で示された符号が「−」の時の値である。また第２の実施の形態では、閾値として０．２δ1を利用する。例えば、１＜Ｎ≦９の範囲まで信頼区間の下限が閾値を下回らなかったとすると、飽和多重度は４．５（＝０．５×９）となる。この飽和多重度が、多重度制限値の下限値となる。
【０２４６】
以下、多重度制限値の下限値算出処理の手順について詳細に説明する。
図３１は、多重度制限値の下限値算出処理の手順の一例を示すフローチャートである。以下、図３１に示す処理をステップ番号に沿って説明する。
【０２４７】
［ステップＳ２２１］多重度制御部１４５は、多重度の最小値と最大値とを求める。例えば多重度制御部１４５は、集計区間情報記憶部１４２に格納された集計区間管理テーブル１４２ｄの多重度の欄から、設定されている値の最小値と最大値とを抽出する。
【０２４８】
［ステップＳ２２２］多重度制御部１４５は、多重度の最小値と最大値との間を、等間隔に細分化する。細分化して得られた多重度の細分化区間を、多重度区間とする。ここで各多重度区間内の下限値をその多重度区間の多重度の区間開始値とし、多重度区間内の上限値をその多重度区間の多重度の終了値とする。
【０２４９】
［ステップＳ２２３］多重度制御部１４５は、多重度が少ない方から順に多重度区間を選択する。
［ステップＳ２２４］多重度制御部１４５は、選択した多重度区間に含まれる多重度を有する集計区間の平均多重度と、それらの集計区間の平均ＳＬＡ充足スループットとを計算する。
【０２５０】
［ステップＳ２２５］多重度制御部１４５は、直前に選択した多重度区間（隣接する多重度区間）との間の、多重度増加に伴うスループットの上昇率（傾き）を計算する。傾きは、前述の式（２）で計算できる。
【０２５１】
［ステップＳ２２６］多重度制御部１４５は、傾きの分布の統計的な信頼区間を計算する。例えば多重度制御部１４５は、上記式３で得られる値を信頼区間とする。
［ステップＳ２２７］多重度制御部１４５は、信頼区間の下限が閾値より小さいか否かを判断する。閾値としては、例えば０．２δ1が用いられる。δ1は、式２に示すように、１番目の多重度区間（ｉ＝１）の平均ＳＬＡ充足スループットを、１番目の多重度区間（ｉ＝１）の平均多重度で除算した値である。多重度制御部１４５は、信頼区間の下限が閾値より小さい場合、処理をステップＳ２３０に進める。また多重度制御部１４５は、信頼区間の下限が閾値以上の場合、処理をステップＳ２２８に進める。
【０２５２】
［ステップＳ２２８］多重度制御部１４５は、未処理の多重度区間があるか否かを判断する。多重度制御部１４５は、未処理の多重度区間があれば、処理をステップＳ２２３に進める。また多重度制御部１４５は、すべての多重度区間の処理が終了していれば、処理をステップＳ２２９に進める。
【０２５３】
［ステップＳ２２９］多重度制御部１４５は、すべての多重度区間において、信頼区間の下限が閾値以上だった場合、多重度制限値の下限値は、現在のサーバにおける多重度制限値より大きいと判断し、多重度制限値の下限値算出処理を終了する。
【０２５４】
［ステップＳ２３０］多重度制御部１４５は、信頼区間の下限が閾値より小さい場合、現在選択している多重度区間における多重度の区間開始値を、多重度制限値の下限値に決定する。
【０２５５】
このように、分割した多重度が小さな多重度区間から順番に、信頼区間の下限が一定の閾値（例えば０．２δ1）を下回らないかどうかが調べられ、最初に下回る多重度区間が求められる。そして求められた多重度区間における多重度の区間開始値が、多重度制限値の下限値となる。
【０２５６】
＜＜多重度制限値の上限値＞＞
次に多重度制限値の上限値について説明する。図３０のグラフに示すように、多重度が上がって飽和多重度に達した後で、さらに多重度が大きくなると、ＳＬＡ充足スループットは一定値の最大スループットで推移する。その後、飽和多重度（多重度制限値の下限値）を超えた多重度の増加によってスループットは増加せずに応答時間だけが伸びていく。多重度が大きくなりすぎた結果としてＳＬＡを充足しないトランザクションが出始めた時点で、ＳＬＡ充足スループットの低下が始まる。
【０２５７】
この場合、多重度制御部１４５は、多重度が上がって飽和多重度に達した後で、ＳＬＡ充足スループットが一定値の最大スループットで推移する区間を求める。第２の実施の形態では、多重度制御部１４５は、分割した多重度区間のうち、信頼区間の下限が閾値を上回った多重度区間について、ｔ検定を行う。ｔ検定は、２つの集合の分布の間に、有意な差があるか否かを判定する統計的手法の１つである。多重度制御部１４５は、ｔ検定により、ＳＬＡ充足スループットの分布が有意に異なることなく推移し続ける区間を求めることができる。ＳＬＡ充足スループットが有意に同じでなくなった（低下を始めた）多重度が、多重度制限値の上限値となる。
【０２５８】
多重度制御部１４５は、多重度の最小値と最大値の間を、一定数（例えば１００）もしくは一定間隔ごと（例えば多重度０．１ごと）に分割する。図３０の場合だと、例えば０と５０の間を０．５刻みで１００分割している。以下の説明では、５０を超えている多重度は無視するものとする。そして、多重度制御部１４５は、飽和多重度より大きな複数の多重度区間の間でｔ検定を行い、多重度制限値の上限値を求める。
【０２５９】
図３２は、多重度制限値の上限値の算出時にｔ検定が行われる多重度区間の一例を示す図である。多重度制御部１４５は、多重度制限値の下限値より大きな多重度区間の中で最初の多重度区間を選択する。ここで、多重度区間を、多重度が小さい方から順に数えたときの最初の多重度区間の順番をｎ1（ｎ1は１以上の整数）とする（図３２の例ではｎ1＝１０）。多重度制御部１４５は、ｎ1番目の多重度区間に属する多重度を持つすべての集計区間（多重度とＳＬＡ充足スループットとの組）から、ＳＬＡ充足スループットの平均値と不偏分散（unbiased sample variance）Ｕｔｐ1を求める。また多重度制御部１４５は、ｎ1に属する多重度を持つすべての集計区間の個数をｍ1（ｍ1は、１以上の整数）とする。
【０２６０】
多重度制御部１４５は、ｎ1の多重度区間より大きな番号ｎ（ｎは、ｎ1より大きな整数、）の多重度区間について、その範囲に属する多重度を持つすべての集計区間から、ＳＬＡ充足スループットの平均値と不偏分散Ｕｔｐnを求める。なお、図３２の例では、１０＜ｎ≦１００となる。また多重度制御部１４５は、ｎ番の多重度区間に属する多重度を持つすべての集計区間の個数をｍn（ｍnは、１以上の整数）とする。
【０２６１】
多重度制御部１４５は、ｎ1番目の多重度区間とｎ番目の多重度区間について、ＳＬＡ充足スループットの集合間の検定統計量ｔnを以下の式（４）によって計算する。
【０２６２】
【数４】
2014038578.tif 000006
【０２６３】
次に、多重度制御部１４５は、計算した検定統計量ｔnを、自由度（degrees of freedom）を「ｍ1＋ｍn−２」としたときのｔ値と比較し、ｎ番目の多重度区間のＳＬＡ充足スループットの集合と最初の多重度区間（ｎ1番目）ＳＬＡ充足スループットの集合が有意に異なる（significantly different）かどうかのｔ検定（Student's t-test）を行う。例えば自由度が６０の場合、ｔ分布表（Student's t-distribution table）から求められるｔ値は、５％有意水準（statistical significanceまたはsignificance level）の片側検定で１．６７１である。上記の式で計算したｔnがこの１．６７１以下の場合は、帰無仮説（null hypothesis）である「ＳＬＡ充足スループットの集合が、最初の多重度区間（ｎ1番目）とｎ番目の多重度区間との間で差がない」を棄却できず、両者は異ならないと判定される。逆に、ｔnが１．６７１より大きい場合は、帰無仮説が棄却され、両者は異なると判定される。なお、片側検定を用いる理由は、ここではＳＬＡ充足スループットが下がり始める地点を調べており、飽和したスループットが上がることは考えられないからである。
【０２６４】
検定統計量ｔnが有意に異なるようになった最初の多重度区間をｎ2とすると、その多重度区間の多重度の開始値を、第２の実施の形態における多重度制限値の上限値とする。例えば、ｎ2＝４７の多重度区間で初めて検定統計量ｔnがｔ値を超えた場合、求める多重度制限値の上限値は２３（＝０．５×４６）となる。
【０２６５】
なお、第２の実施の形態では、図３２に示すように、多重度制限値の下限値を含む多重度区間を基準とし、その多重度区間と他の多重度区間との間でｔ検定を行っている。しかし、基準とする多重度区間は、他の多重度区間であってもよい。例えば多重度制限値の下限値以降も、ステップＳ２５５と同様に傾きを計算し、傾きがほぼ０になったときの多重度を含む多重度区間を、基準の多重度区間とすることもできる。
【０２６６】
図３３は、多重度制限値の上限値算出処理の手順の一例を示す図である。以下、図３３に示す処理をステップ番号に沿って説明する。
［ステップＳ２４１］多重度制御部１４５は、多重度の最小値と最大値とを求める。
【０２６７】
［ステップＳ２４２］多重度制御部１４５は、多重度の最小値と最大値との間を、等間隔に細分化する。細分化して得られた多重度の細分化区間を、多重度区間とする。
なお、ステップＳ２４１，Ｓ２４２の処理は、図３１のステップＳ２２１，Ｓ２２２と同様の処理である。従って、多重度下限値算出処理で実行したステップＳ２２１，Ｓ２２２の処理結果を保持しておき、多重度上限値算出処理においては、ステップＳ２４１，Ｓ２４２の処理を省略することもできる。
【０２６８】
［ステップＳ２４３］多重度制御部１４５は、多重度制限値の下限値を多重度の開始値とする多重度区間を、最初の多重度区間とする。そして多重度制御部１４５は、基準多重度区間に属する集計区間について、ＳＬＡ充足スループットに関する平均値と不偏分散を計算する。
【０２６９】
［ステップＳ２４４］多重度制御部１４５は、最初の多重度区間より後（多重度が大きい方を後方とする）の多重度区間のうち、未選択の多重度区間を１つ選択する。例えば、多重度制御部１４５は、基準多重度区間の次の多重度区間から順に、多重度区間を選択する。
【０２７０】
［ステップＳ２４５］多重度制御部１４５は、選択した多重度区間に属する集計区間のＳＬＡ充足スループットの平均値と不偏分散とを計算する。
［ステップＳ２４６］多重度制御部１４５は、基準多重度区間と、選択した多重度区間との間のｔ検定を行う。
【０２７１】
［ステップＳ２４７］多重度制御部１４５は、ステップＳ２４６におけるｔ値検定の結果として有意な差があるか否かを判断する。多重度制御部１４５は、有意な差がある場合、処理をステップＳ２５０に進める。また多重度制御部１４５は、有意な差がなければ、処理をステップＳ２４８に進める。
【０２７２】
［ステップＳ２４８］多重度制御部１４５は、最初の多重度区間より後の多重度区間のうち、未処理の多重度区間があるか否かを判断する。多重度制御部１４５は、未処理の多重度区間があれば処理をステップＳ２４４に進める。また多重度制御部１４５は、未処理の多重度区間がなければ、処理をステップＳ２４９に進める。
【０２７３】
［ステップＳ２４９］多重度制御部１４５は、すべての多重度区間において、有意な差が検出されたかった場合、多重度制限値の上限値は、現在のサーバにおける許容多重度の設定値より大きいと判断し、多重度制限値の上限値算出処理を終了する。
【０２７４】
［ステップＳ２５０］多重度制御部１４５は、有意な差が検出された場合、現在選択している多重度区間の区間開始値を、適切な多重度制限値の上限値とする。その後、多重度制限値の上限値算出処理が終了する。
【０２７５】
以上のようにして、適切な多重度制限値の上限値が求められる。
上記の多重度制限値の下限値と上限値との算出処理には、多重度制御処理の例外処理が含まれている。
【０２７６】
例外処理の１つ目は、飽和多重度（多重度制限値の下限値）が検出されなかった場合の処理である。この場合は、多重度制御部１４５は、ボトルネック層のサーバにおける現在の許容可能な多重度の設定値が小さすぎると判定する。適切な多重度制限値の下限値または上限値を求めるには、ボトルネック層のサーバにおける許容可能な多重度の設定値を大きな値に変更し、多重度制御処理を最初から再度やり直すこととなる。
【０２７７】
例外処理の２つ目は、多重度制限値の上限値が検出されなかった場合の処理である。多重度制限値の上限値が検出されなかった場合、多重度制御部１４５は、適切な多重度制限値の範囲の上限値は、ボトルネック層のサーバにおける現在の許容可能な多重度の設定値よりも大きいと判定する。この場合の選択肢は下記の２通りが考えられる。
１．許容可能な多重度の設定を大きな値に設定し直し、多重度制御処理を最初から再度やり直す。
２．得られた下限値と現在の設定値の間の範囲から、新しい多重度制限値を選択する。
【０２７８】
＜＜多重度設定＞＞
次に、サーバに対する許容可能な多重度の設定処理について説明する。サーバに対する許容可能な多重度の設定処理は、ボトルネック層のサーバにおける許容可能な多重度を、多重度制限値の下限値から上限値の間の値に設定する処理である。例えば多重度制御部１４５は、多重度制限値の下限値から上限値との中間値を、ボトルネック層のサーバにおける許容可能な多重度とする。
【０２７９】
例えば、多重度制御部１４５は、ボトルネック層のサーバに並列に送信するリクエストの総数を制限することで、ボトルネック層のサーバにおける許容可能な多重度を設定する。この場合、多重度制御部１４５は、ボトルネック層の１段上位の階層のサーバに対して、ボトルネック層のサーバに並列に送信するリクエストの総数が、ボトルネック層のサーバの許容可能な多重度となるように設定を行う。
【０２８０】
多重度制御部１４５は、ボトルネック層のサーバに対して、並列に実行するジョブの総数の上限が、許容可能な多重度となるように設定することもできる。
ボトルネック層が検出されて、ボトルネック層のサーバの許容可能な多重度の設定値を変更した後での、他の階層のサーバの許容可能な多重度の設定に関しては、既に適切な許容可能な多重度に設定されている場合は、その設定値を維持することができる。ただし、複数階層システムの構成がスケールアウトなどで変わった場合には、それ以前に求めた許容可能な多重度の設定値は、適切である保証はない。ボトルネック層以外の階層のサーバにおいて、適切な許容可能な多重度に設定されている保証がない場合は、多重度制御部１４５は、例えば下記の通りに設定する。
・ボトルネック層よりも上の階層のサーバについては、許容可能な多重度の総数が、ボトルネック層で許容可能な多重度の総数よりも、一定の割合で大きくなるように設定する（例えば２倍）。
・ボトルネック層よりも下の階層のサーバについては、許容可能な多重度の総数がボトルネック層の多重度の総数と同じになるように設定する。
【０２８１】
図３４は、多重度設定処理の手順の一例を示すフローチャートである。以下、図３４に示す処理をステップ番号に沿って説明する。
［ステップＳ２６１］多重度制御部１４５は、適切な多重度の下限値が検出されたか否かを判断する。多重度制御部１４５は、適切な多重度の下限値が検出された場合、処理をステップＳ２６３に進める。また多重度制御部１４５は、適切な多重度の下限値が検出されていなければ、処理をステップＳ２６２に進める。
【０２８２】
［ステップＳ２６２］多重度制御部１４５は、ボトルネック層の許容可能な多重度を、現在より大きな値に変更する必要があることを示すメッセージを出力する。例えば多重度制御部１４５は、当該メッセージをモニタ１１に表示する。その後、多重度設定処理を終了する。
【０２８３】
［ステップＳ２６３］多重度制御部１４５は、適切な多重度の上限値が検出されたか否かを判断する。多重度制御部１４５は、適切な多重度の上限値が検出された場合、処理をステップＳ２６５に進める。また多重度制御部１４５は、適切な多重度の上限値が検出されていなければ、処理をステップＳ２６４に進める。その後、多重度設定処理を終了する。
【０２８４】
［ステップＳ２６４］多重度制御部１４５は、ボトルネック層の多重度制限値の上限値は、現在の許容可能な多重度の設定値よりも大きな値であることを示すメッセージを出力する。例えば多重度制御部１４５は、当該メッセージをモニタ１１に表示する。その後、多重度設定処理を終了する。
【０２８５】
［ステップＳ２６５］多重度制御部１４５は、適切な多重度制限値の上限値と下限値とに基づいて、ボトルネック層のサーバにおける許容可能な多重度を修正する。例えば多重度制御部１４５は、適切な多重度制限値の上限値と下限値との中間値が、許容可能な多重度となるように、ボトルネック層のサーバに対して設定を行う。
【０２８６】
［ステップＳ２６６］多重度制御部１４５は、ボトルネック層以外の階層を１つ選択する。
［ステップＳ２６７］多重度制御部１４５は、選択した階層のサーバに対して、ボトルネック層の許容可能な多重度に合わせて、設定変更を行う。例えば多重度制御部１４５は、ボトルネック層の上位の階層のサーバに対しては、ボトルネック層の許容可能な多重度よりも大きな値を、そのサーバの許容可能な多重度として設定する。また多重度制御部１４５は、ボトルネック層の上位の階層のサーバに対して、ボトルネック層に対して並列に出力するリクエストの総数の上限が、ボトルネック層の許容可能な多重度と同数となるように設定する。また多重度制御部１４５は、ボトルネック層よりも下の階層のサーバについては、許容可能な多重度の総数がボトルネック層の多重度の総数と同じになるように設定する。
【０２８７】
［ステップＳ２６８］多重度制御部１４５は、選択していない階層があるか否かを判断する。多重度制御部１４５は、選択していない階層があれば、処理をステップＳ２６６に進める。また多重度制御部１４５は、すべての階層の設定が完了したら、多重度設定処理を終了する。
【０２８８】
以上のようにして、複数階層システムにおいて、ボトルネックとなっている階層に関して、多重度制限値の最小値と最大値を求めることができる。その結果、多重度制限値を適切に設定して、最大スループットの安定した生成と、ＳＬＡで規定された時間内の応答時間を確保することが可能となる。すなわち、多重度が過大とならない範囲で、余裕をもった多重度を設定することが可能となる。
【０２８９】
また、その適切な多重度制限値を得るのに、各階層の多重度制限値の組み合わせ（一般的に膨大な数になる）を１つ１つ試すことを必要とせず、効率的な処理が可能である。
さらに、許容可能な多重度制限値の範囲に基づいて、複数階層システムのサーバに対して、ボトルネック層のサーバの多重度が適切な数となるように、多重度制限値を設定することができる。
【０２９０】
〔その他の実施の形態〕
第２の形態では、飽和多重度以下の多重度を有する集計区間の割合に応じてボトルネック層を判断しているが、他の方法でボトルネック層を判断してもよい。
【０２９１】
また、上記の処理機能の少なくとも一部を、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）などの電子回路で実現することもできる。
【０２９２】
以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。
【符号の説明】
【０２９３】
１  記憶手段
２  判断手段
３  第１の計算手段
４  第２の計算手段
５  決定手段
６，６ａ，６ｂ  トランザクション情報
７  管理テーブル
【図１】
2014038578.tif 000007
【図２】
2014038578.tif 000008
【図３】
2014038578.tif 000009
【図４】
2014038578.tif 000010
【図５】
2014038578.tif 000011
【図６】
2014038578.tif 000012
【図７】
2014038578.tif 000013
【図８】
2014038578.tif 000014
【図９】
2014038578.tif 000015
【図１０】
2014038578.tif 000016
【図１１】
2014038578.tif 000017
【図１２】
2014038578.tif 000018
【図１３】
2014038578.tif 000019
【図１４】
2014038578.tif 000020
【図１５】
2014038578.tif 000021
【図１６】
2014038578.tif 000022
【図１７】
2014038578.tif 000023
【図１８】
2014038578.tif 000024
【図１９】
2014038578.tif 000025
【図２０】
2014038578.tif 000026
【図２１】
2014038578.tif 000027
【図２２】
2014038578.tif 000028
【図２３】
2014038578.tif 000029
【図２４】
2014038578.tif 000030
【図２５】
2014038578.tif 000031
【図２６】
2014038578.tif 000032
【図２７】
2014038578.tif 000033
【図２８】
2014038578.tif 000034
【図２９】
2014038578.tif 000035
【図３０】
2014038578.tif 000036
【図３１】
2014038578.tif 000037
【図３２】
2014038578.tif 000038
【図３３】
2014038578.tif 000039
【図３４】
2014038578.tif 000040