プログラム、分析方法、および情報処理装置
【課題】分析対象装置の処理能力の余力の有無を判断することができるようにする。
【解決手段】計算手段１ｃは、分析対象装置で分析対象期間内に実行された処理の実行期間を示す情報を記憶手段１ｂから取得する。次に計算手段１ｃは、取得した情報に基づいて、分析対象期間を細分化して得られる集計区間ごとに、集計区間内で実行された処理それぞれの実行に費やされた時間を合計した合計処理時間を計算する。また計算手段１ｃは、集計区間ごとに、集計区間内で実行された処理それぞれの進行量を合計した合計進行量を計算する。決定手段１ｄは、集計区間ごとの合計処理時間と合計進行量とに基づいて、合計処理時間の増加量に対する合計進行量の増加量が所定値以下となる合計処理時間の閾値を決定する。そして検出手段１ｅは、合計処理時間が前記閾値以上の集計区間を検出する。
【解決手段】計算手段１ｃは、分析対象装置で分析対象期間内に実行された処理の実行期間を示す情報を記憶手段１ｂから取得する。次に計算手段１ｃは、取得した情報に基づいて、分析対象期間を細分化して得られる集計区間ごとに、集計区間内で実行された処理それぞれの実行に費やされた時間を合計した合計処理時間を計算する。また計算手段１ｃは、集計区間ごとに、集計区間内で実行された処理それぞれの進行量を合計した合計進行量を計算する。決定手段１ｄは、集計区間ごとの合計処理時間と合計進行量とに基づいて、合計処理時間の増加量に対する合計進行量の増加量が所定値以下となる合計処理時間の閾値を決定する。そして検出手段１ｅは、合計処理時間が前記閾値以上の集計区間を検出する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータシステムの性能を分析するプログラム、分析方法、および情報処理装置に関する。
【背景技術】
【０００２】
従来、複数のコンピュータが階層的に処理を分担するコンピュータシステム（多階層システムという）が利用されている。以下、多階層システムを構成するコンピュータを「サーバ」と呼ぶ。多階層システムとして、例えばシステム利用のためのインタフェースを提供するＷｅｂサーバ、システム上の業務処理を実行するＡｐｐ（Application）サーバおよびデータを管理するＤＢ（Database）サーバを有する三階層システムが知られている。各サーバは、ユーザからの処理要求に対して連携して処理を実行し、その処理要求に応答する。このように、各サーバに処理を分担させることで、システムの負担を分散させると共に、各階層のコンピュータの量を適切に調整することによって、信頼性や応答性を向上できる。
【０００３】
このようなＷｅｂ三階層システムに代表される多階層システムにおいて、エンドユーザにおける応答時間の増大が発生した際には、問題が発生しているサーバが属する階層を特定することが、障害対応の第一歩として非常に重要である。そのために、各階層のサーバにおける処理時間を測定し、その推移を監視することによって問題の有無を判定する手法が広く一般に採用されている。
【０００４】
例えば、トランザクションモデルを生成し、スイッチを介して送受信されたメッセージからトランザクションモデルに沿って進行するメッセージの受け渡しを検出する技術が考えられている。この技術により、任意のトランザクションを構成するメッセージの集合を特定し、そのトランザクションの解析が可能となる。例えば、ユーザのリクエストからレスポンスまでの各アプリケーションの処理を追跡することができる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００６−１１６８３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかし、従来の方法では、分析対象であるサーバが処理に要した時間を把握することはできるものの、サーバの処理能力に余力があるかどうかについてはわからなかった。
１つの側面では、本発明は、分析対象装置の処理能力の余力の有無を判断することができるプログラム、分析方法、および情報処理装置を提供することを目的とする。
【課題を解決するための手段】
【０００７】
１つの案では、コンピュータに、分析対象装置で分析対象期間内に実行された処理の実行期間を示す情報を記憶手段から取得し、該取得した情報に基づいて、前記分析対象期間を細分化して得られる集計区間ごとに、集計区間内で実行された処理それぞれの実行に費やされた時間を合計した合計処理時間と、集計区間内で実行された処理それぞれの進行量を合計した合計進行量とを計算し、集計区間ごとの合計処理時間と合計進行量とに基づいて、合計処理時間の増加量に対する合計進行量の増加量が所定値以下となる合計処理時間の閾値を決定し、合計処理時間が前記閾値以上の集計区間を検出する、処理を実行させるプログラムが提供される。
【発明の効果】
【０００８】
分析対象装置の処理能力の余力の有無を判断することができるようになる。
【図面の簡単な説明】
【０００９】
【図１】第１の実施の形態に係るシステムの構成の一例を示す図である。
【図２】第１の実施の形態の分析処理の手順の一例を示すフローチャートである。
【図３】第１の実施の形態による余力判定例を示す図である。
【図４】第２の実施の形態の業務システムの全体構成を示す図である。
【図５】第２の実施の形態に用いるコンピュータのハードウェアの一構成例を示す図である。
【図６】第２の実施の形態に係る分析サーバの機能の一例を示すブロック図である。
【図７】キャプチャ処理の手順の一例を示すフローチャートである。
【図８】キャプチャデータ記憶部のデータ構造の一例を示す図である。
【図９】性能分析処理の手順の一例を示すフローチャートである。
【図１０】メッセージデータ記憶部のデータ構造の一例を示す図である。
【図１１】抽象化ルール記憶部のデータ構造の一例を示す図である。
【図１２】ＨＴＴＰのプロトコルのジョブ種の例を示す図である。
【図１３】ＤＢのプロトコルのジョブ種の例を示す図である。
【図１４】ジョブ種が識別されたメッセージフローの一例を示す図である。
【図１５】メッセージフロー情報記憶部のデータ構造の一例を示す図である。
【図１６】階層別性能分析処理の手順の一例を示すフローチャートである。
【図１７】多重度とスループットとの関係を示す図である。
【図１８】集計区間への分割例を示す図である。
【図１９】実行期間の集計区間への振り分け例を示す図である。
【図２０】並列で処理が実行される状況を示す図である。
【図２１】スループット・多重度算出処理の手順の一例を示すフローチャートである。
【図２２】集計区間情報記憶部のデータ構造の一例を示す図である。
【図２３】正規化スループット値記憶部のデータ構造の一例を示す図である。
【図２４】スループットの時系列推移の一例を示す図である。
【図２５】多重度の時系列推移の一例を示す図である。
【図２６】多重度とスループットとの関係の一例を示す散布図である。
【図２７】飽和多重度算出処理の一例を示すフローチャートである。
【図２８】ボトルネック判定処理の手順の一例を示すフローチャートである。
【図２９】階層が完全未飽和状態の一例を示す散布図である。
【図３０】階層が未飽和状態の一例を示す散布図である。
【図３１】階層が半飽和状態の一例を示す散布図である。
【図３２】階層が飽和状態の一例を示す散布図である。
【図３３】多重度とスループットの関連性を壊す要因の一例を示す図である。
【図３４】間接的な外部資源待ち時間を除外しない場合の各集計区間のスループットと多重度との一例を示す散布図である。
【図３５】間接的な外部資源待ち時間を除外した場合の各集計区間のスループットと多重度との一例を示す散布図である。
【図３６】Ｆｕｌｌ−ＧＣによる停止期間が発生した場合の一連の業務処理を示す図である。
【図３７】第４の実施の形態における正規化スループット値記憶部のデータ構造の一例を示す図である。
【図３８】１ジョブ当たりの正規化スループット値に基づいてスループットを計算した場合の散布図である。
【図３９】１メッセージ当たりの正規化スループット値に基づいてスループットを計算した場合の散布図である。
【図４０】第５の実施の形態における飽和多重度算出処理の一例を示すフローチャートである。
【図４１】第６の実施の形態の集計区間情報記憶部のデータ構造の一例を示す図である。
【図４２】余力計算処理の手順の一例を示すフローチャートである。
【図４３】余力計算処理を説明する図である。
【図４４】集計区間長決定処理の手順の一例を示すフローチャートである。
【図４５】低負荷時の平均処理時間算出処理の一例を示すフローチャートである。
【図４６】多重度が閾値以下の集計区間の抽出例を示す図である。
【図４７】瞬間スループット低下検出処理の手順の一例を示すフローチャートである。
【図４８】第９の実施の形態により異常な瞬間スループット低下が検出される散布図の一例である。
【発明を実施するための形態】
【００１０】
以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第１の実施の形態〕
第１の実施の形態は、単位期間における処理の合計処理時間の平均と、その単位期間における処理の合計進行量との関連を求め、合計処理時間が上昇しても合計進行量が上昇しなくなっている場合に、処理性能が限界に達していると判定するものである。
【００１１】
図１は、第１の実施の形態に係るシステムの構成の一例を示す図である。第１の実施の形態では、情報処理装置１が、例えばＷｅｂ三階層システム中の各サーバを分析対象装置とし、ネットワーク２を介してサーバの性能分析を行う。Ｗｅｂ三階層システムは、端末装置３からの要求に応じて、複数のサーバが連携して処理を実行するコンピュータシステムである。Ｗｅｂ三階層システムは、例えばＷｅｂサーバ４、Ａｐｐサーバ５、ＤＢサーバ６で構成される。
【００１２】
情報処理装置１は、例えば監視手段１ａ、記憶手段１ｂ、計算手段１ｃ、決定手段１ｄ、および検出手段１ｅを有する。
監視手段１ａは、分析対象期間内のＷｅｂサーバ４、Ａｐｐサーバ５、ＤＢサーバ６の動作を監視し、各サーバの処理の実行期間を示す情報を取得する。そして監視手段１ａは、取得した情報を記憶手段１ｂに格納する。
【００１３】
記憶手段１ｂは、分析対象装置で分析対象期間内に実行された処理の実行期間を示す情報を記憶する。
計算手段１ｃは、分析対象装置で分析対象期間内に実行された処理の実行期間を示す情報を記憶手段１ｂから取得する。次に計算手段１ｃは、取得した情報に基づいて、分析対象期間を細分化して得られる集計区間ごとに、集計区間内で実行された処理それぞれの進行量を合計した合計進行量を計算する。さらに計算手段１ｃは、取得した情報に基づいて、分析対象期間を細分化して得られる集計区間ごとに、集計区間内で実行された処理それぞれの実行に費やされた時間を合計した合計処理時間を計算する。
【００１４】
決定手段１ｄは、集計区間ごとの合計処理時間と合計進行量とに基づいて、合計処理時間の増加量に対する合計進行量の増加量が所定値以下となる合計処理時間の閾値を決定する。
【００１５】
検出手段１ｅは、合計処理時間が閾値以上の集計区間を検出する。
このような構成のシステムにおいて、以下のような処理が行われる。
図２は、第１の実施の形態の分析処理の手順の一例を示すフローチャートである。以下、図２に示す処理をステップ番号に沿って説明する。
【００１６】
［ステップＳ１］監視手段１ａは、分析対象期間内のＷｅｂサーバ４、Ａｐｐサーバ５、ＤＢサーバ６の動作を監視する。例えば監視手段１ａは、Ｗｅｂサーバ４、Ａｐｐサーバ５、ＤＢサーバ６に入出力されるメッセージをネットワーク２からキャプチャする。監視手段１ａは、監視内容に基づいて、Ｗｅｂサーバ４、Ａｐｐサーバ５、ＤＢサーバ６から、処理の実行状況に関する情報を、監視結果として取得する。そして監視手段１ａは、監視結果を記憶手段１ｂに格納する。
【００１７】
［ステップＳ２］計算手段１ｃは、記憶手段１ｂに格納されている情報に基づいて、分析対象装置であるサーバごとに、合計進行量を計算する。例えば計算手段１ｃは、分析対象期間を細分化して、集計区間を生成する。次に計算手段１ｃは、生成した集計区間ごとに、各サーバにおいて集計区間内で実行された処理それぞれの進行量を計算する。そして計算手段１ｃは、サーバごとに、各集計区間の進行量を合計し、合計進行量とする。
【００１８】
［ステップＳ３］計算手段１ｃは、記憶手段１ｂに格納されている情報に基づいて、分析対象装置であるサーバごとに、合計処理時間を計算する。例えば計算手段１ｃは、分析対象期間を細分化して、集計区間を生成する。次に計算手段１ｃは、生成した集計区間ごとに、各サーバにおいて集計区間内で実行された処理それぞれの実行に費やされた時間を計算する。そして計算手段１ｃは、サーバごとに、各集計区間の実行に費やされた時間を合計し、合計処理時間とする。なお各サーバでは、複数の処理を並列実行する場合がある。そのため、合計処理時間は、集計区間の長さ（時間幅）より大きくなる場合もある。
【００１９】
［ステップＳ４］決定手段１ｄは、集計区間ごとの合計処理時間と合計進行量とに基づいて、合計処理時間の増加量に対する合計進行量の増加量が所定値以下となる合計処理時間の閾値を決定する。
【００２０】
［ステップＳ５］検出手段１ｅは、合計処理時間が閾値以上の集計区間を検出する。
このようにして検出された集計区間は、合計処理時間が増加しても、処理の進行が増加しなくなっている時間帯である。すなわち、性能の余力がなくなっている時間帯である。合計処理時間が閾値以上の集計区間が多数検出されたサーバは、余力がなくなりつつあることが分かる。また合計処理時間が閾値以上の集計区間がほとんど検出されていないサーバは、性能の余力が十分にあることが分かる。
【００２１】
図３は、第１の実施の形態による余力判定例を示す図である。図３の例では、各サーバにおいて、処理要求が入力されてから応答を返すまでに、処理要求に応じて実行された処理全体で、処理の進行を示す単位量を「１」としている。複数の集計区間を跨って実行された処理は、処理の単位量を処理時間に応じて、各集計区間に比例配分される。
【００２２】
Ｗｅｂサーバ４では、１つの処理要求に応じて、「集計区間１」と「集計区間２」とで２回に分けて処理７が行われている。「集計区間１」における処理時間は「１４ｍｓ」であり、「集計区間２」における処理時間は「１１ｍｓ」である。そこで進行の単位量「１」を２つの集計区間に比例配分すると、「集計区間１」の進行量が「０．５６」、「集計区間２」の進行量が「０．４４」となる。図３の例では、「集計区間１」と「集計区間２」との間に１つの処理要求に応じた処理７のみが実行されているため、合計進行量も、「集計区間１」が「０．５６」、「集計区間２」が「０．４４」となる。
【００２３】
Ａｐｐサーバ５では、１つの処理要求に応じて、「集計区間１」と「集計区間２」とで５回に分けて処理８が行われている。「集計区間１」における処理時間は、「１９ｍｓ」と「９ｍｓ」であり、合計「２８ｍｓ」である。「集計区間２」における処理時間は「１０ｍｓ」と「１２ｍｓ」と「２１ｍｓ」であり、合計「４３ｍｓ」である。そこで進行の単位量「１」を２つの集計区間に比例配分すると、「集計区間１」の進行量が「０．３９４」、「集計区間２」の進行量が「０．６０６」となる。図３の例では、「集計区間１」と「集計区間２」との間に１つの処理要求に応じた処理８のみが実行されているため、合計進行量も、「集計区間１」が「０．３９４」、「集計区間２」が「０．６０６」となる。
【００２４】
ＤＢサーバ６では、４つの処理要求に応じて、「集計区間１」と「集計区間２」とで、処理要求ごとに１回ずつ、計４回の処理９ａ，９ｂ，９ｃ，９ｄが行われている。２つめの処理要求に応じた処理９ｂは、「集計区間１」と「集計区間２」とに跨って実行されている。このように２つの集計区間に跨って実行された処理９ｂに関しては、処理進行の単位量「１」が、処理時間に応じて比例配分される。処理９ｂの「集計区間１」における処理時間は「１０ｍｓ」であり、「集計区間２」における処理時間は「２４ｍｓ」であり、合計「３４ｍｓ」である。そこで処理９ｂに関する進行の単位量「１」を２つの集計区間に比例配分すると、「集計区間１」の進行量が「０．２９」、「集計区間２」の進行量が「０．７１」となる。図３の例では、「集計区間１」において処理９ａが完結しており、その処理９ａの進行の単位量「１」と処理９ｂの進行量「０．２９」の合計値「１．２９」が、「集計区間１」の合計進行量となる。また「集計区間２」において処理９ｃ，９ｄが完結しており、その処理９ｃ，９ｄそれぞれの進行の単位量「１」と処理９ｂの進行量「０．７１」の合計値「２．７１」が、「集計区間２」の合計進行量となる。
【００２５】
サーバごとの各集計区間の合計処理時間は、集計区間内で処理の実行に要した時間の合計である。Ｗｅｂサーバ４では、「集計区間１」の合計処理時間は「１４ｍｓ」、「集計区間２」の合計処理時間は「１１ｍｓ」である。Ａｐｐサーバ５では、「集計区間１」の合計処理時間は「２８ｍｓ」、「集計区間２」の合計処理時間は「４３ｍｓ」である。ＤＢサーバ６では、「集計区間１」の合計処理時間は「１９ｍｓ」、「集計区間２」の合計処理時間は「３９ｍｓ」である。
【００２６】
このようにして集計された情報に基づいて、サーバごとに、合計処理時間の増加量に対する合計進行量の増加量が所定値以下となる閾値が計算される。なお、所定値としては、例えば、合計処理時間が少ない時間帯の合計処理時間の増加量に対する合計進行量の増加量の割合に、所定の係数（１より小さい値）を掛けた値とする。
【００２７】
このようにして求められた閾値よりも合計処理時間が長い集計区間が、複数のサーバそれぞれに関して検出される。例えば図３の例では、Ｗｅｂサーバ４とＤＢサーバ６とについては、合計処理時間が閾値以上となっている集計区間の、全体の集計区間に対する割合は半分以下であり、少ない。他方、Ａｐｐサーバ５については、ほとんどの集計区間において、合計処理時間が閾値以上となっている。そうすると、Ａｐｐサーバ５において処理能力の余力がなくなっており、Ｗｅｂ三階層システムにおけるボトルネックとなっていることが分かる。
【００２８】
ここで言うボトルネックとは、システム全体としての処理性能の上昇を阻害している要因のことである。またボトルネックの検出とは、複数のコンピュータが階層的に処理を分担するシステム（多階層システム）の内のどの階層に問題があって、システム全体としての性能が頭打ちになっているのかを求めることである。
【００２９】
このように、第１の実施の形態によれば、各サーバの処理能力の余力の有無を検出することができる。これにより、多階層システムにおいて、ボトルネックとなっているサーバを容易に特定できる。
【００３０】
ところで、従来は、多階層システムにおけるボトルネックとなっているサーバの検出は、難しかった。以下、多階層システムにおいて、システム全体の処理性能が限界を迎えた場合の、ボトルネックとなっているコンピュータの検出の困難性について説明する。
【００３１】
多階層システムの運用中に発生したボトルネックの検出に利用可能と考えられる技術を大別すると、下記の５通りに分類される。
・第１の手法：システムリソースの利用状況を監視する。
・第２の手法：アプリケーション内部の詳細な動作状況を監視する。
・第３の手法：コンピュータ上でアプリケーションの外部挙動（応答時間や各階層での滞在時間）を監視する。
・第４の手法：ネットワーク上でアプリケーションの外部挙動（応答時間や各階層での滞在時間）を監視する。
・第５の手法：システム運用前に予め負荷テストを行い、負荷量とスループットの関係を学習し、その知識を利用して運用中のボトルネックを特定する。
【００３２】
次に、各手法について詳細に説明する。
＜第１の手法＞
第１の手法に該当する技術は、例えば多階層システムに含まれるコンピュータ上に特定のプロセス（エージェントと呼ばれることが多い）を用意しておき、そのプロセスが様々な測定値を収集する手法である。取得する測定値の例としては、マシン全体でのＣＰＵ利用率やメモリ使用量などの、マシン単位でのシステムリソース利用状況がある。また取得する測定値の別の例としては、プロセスごとのＣＰＵ利用率やファイルオープン数などの、プロセス単位の情報がある。
【００３３】
第１の手法では、分析対象の各コンピュータ上で収集されたデータは、一旦そのコンピュータ上の記録装置へ書き出しておいて、後で分析を行うコンピュータで回収される。または分析対象のコンピュータがネットワーク経由で直接、分析を行うコンピュータに送信する。これによって、多階層システムに含まれるコンピュータ以外の特定のコンピュータに集められる。そしてデータが集められたコンピュータにおいて、多階層システム内の全コンピュータのデータを突き合わせて分析することによって、ボトルネックを検出することになる。
【００３４】
＜第２の手法＞
第２の手法に該当する技術としては、例えばアプリケーションソフトウェアの機能を利用したり、アプリケーションソフトウェアに改造を加えたりして、アプリケーションソフトウェア内部の情報を取得する手法である。取得する情報は、例えばデータベース（ＤＢ）ソフトウェアにおけるＤＢ問い合わせ処理時間、同時接続ユーザ数、各内部メソッドの開始・終了時刻などである。これらの情報は、エージェントのような別プロセスから当該ソフトウェアに問い合わせて得られる場合もあるし、当該アプリケーションソフトウェア自身がログなどの形式で出力する場合もある。
【００３５】
第２の手法においても、第１の手法と同様に、各コンピュータ上で収集されたデータは、一旦そのコンピュータ上の記録装置へ書き出しておいて、後でそのコンピュータとは別の特定のコンピュータに集められる。そしてデータが集められたコンピュータにおいて、データが分析され、ボトルネックが検出される。
【００３６】
＜第３の手法＞
第３の手法における外部挙動を監視する技術としては、応答時間を測定する手法が一般的である。応答時間は、多階層システムのあらゆる階層において測ることが考えられる。
【００３７】
第３の手法では、例えば各コンピュータ上のアプリケーションソフトウェアの機能を利用したり、アプリケーションソフトウェアに改造を加えたりすることによって、アプリケーションソフトウェアが他コンピュータとメッセージ送受を行ったことを記録する。そしてアプリケーションソフトウェアは、その中から各処理要求の受信時刻と処理結果の返信時刻を抜き出して応答時間を求める手法である。
【００３８】
第３の手法においても、第１の手法と同様に、各コンピュータ上で収集されたデータは、一旦そのコンピュータ上の記録装置へ書き出しておいて、後でそのコンピュータとは別の特定のコンピュータに集められる。そしてデータが集められたコンピュータにおいて、データが分析され、ボトルネックが検出される。
【００３９】
＜第４の手法＞
第４の手法における外部挙動を監視する技術も、第３の手法と同様、応答時間を、多階層システムの各階層において測定する手法が一般的である。第３の手法と第４の手法との違いは、応答時間の測定方法にある。
【００４０】
第４の手法では、例えば多階層システムに含まれるコンピュータには手を加えず、ネットワーク上を流れる通信パケットを、多階層システムに含まれないコンピュータで取得する。そして、通信パケットを取得したコンピュータが、取得した通信パケットから、多階層システムに含まれるコンピュータ間のメッセージ送受を解析し、それらの送受時刻から応答時間を求める。
【００４１】
第４の手法には、他の全ての手法と違って、各コンピュータ内には一切手を加えないので各コンピュータ本来の挙動に一切影響を与えないという利点がある。以下に、第４の手法をさらに詳細に説明する。コンピュータネットワーク上から通信パケットを取得する方法として、ネットワークスイッチの持つポートミラーリング機能を利用する方法がある。ポートミラーリング機能は、ネットワークスイッチ上の特定のポートを流れるＩＰ（Internet Protocol）パケットをコピーし、そのコピーを指定したポートに転送する。そのポートの先に接続したコンピュータにおいて、転送されてきたＩＰパケットをキャプチャして記録することができる。
【００４２】
こうして取得したデータは、コンピュータ間でサーバプログラム同士がやり取りするメッセージの形式ではなく、細分化されたＩＰパケットという形式である。ここからメッセージ上の情報を取得するには、まず細分化されたＩＰパケット同士を組み立て、さらにはそのパケットをメッセージのプロトコル種別に従って解析することとなる。メッセージを解析することによって、各処理の要求と、その要求に対する返信のペア（メッセージペア）を見つけだすことができる。メッセージペアが検出できれば、メッセージペアの時刻情報の差分を取れば応答時間を求めることができる。
【００４３】
さらには、各メッセージの情報から、処理要求の内容に関する情報も取得することができる。例えば、ＨＴＴＰ（HyperText Transfer Protocol）要求の場合は、取得を要求しているＵＲＬ（Uniform Resource Locator）であるとか、ＤＢ要求の場合はＳＱＬ（Structured Query Language）文などの情報である。これらの内容と応答時間とから、どのような業務処理にどれくらいの応答時間を要しているか判断することができる。この応答時間の平均値の推移を監視することによって、特定の階層でだけ応答時間が増加すれば、それはその階層下の処理に何らかの問題が発生していると考え、ボトルネック検出の手掛かりとすることができる。また、業務処理内容ごとに集計すれば、特定の業務処理の応答時間だけが低下した場合に、その業務処理に関連している部分にボトルネックが存在すると考えることもできる。
【００４４】
＜第５の手法＞
第５の手法は、事前の負荷テストによってデータ収集を行うことを前提とする。事前の負荷テストでは、例えば多階層システムに含まれないコンピュータ（負荷生成器）から多階層システムに対して運用時を模した負荷を掛ける。例えば、負荷生成器から多階層システムに、同時アクセスユーザ数を変えながら、多数のパターンの要求を入力する。そして、処理結果を観測するコンピュータにおいて、同時アクセスユーザ数ごとの多階層システムのスループットを測定する。処理結果を観測するコンピュータでは、システムに掛かる同時アクセスユーザ数とスループットの関係から、スループットが上限に達する同時アクセスユーザ数を判定し、判定した同時アクセスユーザ数を限界同時アクセスユーザ数とする。このような事前処理を行った後、その監視対象の多階層システムの運用時に同時アクセスユーザ数を監視しておき、先に得た限界同時アクセスユーザ数に達すると、システムの性能が限界に達したと判定する。
【００４５】
以上のような第１から第５の手法のいずれかを用いて多階層システムのボトルネックを検出した場合、以下のような課題が残ってしまう。
＜第１の手法の課題＞
特定のシステムリソースを消費し尽くしていない状況で発生したボトルネックは検出できない。
【００４６】
システムリソースの利用状況の監視では、ボトルネックを検出できない場合がある。これは、以下のような理由により、特定のリソースが枯渇していなくても、そのコンピュータがボトルネックとなることがあるからである。
１．ソフトウェア設定やユーザアプリ内部において、並列度を制限している場合
２．複数リソースが複合してボトルネックとなっている場合
なお第２の手法を使用して、アプリケーション内部の詳細な動作状況を監視する場合、１．の問題は解決できる可能性があるが、それも適切なデータを取得できた場合に限られる。アプリケーション内部でボトルネック要因になると考えられる要素は、一般的に非常に多く存在する。そのため、それらの全てについて網羅的に詳細な記録を取り続けることは、データの記録装置への書き出しに要する時間とシステム負荷を考えると、現実的には困難である。
【００４７】
＜第１〜第３の手法に共通の課題＞
第１〜第３の手法には、極短時間で変化するボトルネックが検出できないという問題がある。
【００４８】
各コンピュータ上でデータを測定する手法には、以下の２つの要因があって、極短い時間間隔ごとの詳細な分析を行うことが難しいという問題がある。
極短い時間間隔ごとの詳細なデータはデータ量が大きくなり、コンピュータ上の記録装置に一旦格納して後から取り出す場合においても、直接ネットワーク経由で外部へ送り出す場合においても、そのコンピュータに掛かる負担が大きくなる。そのため、データの収集処理が、コンピュータ上で動作しているアプリケーションの挙動に大きく影響を及ぼしてしまう。その結果として、そのアプリケーションの本来の挙動とは大きく異なる挙動を観測してしまうことになる。
【００４９】
コンピュータ間で時計の誤差があり、これはＮＴＰ（Network Time Protocol）等の時計同期システムを使用したとしても、数ミリ秒単位の誤差は免れない。これでは、複数コンピュータから収集したデータを付き合わせて分析する際に、タイムスタンプ間に誤差が生じていて、正しく突き合わせを実行することができず、極短い時間間隔での精密な分析はできなくなる。
【００５０】
極短い時間間隔ごとの詳細な分析を行えない結果として、例えば、一つのコンピュータ上で、測定期間より短い一瞬一瞬だけの短時間に発生しているボトルネックは、測定期間内で平均化されてしまい、その後の分析で検出できないことになる。また、複数の階層間で測定期間より短い極短時間の内にボトルネック要因が推移している場合は、同様に検出できない。
【００５１】
＜第４の手法の課題＞
アプリケーションの外部挙動を監視する第４の手法には、以下の課題がある。
応答時間／処理時間などの外部観測ではボトルネックを見誤る場合がある。このようなことは、外部観測では外面の挙動しか観測しておらず、そのような挙動が発生する原因となる内部処理については何も情報を得ていないために発生する。
【００５２】
例えば、発生しがちなケースとして次のようなことがある。ある層がボトルネックになった際に、その層に送られてくる処理要求の数が処理可能な数を超えて際限なく増加していく場合は、その階層における応答時間が大きく悪化する。しかし、その階層へ送られてくる処理要求の数が適切にコントロールされている場合は、その階層へはそれ以上処理要求が送られて来なくなる。それによって、応答時間の低下は小さく留まる。その代わりに、その層へ処理要求を送る上位の階層では、下位の階層へ処理を送るまでの待ち時間が指数関数的に増加する。外部観測で処理時間の推移を監視していると、その待ち時間の増加と純粋な処理時間の増加の区別が付かないために、あたかもその待ち時間が増加した階層にボトルネックが存在するかのように誤認してしまう。
【００５３】
＜第５の手法の課題＞
システム運用前に予め負荷テストを行い、負荷量とスループットの関係を学習し、その知識を利用して運用中のボトルネックを特定する第５の手法には、以下の課題がある。
【００５４】
第５の手法を多階層システムに適用する場合、多階層システムの最上段に掛かる多重度（同時アクセスユーザ数）と、その時のスループットは測定できても、階層ごとの多重度・スループットの関係は測定できないという問題がある。また、このような手法では、システムに掛かる多重度を変化させるために負荷生成器の発生する負荷量を変化させながら、何回も測定し直す必要がある。さらには、多階層システムの場合は、各階層のコンピュータの台数を動的に変更すること（スケールアウト）があり、その考えられる全ての構成について、このような事前測定を行っておくのは困難である。さらに、多階層システムにおいて各階層に掛かる負荷は、そのシステム上で動く複数種類の処理の混合割合やその実行タイミングによっても変わってくる。その全ての組み合わせを事前にテストして完全なデータを揃えておくことは、非常に困難で現実的ではない。
【００５５】
また、同様の手法を最上段以外の階層に直接適用して、負荷生成器から中間階層へ直接負荷を掛けて、多重度とスループットの関係を測定しようとすると、実環境に即した負荷をどのようにして生成するかという非常に困難な問題が発生する。現在の多階層システムは挙動が非常に複雑で、各階層が上位層からある処理を受けた際に下位層へどのようなタイミングでどのような負荷を発行するかは、アプリケーションのプログラム内容だけでなく、ハードウェア構成やＯＳ実装を含む種々の要因が複雑に絡んで決まる。そのため、負荷の生成要因を正確に理解して再現することは非常に困難であり、現実的ではない。
【００５６】
よって、第５の手法は、システム運用前のテスト手法としては利用できるが、実運用中に発生した性能問題の原因分析（ボトルネック特定）には利用できない。
以上のように、第１〜第５の手法では、いずれも課題があり、多階層システムのボトルネックを適切に検出するのが難しかった。
【００５７】
第１の実施の形態に示した手法では、精密なメッセージ送受時刻の記録などの情報から、各階層における処理の合計進行量と合計処理時間を算出し、その関係を動的に求め、そこからボトルネック判定を行うことを可能とする。これにより、各階層のサーバが処理性能の限界まで使用されているのかどうかを正確に把握することができ、上記課題も解消可能である。
【００５８】
例えば、第１の実施の形態では、各サーバのシステムリソースの消費状況の情報ではなく、各サーバの処理の実行期間を示す情報に基づいてボトルネックを検出できる。そのため、上記第１の手法の「特定のシステムリソースを消費し尽くしていない状況で発生したボトルネックは検出できない」という課題は解消している。
【００５９】
また第１の実施の形態では、分析対象期間を細分化した集計区間単位で、合計処理時間が閾値以上か否かを判断する。そのため上記第１〜第３の手法における「極短時間で変化するボトルネックが検出できない」という課題も解決されている。
【００６０】
また第１の実施の形態では、合計処理時間と合計進行量という２つの測定値からボトルネックを判定している。一方で、上記第４の手法は、それら２つの測定値からも算出可能な応答時間／処理時間という単一の測定値からボトルネックの検出を行っている。第４の手法の課題「応答時間／処理時間などの外部観測ではボトルネックを見誤る場合がある」の原因の大きな要素は、単なる下位の階層のサーバからの応答待ち時間の増加をボトルネックと見誤る可能性があることである。第１の実施の形態では、合計処理時間と合計進行量という２つの測定値から二次元の関係を利用してボトルネック判定を行っているため、単なる下位の階層のサーバからの応答待ち時間の増加をボトルネックと見誤る可能性が、抑止されている。
【００６１】
また第１の実施の形態では、各階層のサーバごとにボトルネックの発生の有無を検出できる。そのため、上記第５の手法の課題「階層ごとの多重度・スループットの関係は測定できない」について解消している。
【００６２】
なお、図１に示した監視手段１ａ、計算手段１ｃ、決定手段１ｄ、および検出手段１ｅは、情報処理装置１が有するＣＰＵ（Central Processing Unit）により実現することができる。また、記憶手段１ｂは、情報処理装置１が有するＲＡＭ（Random Access Memory）やハードディスクドライブ（ＨＤＤ:Hard Disk Drive）などにより実現することができる。
【００６３】
また、図１に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。
〔第２の実施の形態〕
次に第２の実施の形態について説明する。第２の実施の形態は、ネットワーク上でのアプリケーションの外部挙動を観測するアプローチを採用する。第２の実施の形態では、スイッチングハブのポートミラーリング機能を使ってネットワークを流れるＩＰパケットをキャプチャし、そこからプロトコルメッセージを再現することによって情報を得る。ここで、プロトコルメッセージは、所定のプロトコルに準拠した情報である。以下、プロトコルメッセージを、単に「メッセージ」と呼ぶ。
【００６４】
なお、コンピュータの単位時間当たりの処理能力は、スループットと呼ばれる。そこで、第２の実施の形態では、第１の実施の形態に示した合計進行量に相当する値を、スループットと呼ぶこととする。
【００６５】
また第２の実施の形態では、第１の実施の形態における合計処理時間を、集計区間の長さで除算することで、集計区間内の処理の多重度の平均値を求め、集計区間内の多重度とする。各集計区間の長さは同じである。そのため、第１の実施の形態で示した性能分析における合計処理時間に代えて多重度を用いても、分析結果に影響はない。そこで第２の実施の形態では、集計区間の多重度を用いて、装置の性能の余力などの分析を行うものとする。
【００６６】
また第２の実施の形態では、複数階層システムとしてＷｅｂ３階層システムを例として説明する。Ｗｅｂ３階層システムとは、Ｗｅｂサーバ、アプリケーションサーバ（以降、Ａｐｐサーバ）、データベースサーバ（以降、ＤＢサーバ）からなる複数階層コンピュータシステムである。エンドユーザのコンピュータ上のブラウザが出力する処理要求は、ＷｅｂサーバがＨＴＴＰに従ったメッセージで受ける。処理要求が静的コンテンツの取得であれば、Ｗｅｂサーバが、保持しているコンテンツを直接エンドユーザのコンピュータへ返信する。他方、処理要求がプログラムによって生成される動的コンテンツの取得の場合、Ｗｅｂサーバは、処理をＡｐｐサーバへ依頼する。処理の依頼を受けたＡｐｐサーバは、Ｊａｖａ（登録商標）などで記述されたプログラムによってその処理要求を実行する。Ａｐｐサーバは、処理の過程において使用されるデータを、それを保持するＤＢサーバに対して処理要求を発行して取得する。
【００６７】
図４は、第２の実施の形態の業務システムの全体構成を示す図である。この業務システムは、分析サーバ１００、Ｗｅｂサーバ２００、Ａｐｐサーバ３００およびＤＢサーバ４００を有する。分析サーバ１００、Ｗｅｂサーバ２００、Ａｐｐサーバ３００およびＤＢサーバ４００は、スイッチ装置１０を介して相互に接続されている。また、スイッチ装置１０は、ネットワーク２０を介して端末装置２１，２２，２３に接続されている。
【００６８】
端末装置２１，２２，２３は、スイッチ装置１０およびネットワーク２０を介してＷｅｂサーバ２００にアクセス可能である。端末装置２１，２２，２３のユーザは、Ｗｅｂサーバ２００が提供するＧＵＩ（Graphical User Interface）を端末装置２１，２２，２３から操作して業務システムを利用できる。ネットワーク２０は、例えばイントラネットである。
【００６９】
なお、ネットワーク２０がインターネットである場合も考えられる。その場合、スイッチ装置１０はファイアウォールとして機能させることもできる。また、Ｗｅｂサーバ２００の属するネットワークセグメントは、例えばＤＭＺ（Demilitarized Zone）として扱われる。
【００７０】
分析サーバ１００は、Ｗｅｂサーバ２００、Ａｐｐサーバ３００およびＤＢサーバ４００の稼働状況を管理する。分析サーバ１００は、そのための情報をスイッチ装置１０から取得することができる。すなわち、スイッチ装置１０は、ポートミラーリング機能を有しており、Ｗｅｂサーバ２００、Ａｐｐサーバ３００およびＤＢサーバ４００の間で送受信される通信パケットを分析サーバ１００にも送信する。ポートミラーリング機能とは、スイッチ装置１０上の設定したポートを流れるＩＰパケットをコピーして、指定した別のポートへ転送する機能である。この転送先として指定されたポートの先に、ＩＰパケット記録や解析を行う分析サーバ１００が配置される。
【００７１】
分析サーバ１００は、スイッチ装置１０から送信される通信パケットを受信して、記憶する（パケットキャプチャ）。なお、分析サーバ１００で単にパケットキャプチャを行う用途であれば、スイッチ装置１０をリピータハブで代用することもできる。分析サーバ１００は、この転送されてくるＩＰパケットを受信可能なネットワークインタフェースを有している。そして分析サーバ１００は、転送されてきたＩＰパケット格納用の十分に大きなハードディスクを有している。さらに、分析サーバ１００は、ＩＰパケットをキャプチャするのに十分なＣＰＵ性能を保有していることが望ましい。転送されてきたＩＰパケットは、分析サーバ１００上でキャプチャされ、その後にメッセージを抽出するための処理が実施される。
【００７２】
Ｗｅｂサーバ２００は、端末装置２１，２２，２３で実行されるＷｅｂブラウザから業務システムに対する処理要求（メッセージ）を受け付ける。ここで、Ｗｅｂサーバ２００と端末装置２１，２２，２３とのメッセージ交換は、ＨＴＴＰによって行われるものとする。ただし、他のプロトコルが用いられてもよい。
【００７３】
以下では、端末装置２１，２２，２３からＷｅｂサーバ２００へ送信する処理要求をＨＴＴＰリクエストと呼ぶこととする。また、それに対する応答をＨＴＴＰレスポンスと呼ぶこととする。なお、リクエスト／レスポンスともに処理要求の一例である。
【００７４】
Ｗｅｂサーバ２００は、端末装置２１，２２，２３から受信したＨＴＴＰリクエストに基づいて、静的コンテンツに関しては自装置でＨＴＴＰレスポンスを生成し、端末装置２１，２２，２３に送信する。なお、動的コンテンツに関しては、Ａｐｐサーバ３００に依頼すべき処理の処理要求（メッセージ）を生成して、Ａｐｐサーバ３００に送信する。
【００７５】
ここで、Ｗｅｂサーバ２００とＡｐｐサーバ３００とのメッセージ交換は、ＩＩＯＰ（Internet Inter-ORB（Object Request Broker） Protocol）によって行われるものとする。ただし、他のプロトコルが用いられてもよい。
【００７６】
以下では、Ｗｅｂサーバ２００からＡｐｐサーバ３００へ送信する処理要求をＩＩＯＰリクエストと呼ぶこととする。また、それに対する応答をＩＩＯＰレスポンスと呼ぶこととする。
【００７７】
Ｗｅｂサーバ２００は、ＩＩＯＰリクエストに対するＩＩＯＰレスポンスを受信すると、その内容に基づいてＨＴＴＰレスポンスを生成して、端末装置２１，２２，２３に送信する。
【００７８】
Ａｐｐサーバ３００は、Ｗｅｂサーバ２００から受信したＩＩＯＰリクエストに基づいてＤＢサーバ４００に依頼すべき処理のクエリを生成し、ＤＢサーバ４００に送信する。
ここで、Ａｐｐサーバ３００が生成するクエリは、例えばＳＱＬ文によって表記され、ＤＢサーバに固有のプロトコルでＤＢサーバへと送信される。以下では、Ａｐｐサーバ３００がＤＢサーバ４００に送信するクエリをＤＢリクエストと呼ぶこととする。また、それに対する応答をＤＢレスポンスと呼ぶこととする。
【００７９】
Ａｐｐサーバ３００は、ＤＢリクエストに対するＤＢレスポンスを受信すると、その内容に基づいてＩＩＯＰレスポンスを生成してＷｅｂサーバ２００に送信する。
ＤＢサーバ４００は、Ａｐｐサーバ３００から受信したＤＢリクエストに含まれるＳＱＬ文を実行してＤＢの参照や更新等の処理を実行する。ＤＢサーバ４００は、その処理結果に基づいてＤＢレスポンスを生成し、Ａｐｐサーバ３００に送信する。
【００８０】
なお、業務システムにおいてＷｅｂサーバ２００、Ａｐｐサーバ３００およびＤＢサーバ４００と各層（Ｗｅｂ層、Ａｐｐ層およびＤＢ層）一台ずつの構成を例示したが、各層にそれぞれ複数台のサーバを設けてもよい。各層に複数のサーバがある場合、各層において負荷分散処理が行われる。
【００８１】
階層間を跨って送受信されるメッセージを取得する手法には何通りか考えられるが、第２の実施の形態では、ネットワーク上を流れるＩＰパケットから情報を取得するものとする。この場合、ポートミラーリング機能を有するスイッチ装置１０が用いられる。
【００８２】
また、以下では各サーバという場合、Ｗｅｂサーバ２００、Ａｐｐサーバ３００およびＤＢサーバ４００を示すものとする。さらに、Ｗｅｂサーバ２００は、Ａｐｐサーバ３００およびＤＢサーバ４００よりも上位層のサーバであるとする。また、Ａｐｐサーバ３００は、ＤＢサーバ４００よりも上位層のサーバであるとする。このような階層関係を定義する情報は、分析サーバ１００に予め格納される。
【００８３】
図５は、第２の実施の形態に用いるコンピュータのハードウェアの一構成例を示す図である。分析サーバ１００は、ＣＰＵ１０１、ＲＯＭ（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）のアクティビティ図で用いられる同期バー３１，３２を用いて、並列処理を表している。同期バー３１は、特にフォークと呼ばれ、１つの処理が２つ以上の並列処理に分割されることを示す。同期バー３２は、特にジョインと呼ばれ、２つ以上の処理の流れを１つに統合することを示す。
【０１０９】
以下、図７に示す処理をステップ番号に沿って説明する。
［ステップＳ１０１］キャプチャ部１１１は、スイッチ装置１０のミラーポートから出力されたＩＰパケットをキャプチャする。キャプチャ部１１１は、例えばキャプチャしたＩＰパケットを、一時的にＲＡＭ１０３に格納する。この際、キャプチャ部１１１は、受信したＩＰパケットに受信時刻を付与する。
【０１１０】
［ステップＳ１０２］キャプチャ部１１１は、キャプチャの開始、またはキャプチャデータの前回のファイル出力から、所定のファイル出力周期が経過したか否かを判断する。ファイル出力周期は、例えば１８０秒といった値が予めキャプチャ部１１１に設定されている。キャプチャ部１１１は、ファイル出力周期が経過した場合、処理をステップＳ１０３に進める。またキャプチャ部１１１は、ファイル出力周期が経過していなければ、処理をステップＳ１０１に進め、ＩＰパケットのキャプチャを継続する。
【０１１１】
［ステップＳ１０３］キャプチャ部１１１は、ＲＡＭ１０３などに一時的に保管してあるキャプチャデータを、ファイル１１２ａに出力する。例えばキャプチャ部１１１は、新規のファイルを作成し、作成したファイル１１２ａにキャプチャデータを出力する。そしてキャプチャ部１１１は、キャプチャデータを含むファイルをキャプチャデータ記憶部１１２に格納する。
【０１１２】
［ステップＳ１０４］キャプチャ部１１１は、停止コマンドが入力されたか否かを判断する。停止コマンドは、例えば管理者が、キーボード１２やマウス１３を操作して分析サーバ１００に入力する。キャプチャ部１１１は、停止コマンドが入力された場合、キャプチャ処理を終了する。またキャプチャ部１１１は、停止コマンドが入力されていなければ、処理をステップＳ１０１に進める。
【０１１３】
このようにして、ファイル出力周期ごとにキャプチャしたデータを含むファイル１１２ａが生成され、順次キャプチャデータ記憶部１１２に格納される。
［ステップＳ１０５］メッセージ解析部１２１は、キャプチャデータ記憶部１１２から、性能分析処理を行っていない、未処理のファイル１１２ａがあるか否かを判断する。未処理のファイルは、キャプチャ部１１１により、ファイル出力周期で定期的にキャプチャデータ記憶部１１２に順次格納されている。従って、メッセージ解析部１２１は、ファイル出力周期で、未処理のファイルを検出できる。
【０１１４】
［ステップＳ１０６］メッセージ解析部１２１は、キャプチャデータ記憶部１１２内の未処理のファイル１１２ａからキャプチャデータを読み込む。
［ステップＳ１０７］分析サーバ１００内の各機能が連携して性能分析を行う。この処理の詳細は後述する。
【０１１５】
［ステップＳ１０８］メッセージ解析部１２１は、停止コマンドが入力されたか否かを判断する。停止コマンドは、例えば管理者が、キーボード１２やマウス１３を操作して分析サーバ１００に入力する。メッセージ解析部１２１は、停止コマンドが入力された場合、分析処理を終了する。またメッセージ解析部１２１は、停止コマンドが入力されていなければ、処理をステップＳ１０５に進める。
【０１１６】
このように、キャプチャされたデータは、一定時間分（例えば１８０秒間）だけ貯められて、一定時間間隔で、その一定時間分のデータを使用して性能分析処理が行われる。このとき、データの収集処理（ステップＳ１０１〜Ｓ１０４）と性能分析処理（ステップＳ１０７）は切り離して非同期で行ってもよい。ただし、ボトルネック発生をリアルタイムに監視するためには、図７に示すようにデータの収集処理（ステップＳ１０１〜Ｓ１０４）と性能分析処理（ステップＳ１０７）を同期して動作させ、収集されたデータをすぐに処理するのが理想的である。
【０１１７】
図８は、キャプチャデータ記憶部のデータ構造の一例を示す図である。キャプチャデータ記憶部１１２には、複数のファイル１１２ａ，１１２ｂ，１１２ｃ，・・・が格納されている。
【０１１８】
ファイル１１２ａには、複数のＩＰパケット１１２ｄ−１〜１１２ｄ−７が含まれている。またＩＰパケット１１２ｄ−１〜１１２ｄ−７それぞれには、受信時刻１１２ｅ−１〜１１２ｅ−７が付与されている。他のファイル１１２ｂ，１１２ｃ，・・・も、ファイル１１２ａと同様に、受信時刻が付与されたＩＰパケットを含んでいる。
【０１１９】
次に、性能分析処理について詳細に説明する。
図９は、性能分析処理の手順を示すフローチャートである。以下、図９に示す処理をステップ番号に沿って説明する。
【０１２０】
［ステップＳ１１１］メッセージ解析部１２１は、取得したファイルに含まれるＩＰパケットに基づいて、メッセージを再構築する。メッセージ解析部１２１は、再構築したメッセージを、メッセージデータ記憶部１２２に時系列に格納する。
【０１２１】
［ステップＳ１１２］メッセージフロー検出部１３２は、メッセージデータ記憶部１２２に格納されたメッセージから、一つの業務処理リクエストに応じて多階層システム内で発行された一連のメッセージ送受関係を示すメッセージフローを検出する。
【０１２２】
第２の実施の形態では、メッセージは階層ごとに異なるプロトコルが使われている。端末装置２１〜２３からの一つのリクエストに関連して、多階層システム内の各階層で発行される異なるプロトコルのメッセージ間には、それらを関連付けるための情報が含まれていない場合が多い。そこで第２の実施の形態では、これらの異なるプロトコル間のメッセージを、既知のモデルと照合することで関連付ける。例えばメッセージフロー検出部１３２は、予め用意されたメッセージフローのモデルと、メッセージデータ記憶部１２２に格納されたメッセージとを比較し、モデルに合致するメッセージの組み合わせを作成する。そしてメッセージフロー検出部１３２は、作成されたメッセージの組み合わせをメッセージフローとする。
【０１２３】
［ステップＳ１１３］メッセージフロー検出部１３２は、検出したメッセージフローに含まれるリクエストメッセージに応じて、各階層のサーバで実行される処理のジョブ種を判定する。例えばメッセージフロー検出部１３２は、抽象化ルール記憶部１３１に格納されている抽象化ルールに従って、リクエストメッセージを抽象化する。そしてメッセージフロー検出部１３２は、抽象化後の内容が同じリクエストメッセージ同士をまとめて、１つのジョブ種とする。検出されたジョブ種には、識別名（ジョブ種名）が付与される。
【０１２４】
そしてメッセージフロー検出部１３２は、リクエストメッセージにジョブ種名が付与されたメッセージフローを、メッセージフロー情報記憶部１３３に格納する。
［ステップＳ１１４］飽和多重度決定部１４４は、未処理の階層を選択する。例えば飽和多重度決定部１４４には、多階層システムを構成する各階層のサーバに入力するリクエストメッセージのプロトコル名が予め設定されている。Ｗｅｂ３階層であれば、例えばプロトコル名「ＨＴＴＰ」、「ＩＩＯＰ」、「ＤＢ」の各プロトコル名が飽和多重度決定部１４４に設定されている。飽和多重度決定部１４４は、設定されているプロトコル名に対応する階層を順に選択する。
【０１２５】
［ステップＳ１１５］飽和多重度決定部１４４と分析部１４５とが連携し、選択したプロトコル名に対応する階層の性能分析処理を行う。この処理の詳細は後述する（図１６参照）。
【０１２６】
［ステップＳ１１６］飽和多重度決定部１４４は、全ての階層について階層別の性能分析処理を実行したか否かを判断する。例えば飽和多重度決定部１４４は、予め設定されているプロトコル名で示される全ての階層が選択済みであれば、未処理の階層なしと判断する。未処理の階層がある場合、飽和多重度決定部１４４は、処理をステップＳ１１４に進める。未処理の階層がなければ、飽和多重度決定部１４４は、性能分析処理を終了する。
【０１２７】
このように、性能分析処理では、まずメッセージが再構築され、メッセージデータ記憶部１２２に格納される。
図１０は、メッセージデータ記憶部のデータ構造の一例を示す図である。メッセージデータ記憶部１２２には、復元された複数のメッセージが、時系列に格納されている。このように時系列に並べられたメッセージが、時系列データである。図１０では、各メッセージの左に、メッセージデータ記憶部１２２内での行番号を示している。なお、メッセージデータ記憶部１２２には、各階層間の処理要求および応答に関連するメッセージ以外のメッセージに関しては図示を省略している。
【０１２８】
各行に示されるメッセージには、日付フィールド１２２ａ、時刻フィールド１２２ｂ、セッション番号フィールド１２２ｃ、送信元アドレスフィールド１２２ｄ、送信先アドレスフィールド１２２ｅ、コマンド種別フィールド１２２ｆおよびメッセージフィールド１２２ｇが含まれる。
【０１２９】
日付フィールド１２２ａは、メッセージをキャプチャした日付を示すフィールドである。
時刻フィールド１２２ｂは、メッセージをキャプチャした時刻を示すフィールドである。
【０１３０】
セッション番号フィールド１２２ｃは、業務システムにおけるメッセージの送受信に用いるリソースを管理するためのセッション番号を示すフィールドである。
送信元アドレスフィールド１２２ｄは、メッセージの送信元のコンピュータのＩＰアドレスおよびポート番号を示すフィールドである。
【０１３１】
送信先アドレスフィールド１２２ｅは、メッセージの送信先のコンピュータのＩＰアドレスおよびポート番号を示すフィールドである。
コマンド種別フィールド１２２ｆは、コマンドのリクエスト／レスポンス属性やプロトコル（ＨＴＴＰ、ＩＩＯＰおよびＤＢクエリ用等）の種別を示すフィールドである。
【０１３２】
メッセージフィールド１２２ｇは、コマンド種別フィールド１２２ｆに示されたリクエスト等のメッセージ内容を示すフィールドである。
このようなメッセージデータ記憶部１２２内のメッセージを参照することで、何れのサーバに対して、どのようなメッセージが送信されたかを検出することができる。
【０１３３】
ここで、メッセージデータ記憶部１２２内のメッセージ中のその他のＩＰアドレスと各装置との対応関係は次の通りである。
“１９４．２３．５．２２６”は、Ｗｅｂサーバ２００のＩＰアドレスを示す。“１９４．２３．７．１６８”は、Ａｐｐサーバ３００のＩＰアドレスを示す。“１９４．２３．８．１９８”は、ＤＢサーバのＩＰアドレスを示す。“１９４．１８５．３９．２４”は、端末装置２２のＩＰアドレスを示す。
【０１３４】
なお、日付フィールド１２２ａおよび時刻フィールド１２２ｂの情報として、メッセージ解析部１１０が通信パケットをキャプチャしたタイミングにおけるタイムスタンプを設定するものとしたが、設定方法はこれに限らない。例えば、通信パケット中に各サーバにおけるパケットの生成時刻や送信時刻の情報が含まれている場合には、その日時を日付フィールド１２２ａおよび時刻フィールド１２２ｂの情報としてもよい。その場合、各サーバで精度良く時刻同期が行われていることが望ましい。
【０１３５】
メッセージが再構築されると、メッセージフロー検出部１３２は、検出されたメッセージフロー内のリクエストメッセージに関し、そのリクエストメッセージによって実行されるジョブのジョブ種を識別する。ここでいうジョブ種は、同様の処理内容のリクエストをグループ化したものである。メッセージフロー検出部１３２は、ジョブ種を識別する場合、抽象化ルール記憶部１３１に設定された抽象化ルールに基づいて、リクエストメッセージを抽象化する。
【０１３６】
図１１は、抽象化ルール記憶部のデータ構造の一例を示す図である。抽象化ルール記憶部１３１には、プロトコルごとの抽象化ルールが格納されている。
例えばプロトコルがＨＴＴＰのメッセージの場合は、メッセージフロー検出部１３２は、コマンド名と、ＵＲＬ内のローカルアドレス部分に、残すべきと指定されたＣＧＩ（Common Gateway Interface）パラメータを連結したもので、ジョブ種を区別する。コマンド名は、ＧＥＴやＰＯＳＴ等である。ＵＲＬ内のローカルアドレス部分は、ＵＲＬから“プロトコル名://ホスト名:ポート番号”の部分を削除したものである。そしてＨＴＴＰ用の抽象化ルール１３１ａには、残すべきＣＧＩパラメータが定義されている。例えば、図１１の例では、「type」、「comment＿table」の各パラメータを残し、他のパラメータは削除することが示されている。
【０１３７】
またＤＢプロトコルのメッセージの場合は、メッセージフロー検出部１３２は、使用するＤＢプロトコル固有のコマンド名とＳＱＬ文とを、正規表現で記述したルールで置換する。そしてメッセージフロー検出部１３２は、置換によって抽象化されたメッセージによりジョブ種を区別する。ＤＢプロトコル用の抽象化ルール１３１ｂには、正規表現を用いた置換規則が定義されている。図１１の例では、Ｐｅｒｌと同じ記法による置換規則が定義されている。例えば１行目の置換規則「s/INSERT INTO ([^ \(]+).*/INSERT INTO $1 VALUES (..)/」の先頭の「s」は、置換処理であることを示している。最初の「/」と２つめの「/」で囲われた文字列「INSERT INTO ([^ \(]+).*」が、置換元の文字列である。また２つめの「/」と３つめの「/」で囲われた文字列「INSERT INTO $1 VALUES (..)」が、置換後の文字列である。置換元の文字列の「(」と「)」とで囲われた文字列は、変数として記憶される。１行目の置換規則の「(」、「)」で囲われた文字列「[^ \(]+」は、「(」以外の文字の１回以上の繰り返しが、正規表現で示されている。「(」と「)」とで囲われた文字列は、左から順に記憶される。ｎ番目に記憶された文字列には、「$n」（ｎは、１以上の整数）という変数名が与えられる。変数に記憶された文字列は、置換後の文字列内に、変数名で指定された位置に挿入される。
【０１３８】
このような抽象化ルールに従ってリクエストメッセージが抽象化される。そして、抽象化された後の内容が同じリクエストメッセージ同士が、同じジョブ種となる。
図１２は、ＨＴＴＰのプロトコルのジョブ種の例を示す図である。図１２の例では、ＨＴＴＰのプロトコルに関するジョブ種名に対応付けて、コマンド名と、抽象化されたジョブ内容とが示されている。例えば、ジョブ種名「Ｗ１」のジョブ種は、コマンド名「GET」であり、ジョブ内容が「/RUBBOS/SERVLET/EDU.RICE.RUBBOS.SERVLETS.STORIESOFTHEDAY」である。
【０１３９】
図１３は、ＤＢのプロトコルのジョブ種の例を示す図である。図１３の例では、ＤＢのプロトコルに関するジョブ種名に対応付けて、コマンド名と、抽象化されたジョブ内容とが示されている。例えば、ジョブ種名「Ｄ１」のジョブ種は、コマンド名「EXECREADREQ」であり、ジョブ内容が「SELECT .. FROM STORIES, USERS WHERE ..」である。
【０１４０】
メッセージの抽象化が終了すると、メッセージフロー検出部１３２によりメッセージ同士の関連付けが行われ、関連付けられたメッセージを時系列に並べたメッセージフローが検出される。メッセージフローは、各階層のプロトコル間のメッセージにおいて、同一のトランザクションによって発行された関連するメッセージ同士を紐付けたものである。例えば上位層のプロトコルによって、その下の階層のサーバに送られたメッセージと、その処理に伴って生成された下位層のプロトコルのメッセージとの間が紐付けされる。このようなメッセージ間の紐付けを全ての階層のプロトコル間で行うことによって、最上位層から最下位層までの間で、一連のトランザクションを構成する全てのメッセージ送受の関係が再現される。このようなメッセージフローの検出方法として、例えば特開２００６−０１１６８３号公報に記載の方法を利用することができる。
【０１４１】
図１４は、ジョブ種が識別されたメッセージフローの一例を示す図である。なお図１４では、各サーバがジョブに関する処理を実行している期間を実線で示し、ジョブに関する処理を実行していない期間を破線で示している。サーバがジョブに関する処理を実行していない期間とは、例えば、下位層のサーバにリクエストメッセージを送信し、そのリクエストメッセージに対するレスポンスメッセージを待っている期間である。
【０１４２】
図１４の例では、Ｗｅｂサーバ２００では、ＨＴＴＰリクエストメッセージ４１に応じて、ジョブ種「Ｗ１」のジョブ６１が実行されている。Ｗｅｂサーバ２００は、ジョブ種「Ｗ１」のジョブ６１の実行途中で、Ａｐｐサーバ３００に対してＩＩＯＰリクエストメッセージ４２を送信している。
【０１４３】
Ａｐｐサーバ３００では、ＩＩＯＰリクエストメッセージ４２に応じて、ジョブ種「Ａ１」のジョブ６２が実行されている。Ａｐｐサーバ３００は、ジョブ種「Ａ１」のジョブ６２の実行途中で、ＤＢサーバ４００に対してＤＢリクエストメッセージ４３を送信している。
【０１４４】
ＤＢサーバ４００では、ＤＢリクエストメッセージ４３に応じて、ジョブ種「Ｄ１」のジョブ６３が実行されている。ＤＢサーバ４００は、ジョブ種「Ｄ１」のジョブ６３の実行が終了すると、Ａｐｐサーバ３００に対してＤＢレスポンスメッセージ４４を送信している。
【０１４５】
以後、Ａｐｐサーバ３００からＤＢサーバ４００へのＤＢリクエストメッセージ４５，４７，４９の送信と、ＤＢサーバ４００からＡｐｐサーバ３００へのレスポンスメッセージ４６，４８，５０とが繰り返し行われる。ＤＢサーバ４００では、ＤＢリクエストメッセージ４５，４７，４９に応じたジョブ６４〜６６が実行されている。
【０１４６】
Ａｐｐサーバ３００では、ＤＢレスポンスメッセージ５０に応じて、ジョブ種「Ａ１」のジョブ６２の実行が再開されている。Ａｐｐサーバ３００は、ジョブ種「Ａ１」のジョブ６１の処理が終了すると、Ｗｅｂサーバ２００に対してＩＩＯＰレスポンスメッセージ５１を送信している。Ｗｅｂサーバ２００では、ＩＩＯＰレスポンスメッセージ５１に応じて、ジョブ種「Ｗ１」のジョブ６１の実行が再開されている。Ｗｅｂサーバ２００は、ジョブ種「Ｗ１」のジョブ６１の処理が終了すると、ＨＴＴＰリクエストメッセージ４１を送信した端末装置に対してＨＴＴＰレスポンスメッセージ５２を送信している。
【０１４７】
メッセージフロー検出部１３２は、ジョブ種を識別したメッセージフローに関するメッセージフロー情報を、メッセージフロー情報記憶部１３３に格納する。
図１５は、メッセージフロー情報記憶部のデータ構造の一例を示す図である。メッセージフロー情報記憶部１３３には、トランザクションごとのメッセージフロー情報１３３ａ，１３３ｂ，１３３ｃ，・・・が格納されている。
【０１４８】
メッセージフロー情報１３３ａには、項番を示す項目、時刻を示す項目、セッション番号を示す項目、プロトコルを示す項目、Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅを示す項目、およびジョブ種を示す項目が設けられている。各項目の横方向に並べられた情報同士が互いに関連付けられて、１つのメッセージに関する情報を示す。
【０１４９】
項番を示す項目には、レコードを識別する番号が設定される。時刻を示す項目には、メッセージに対応する通信パケットをキャプチャした時刻が設定される。セッション番号を示す項目には、メッセージを送信するために用いられたセッションを識別するセッション番号が設定される。プロトコルを示す項目には、メッセージが何れのプロトコルによるものかを示す情報が設定される。Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅを示す項目には、そのメッセージがリクエスト／レスポンスの何れのものであるかを示す情報が設定される。ジョブ種を示す項目には、リクエストメッセージで要求している処理のジョブ種の名称（ジョブ種名）が設定される。 メッセージフロー情報１３３ａには、例えば、項番が“１”、時刻が“０１：５８：１９．９８７”、セッション番号が“１５２２９０”、プロトコルが“ＨＴＴＰ”、Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅが“Ｒｅｑｕｅｓｔ”、ジョブ種“Ｗ１”という情報が設定される。
【０１５０】
図１５の例では、時刻には、ミリ秒までの時間単位で設定している。この点、さらに短い時間単位（例えば、マイクロ秒単位）で時刻を取得してもよい。また、セッション番号には図１０に示したセッション番号フィールド１２２ｃに含まれる情報のうち、リクエスト／レスポンスの組を特定するために必要な最低限の情報を設定している。以下、セッション番号という場合、メッセージフロー情報１３３ａのセッション番号を示す項目に設定された情報を示すものとする。
【０１５１】
メッセージフロー情報には、各メッセージの通信時刻が設定されている。すなわち、キャプチャしたパケットに基づいて、メッセージフローを構成する各メッセージの通信時刻が測定されている。また、ある階層へ処理要求のメッセージが到着して、その処理に関連して下位層へ処理を要求するメッセージが送信された場合に、それらの間の関連付けは、メッセージフロー内の連続するメッセージに基づいて判断できる。すなわち、プロトコル「ＩＩＯＰ」のリクエストメッセージの後に、プロトコル「ＤＢ」のリクエストメッセージがあれば、「ＩＩＯＰ」のリクエストメッセージに関連して「ＤＢ」のリクエストメッセージが出力されたことが分かる。また、上位層のリクエストメッセージからレスポンスメッセージまでの時間帯内の下位層の各リクエストメッセージは、その上位層のリクエストメッセージに応じて実行された処理に関連して実行されていることが分かる。
【０１５２】
このように第２の実施の形態では、ネットワーク上を流れるＩＰパケットをキャプチャして、そこからメッセージ送受の情報を取得することで、一連の処理を示すメッセージフロー情報を生成している。この方法の利点としては、観測対象のシステムに余計な負荷を与えないので正確な挙動を観測できるということがある。また、１か所のサーバでキャプチャしてその際にタイムスタンプを付与できるのでサーバ間の時計誤差を気にしなくてよいという利点もある。
【０１５３】
なお第２の実施の形態では、各メッセージ上にそれらを関連付ける情報が付加されてない場合を想定している。そのため、メッセージフロー検出部１３０によるトランザクションモデルとの適合の有無の判定などが行われている。他方、各メッセージ上にそれらを関連付ける情報が付加されている場合もあり得る。例えば、最上位のサーバ（Ｗｅｂサーバ２００）に入力されたリクエストメッセージに応じて実行されるトランザクションの識別情報が、そのトランザクションで通信される各メッセージに付与しているような場合である。このような場合、メッセージフロー検出部１３０は、同一の識別情報が付与されたメッセージを抽出して、メッセージフローを生成することができる。
【０１５４】
なお、第２の実施の形態では、特開２００６−０１１６８３号公報に記載の方法を利用してメッセージフロー情報を作成しているが、メッセージフロー情報の作成手法は特開２００６−０１１６８３号公報に記載の方法に限定されるものではない。すなわち、個々の業務処理に関する複数階層間を跨った一連のメッセージフローを測定し、その中での各メッセージの正確な送受時刻を取得する手法は何通りか考えられる。
【０１５５】
他の方法としては、例えば、Ｗｅｂ３階層システムを構成する各Ｗｅｂサーバ２００、Ａｐｐサーバ３００、およびＤＢサーバ４００でファイルなどに記録したメッセージ送信／受信ログを利用する方法がある。この方法を適用する場合、Ｗｅｂサーバ２００、Ａｐｐサーバ３００、およびＤＢサーバ４００が、受信メッセージとその処理に関連した送信メッセージの関連付けを行い、ログ情報としてＨＤＤなどの記録装置に記録する。分析サーバ１００は、Ｗｅｂサーバ２００、Ａｐｐサーバ３００、およびＤＢサーバ４００から、記録した情報を取得する。この手法では、Ｗｅｂサーバ２００、Ａｐｐサーバ３００、およびＤＢサーバ４００が、受信したリクエストメッセージと、そのリクエストメッセージに応じた処理により下位の層のサーバへ出力したリクエストメッセージとを関連付けている。そのため、分析サーバ１００では、１つのトランザクションを構成する上位層のメッセージと下位層のメッセージとを容易に関連付けることができ、メッセージフローの作成が容易となる。ただし、この方法を適用する場合、Ｗｅｂサーバ２００、Ａｐｐサーバ３００、およびＤＢサーバ４００各サーバの内部時計を、正確に同期させておくことが好ましい。
【０１５６】
メッセージデータ記憶部１２２に格納されたメッセージから検出可能な全てのメッセージフローがメッセージフロー情報記憶部１３３に格納された後、Ｗｅｂ三階層システムの階層ごとの性能分析が行われる。
【０１５７】
図１６は、階層別性能分析処理の手順の一例を示すフローチャートである。以下、図１６に示す処理をステップ番号に沿って説明する。
［ステップＳ１２１］集計部１４１は、分析対象期間を、十分に細かい粒度で分割する。分析対象期間は、キャプチャデータ記憶部１１２内の現在処理対象となっている時系列データの生成元となったＩＰパケットの採取期間である。また分析対象期間を分割することで生成された複数の期間を、集計区間とする。飽和多重度決定部１４４は、例えば、個々の集計区間の期間を示す情報を、集計区間情報記憶部１４２に格納する。
【０１５８】
［ステップＳ１２２］集計部１４１は、各集計区間のスループットと多重度とを算出する。この処理の詳細は後述する（図２１参照）。
［ステップＳ１２３］飽和多重度決定部１４４は、飽和多重度を算出する。この処理の詳細は後述する（図２７参照）。
【０１５９】
［ステップＳ１２４］分析部１４５は、性能分析対象となっている階層がボトルネックとなっているか否かを判定する。この処理の詳細は後述する（図２８参照）。その後、階層別性能分析処理が終了する。
【０１６０】
次に、図１６に示す各ステップの処理を詳細に説明する。
＜集計区間への分割＞
分析対象期間の集計区間への分割処理について説明する。集計部１４１は、分析対象期間を、十分に細かい粒度の集計区間に分割する。
【０１６１】
なお、第２の実施の形態の手法を実施する場合、細分化した一つの集計区間の長さは十分に短くするのが適切である。なぜならば、多重度はジョブの平均処理時間に近い極短時間で大きく変化する。また、一般的に多重度とスループットの関係は図１７のような関係となる。
【０１６２】
図１７は、多重度とスループットとの関係を示す図である。図１７では、細粒度で集計区間を分割した場合の、各集計区間の多重度とスループットとを表Ａに示している。また各集計区間の多重度とスループットとの関係をグラフＢに示している。
【０１６３】
図１７に示すように、集計区間の長さを十分に細かくすると、集計区間それぞれの多重度は、大きく異なる。もし集計区間を長くして、例えば図１７の「集計区間１」から「集計区間８」までを１つの集計区間にまとめると、まとめられた集計区間の多重度は、もとの集計区間の多重度の平均となる。集計区間ごとのばらつきが大きい多重度を平均化した結果として、多重度とスループットとの関係を不正確に捉えてしまう結果となる。このことを避けるために、この細分化された集計区間の長さは、集計区間内での多重度変化が小さくなるように、ジョブの平均処理時間に応じて、短く設定する。例えば、集計区間の長さは「１００ｍｓ」とする。
【０１６４】
図１８は、集計区間への分割例を示す図である。図１８の例では、１００ｍｓの集計区間長で、分析対象期間が分割されている。なお第２の実施の形態では、集計区間長は、例えば、予め集計部１４１に設定されている。
【０１６５】
図１８に示すように、分析対象期間の分割に伴い、各ジョブの実行期間は、いずれかの集計区間に振り分けられる。これにより、集計区間ごとに、非常に短い時系列データが構成される。
【０１６６】
図１９は、実行期間の集計区間への振り分け例を示す図である。Ｗｅｂサーバ２００で実行されたジョブ６１は、２回の実行期間６１ａ，６１ｂにおいて、処理が実行されている。１回目の実行期間６１ａは、「集計区間１」の時間帯に含まれているため、「集計区間１」に振り分けられる。また実行期間６１ｂは、「集計区間２」の時間帯に含まれているため、「集計区間２」に振り分けられる。
【０１６７】
Ａｐｐサーバ３００で実行されたジョブ６２は、５回の実行期間６２ａ，６２ｂ，６２ｃ，６２ｄ，６２ｅにおいて、処理が実行されている。１回目と２回目との実行期間６２ａ，６２ｂは、「集計区間１」の時間帯に含まれているため、「集計区間１」に振り分けられる。３回目〜５回目の実行期間６２ｃ，６２ｄ，６２ｅは、「集計区間２」の時間帯に含まれているため、「集計区間２」に振り分けられる。
【０１６８】
ＤＢサーバ４００で実行されたジョブ６３〜６６は、各ジョブが１回ずつの実行期間で実行されている。ジョブ６３は、「集計区間１」の時間帯に実行されているため、「集計区間１」に振り分けられる。ジョブ６５，６６は、「集計区間２」の時間帯に実行されているため、「集計区間２」に振り分けられる。
【０１６９】
ジョブ６４は、「集計区間１」と「集計区間２」とに跨って実行されている。このように、実行期間が複数の集計区間を跨り、複数の集計区間に属する実行期間も存在する。この場合、複数の集計区間に属する実行期間が、各集計区間に属する期間ごとに分割される。例えばジョブ６４の全体の実行期間は、「集計区間１」に属する実行期間６４ａと「集計区間２」に属する実行期間６４ｂとに分割される。そして分割後の各実行期間６４ａ，６４ｂが、各集計区間に振り分けられる。
【０１７０】
なお図１８、図１９には、１つの業務処理に応じて行われた一連の処理について示しているが、複数の業務処理が、各階層のサーバにおいて並列で実行される場合もある。
図２０は、並列で処理が実行される状況を示す図である。図２０の例では、「集計区間１」と「集計区間２」との間に、３つの業務処理が並列で実行されている。ジョブ６１〜６６によって１つの業務処理が実行され、ジョブ７１〜７５によって１つの業務処理が実行され、ジョブ８１〜８３によって１つの業務処理が実行されている。なお、図２０において、各ジョブを示す矩形内の文字は、各ジョブのジョブ種を示している。
【０１７１】
このように複数の業務処理が並列で実行される場合も、図１９に示したように、各ジョブの実行期間が、その実行期間を包含する集計区間に振り分けられる。
次にスループットと多重度との算出処理について詳細に説明する。
【０１７２】
図２１は、スループット・多重度算出処理の手順の一例を示すフローチャートである。以下、図２１に示す処理をステップ番号に沿って説明する。
［ステップＳ１３１］集計部１４１は、未処理の集計区間を１つ選択する。例えば集計部１４１は、集計区間情報記憶部１４２に設定されている集計区間を、先頭のエントリから順に選択する。
【０１７３】
［ステップＳ１３２］集計部１４１は、選択した集計区間のスループットを計算する。例えば集計部１４１は、ジョブ種ごとの１ジョブ当たりの正規化したスループット値により、各ジョブに重み付けを行うことで、処理負荷の異なる複数のジョブを処理する場合のスループット算出の正確性を向上させる。集計部１４１は、計算したスループットを、例えば集計区間情報記憶部１４２に格納する。
【０１７４】
［ステップＳ１３３］集計部１４１は、選択した集計区間の多重度を計算する。例えば集計部１４１は、処理中の階層のサーバで選択した集計区間内に存在しているジョブの、集計区間内での処理時間の合計を求める。そして集計部１４１は、求めた合計を集計区間長で除算し、除算結果を集計区間の多重度とする。この多重度は、集計区間内の平均的な多重度を表している。集計部１４１は、計算した多重度を、例えば集計区間情報記憶部１４２に格納する。
【０１７５】
［ステップＳ１３４］集計部１４１は、未処理の集計区間があるか否かを判断する。例えば集計部１４１は、集計区間情報記憶部１４２に設定されている集計区間の最後のエントリの処理が終了した場合、未処理の集計区間はないと判断する。未処理の集計区間がある場合、集計部１４１は、処理をステップＳ１３１に進める。未処理の集計区間がなければ、集計部１４１は、スループット・多重度算出処理を終了する。
【０１７６】
図２２は、集計区間情報記憶部のデータ構造の一例を示す図である。集計区間情報記憶部１４２には、階層ごとの集計区間管理テーブル１４２ａ，１４２ｂ，１４２ｃが格納されている。例えば集計区間管理テーブル１４２ａは、ＤＢサーバ４００の階層に対応する。
【０１７７】
集計区間管理テーブル１４２ａには、集計区間、期間、スループット、および多重度の欄が設けられている。集計区間の欄には、集計区間の名称が設定される。期間の欄には、集計区間の期間が設定される。スループットの欄には、集計区間のスループットが設定される。多重度の欄には、集計区間の多重度が設定される。
【０１７８】
＜スループット・多重度計算＞
次に、スループットの計算と多重度の計算とについて、詳細に説明する。
＜＜スループット計算＞＞
まず、スループット計算処理について詳細に説明する。飽和多重度決定部１４４は、集計区間ごとに、その集計区間に属するジョブの処理時間に基づいて、スループットを計算する。この際、飽和多重度決定部１４４は、ジョブ種間の差異を考慮した重み付けを行って、正規化したスループットを計算する。
【０１７９】
ここで、スループットの正規化の有用性について説明する。第２の実施の形態では、分析対象期間を短い集計区間に細分化する。ここで、正規化を行わずに多重度とスループットの関係を求めようとすると、下記の２つの要素が両者の関係における揺らぎとなって、関連性を失わせる可能性がある。すると、多重度とスループットとの関連性を用いたボトルネック判定の信頼性が低下してしまう。
１．異種ジョブ間でのハードウェア資源消費量の差異
２．同種ジョブの個々のジョブ間でのハードウェア資源消費量の差異
特に１．は差異の絶対量が大きく、また、短い時間区間に区切ると、各区間同士の間でジョブ種の混合割合が偏るので、結果として大きな影響を及ぼすことになる。一方、２．の方は、同種ジョブということで、ある程度は平均化した分布（正規分布など）となることが期待できる。
【０１８０】
そこで、第２の実施の形態では、低負荷時に測定したジョブ種ごとの平均処理時間を利用して、異種ジョブ間でのハードウェア資源消費量の差異を正規化することによって、１．の問題を解決した正確なスループットを得る。ジョブ種間の差異を考慮した重みの判断指標となる情報は、予め正規化スループット値記憶部１４３に格納されている。
【０１８１】
図２３は、正規化スループット値記憶部のデータ構造の一例を示す図である。正規化スループット値記憶部１４３には、正規化スループット値テーブル１４３ａが格納されている。正規化スループット値テーブル１４３ａには、ジョブ種、低負荷時の平均処理時間、および正規化されたスループット値の欄が設けられている。
【０１８２】
ジョブ種の欄には、Ｗｅｂ三階層システムのいずれかのサーバで実行されるジョブのジョブ種名が設定される。
低負荷時の平均処理時間の欄には、対応するジョブ種のジョブを、サーバが低負荷時に実行した場合の平均処理時間が設定される。図２３の例では、低負荷時の平均処理時間の欄に、「ｍｓ」単位の数値が設定されている。低負荷時の平均処理時間は、例えば、システムの管理者が、予めＷｅｂ三階層システムの負荷が少ない状態で計測し、正規化スループット値テーブル１４３ａに設定する。
【０１８３】
正規化されたスループット値の欄には、各ジョブ種の１ジョブ当たりの正規化されたスループット値が設定される。例えば階層ごとに、代表ジョブ種が１つずつ選択される。図２３の例では、Ｗｅｂサーバ２００で実行されるジョブ種に関しては、ジョブ種名「Ｗ１」のジョブ種が、代表ジョブ種である。Ａｐｐサーバ３００で実行されるジョブ種に関しては、ジョブ種名「Ａ１」のジョブ種が、代表ジョブ種である。ＤＢサーバ４００で実行されるジョブ種に関しては、ジョブ種名「Ｄ１」のジョブ種が、代表ジョブ種である。各階層の代表ジョブ種に関しては、１ジョブ当たりの正規化されたスループット値は「１．００」である。
【０１８４】
代表ジョブ種以外のジョブ種に関しては、同じ階層の代表ジョブ種と比較し場合に、低負荷時の平均処理時間が何倍となるかを示す数値が、そのジョブ種の１ジョブ当たりの正規化されたスループット値となる。例えばジョブ種名「Ｗ２」のジョブ種は、低負荷時の平均処理時間が、代表ジョブ種（ジョブ種名「Ｗ１」）の平均処理時間の０．６０４倍（１３．４ｍｓ／２２．２ｍｓ）である。従って、ジョブ種名「Ｗ２」のジョブ種の１ジョブ当たりの正規化されたスループット値は、「０．６０４」となる。
【０１８５】
このような１ジョブ当たりの正規化されたスループット値を用いて、集計部１４１は、細分化した各集計区間について、その集計区間内の平均スループットを計算する。すなわち集計部１４１は、低負荷時に収集したジョブ種ごとの平均処理時間を利用して、スループットの重み付けを行う。例えば集計部１４１は、各ジョブの処理（要求を受けてから返信を返すまで）に関し、スループットの基準スコアを「１」とする。そして集計部１４１は、基準スコアに、低負荷時のジョブ種別ごとの平均処理時間を元に計算された１ジョブ当たりの正規化されたスループット値による重み付けを行い、ジョブごとの１ジョブ当たりのスコアを求める。さらに集計部１４１は、ジョブ全体の実行期間のうち、各集計区間に属している割合に応じた比率で、１つのジョブのスコアを、そのジョブの実行期間が属する集計区間に分配する。そして集計部１４１は、分配したスコアを、各集計区間のスループットに加算する。
【０１８６】
以下、図１９に示した集計区間のスループット計算例を示す。なお図１９に示したように、各階層のジョブ６１〜６６のうち、各階層のサーバで処理を行っている期間のみが実行期間となり、他の階層へリクエストメッセージを送信してからレスポンスメッセージを待っている期間は、実行期間から除外される。
【０１８７】
まずＷｅｂサーバ２００の階層におけるスループットの計算例を示す。図１９の例では、ジョブ６１の２つの実行期間６１ａ，６１ｂのうち、１回目の実行期間６１ａのみが「集計区間１」に含まれ、２回目の実行期間は「集計区間２」に含まれる。実行期間６１ａの長さ（処理時間）は「１４ｍｓ」であり、実行期間６１ｂの長さ（処理時間）は「１１ｍｓ」である。するとジョブ６１の合計の処理時間は「２５ｍｓ」である。またジョブ６１のジョブ種は「Ｗ１」であり、正規化スループット値テーブル１４３ａ（図２３参照）では、１ジョブ当たりの正規化されたスループット値は「１．００」である。正規化されたスループット値で示されるスコア「１．００」が、「集計区間１」と「集計区間２」とに含まれる処理時間比率で分配される。すると「集計区間１」のスコアが「０．５６」（＝１．００×１４／２５）、「集計区間２」のスコアが「０．４４」（＝１．００×１１／２５）となる。得られたスコアが、Ｗｅｂサーバ２００の階層における各集計区間のスループットに加算される。
【０１８８】
次にＡｐｐサーバ３００の階層におけるスループットの計算例を示す。図１９の例では、ジョブ６２の５つの実行期間６２ａ，６２ｂ，６２ｃ，６２ｄ，６２ｅのうち、２つの実行期間６２ａ，６２ｂが「集計区間１」に含まれ、３つの実行期間６２ｃ，６２ｄ，６２ｅが「集計区間２」に含まれる。実行期間６２ａの長さは「１９ｍｓ」、実行期間６２ｂの長さは「９ｍｓ」、実行期間６２ｃの長さ（処理時間）は「１０ｍｓ」、実行期間６２ｄの長さは「１２ｍｓ」、実行期間６１ｅの長さは「２１ｍｓ」である。するとジョブ６２の合計の処理時間は「７１ｍｓ」である。またジョブ６２のジョブ種は「Ａ１」であり、正規化スループット値テーブル１４３ａ（図２３参照）では、１ジョブ当たりの正規化されたスループット値は「１．００」である。正規化されたスループット値で示されるスコア「１．００」が「集計区間１」と「集計区間２」とに含まれる処理時間比率で分配される。すると「集計区間１」のスコアが「０．３９４」（＝１．００×（１９＋９）／７１）、「集計区間２」のスコアが「０．６０６」（＝１．００×（１０＋１２＋２１）／７１）となる。得られたスコアが、Ａｐｐサーバ３００の階層における各集計区間のスループットに加算される。
【０１８９】
次にＤＢサーバ４００の階層におけるスループットの計算例を示す。図１９の例では、ジョブ６３の実行期間は、全体が「集計区間１」に含まれ、処理時間は「９ｍｓ」である。またジョブ６３のジョブ種は「Ｄ１」であり、正規化スループット値テーブル１４３ａ（図２３参照）では、１ジョブ当たりの正規化されたスループット値は「１．００」である。そこで、正規化されたスループット値で示されるスコア「１．００」が、ＤＢサーバ４００の階層における「集計区間１」のスループットに加算される。
【０１９０】
ジョブ６４の実行期間は、図１９の例では、前半の実行期間６４ａが「集計区間１」に含まれ、後半の実行期間６４ｂは「集計区間２」に含まれる。実行期間６４ａの長さ（処理時間）は「１０ｍｓ」であり、実行期間６４ｂの長さは「２４ｍｓ」である。するとジョブ６４の合計の処理時間は「３４ｍｓ」である。またジョブ６４のジョブ種は「Ｄ２」であり、正規化スループット値テーブル１４３ａ（図２３参照）では、１ジョブ当たりの正規化されたスループット値は「３．７２」である。正規化されたスループット値で示されるスコア「３．７２」が、「集計区間１」と「集計区間２」とに含まれる処理時間比率で分配される。すると「集計区間１」のスコアが「１．０９」（＝３．７２×１０／３４）、「集計区間２」のスコアが「２．６３」（＝３．７２×２４／３４）となる。得られたスコアが、ＤＢサーバ４００の階層における各集計区間のスループットに加算される。
【０１９１】
ジョブ６５の実行期間は、図１９の例では、全体が「集計区間２」に含まれ、処理時間は「８ｍｓ」である。またジョブ６５のジョブ種は「Ｄ３」であり、正規化スループット値テーブル１４３ａ（図２３参照）では、１ジョブ当たりの正規化されたスループット値は「０．７９６」である。そこで、正規化されたスループット値で示されるスコア「０．７９６」が、ＤＢサーバ４００の階層における「集計区間２」のスループットに加算される。
【０１９２】
ジョブ６６の実行期間は、図１９の例では、全体が「集計区間２」に含まれ、処理時間は「７ｍｓ」である。またジョブ６６のジョブ種は「Ｄ４」であり、正規化スループット値テーブル１４３ａ（図２３参照）では、１ジョブ当たりの正規化されたスループット値は「３．１９」である。そこで、正規化されたスループット値で示されるスコア「３．１９」が、ＤＢサーバ４００の階層における「集計区間２」のスループットに加算される。
【０１９３】
以上よりＤＢサーバ４００の階層における「集計区間１」のスループットは、ジョブ６３に基づくスコアと、ジョブ６４の実行期間６４ａに基づくスコアとの合計となり、「２．０９」となる。またＤＢサーバ４００の階層における「集計区間２」のスループットは、ジョブ６４の実行期間６４ｂに基づくスコア、および２つのジョブ６５，６６それぞれに基づくスコアの合計となり、「６．６１６」となる。
【０１９４】
図２０に示したように、複数の業務処理が並列実行されている場合は、階層ごとに、各集計区間において、各業務処理に関するジョブによるスコアの総和が求められ、得られた総和が、各階層の集計区間ごとのスループットとなる。
【０１９５】
このようなスループットを集計区間ごとに求めることで、スループットの時系列推移が得られる。
図２４は、スループットの時系列推移の一例を示す図である。図２４では、ＤＢサーバ４００の階層におけるスループットの時系列推移をグラフで表している。図２４に示したグラフは、横軸が時刻、縦軸がスループットである。横軸の１目盛が各集計区間に対応する。
【０１９６】
＜＜多重度計算＞＞
次に多重度計算処理について詳細に説明する。第２の実施の形態における多重度は、その集計区間内で、平均すると同時に何件のジョブが同時に実行されていたかを示す値である。この多重度は、次の式で求めることができる。
多重度＝集計区間内での全てのジョブの処理時間の合計÷集計区間の長さ
最下位の階層以外の階層における多重度の計算では、「ジョブの処理時間」には、その階層において処理が行われている時間だけを含め、他の階層へ処理を送ってから返信を待っている間の時間は含めない。
【０１９７】
図１９の例を用い、多重度の計算例を示す。Ｗｅｂサーバ２００の階層の「集計区間１」の多重度は「０．１４」（＝１４／１００）、「集計区間２」の多重度は「０．１１」（＝１１／１００）である。Ａｐｐサーバ３００の階層の「集計区間１」の多重度は「０．２８」（＝（１９＋９）／１００）、「集計区間２」の多重度は「０．４３」（＝（１０＋１２＋２１）／１００）である。ＤＢサーバ４００の階層の「集計区間１」の多重度は「０．１９」（＝（９＋１０）／１００）、「集計区間２」の多重度は「０．３９」（＝（２４＋８＋７）／１００）である。
【０１９８】
図２０の場合のように、複数の業務処理が並列実行されている場合にも、この計算法は変わらない。すなわち、集計区間に存在する複数の業務処理のジョブを区別することなく、各ジョブの処理時間の総和を計算して、計算された総和を集計区間長で割ればよい。
【０１９９】
このような多重度を集計区間ごとに求めることで、多重度の時系列推移が得られる。
図２５は、多重度の時系列推移の一例を示す図である。図２５では、ＤＢサーバ４００の階層における多重度の時系列推移をグラフで表している。図２５に示したグラフは、横軸が時刻、縦軸が多重度である。横軸の１目盛が各集計区間に対応する。
【０２００】
＜飽和多重度算出＞
次に、飽和多重度算出処理について詳細に説明する。
飽和多重度決定部１４４は、スループットと多重度との関係から、飽和多重度を動的に求める。例えば飽和多重度決定部１４４は、各集計区間について計算されたスループットと多重度とから、両者の関係を求め、多重度の上昇に伴うスループットの上昇が止まる飽和多重度の値を求める。
【０２０１】
多重度の上昇に伴うスループットの上昇が止まる位置があることは、例えば、各集計区間の多重度とスループットとの関係を散布図で表すことで容易に理解できる。
図２６は、多重度とスループットとの関係の一例を示す散布図である。図２６に示した散布図は、横軸（Ｘ軸）に多重度、縦軸にスループットを採っている。そして各集計区間のスループットと多重度とに応じた点を、図中にプロットしている。
【０２０２】
図２６に示した散布図からも分かるように、多重度がある程度の値までは、多重度の上昇に伴ってスループットは上昇するが、それ以降は多重度が上昇してもスループットは上昇しなくなる。飽和多重度決定部１４４は、この境界となる多重度を飽和多重度として求める。
【０２０３】
図２７は、飽和多重度算出処理の一例を示すフローチャートである。以下、図２７に示す処理をステップ番号に沿って説明する。
［ステップＳ１４１］飽和多重度決定部１４４は、多重度の最小値と最大値とを求める。例えば飽和多重度決定部１４４は、現在処理対象となっている階層の集計区間管理テーブルの多重度の欄から、設定されている値の最小値と最大値とを抽出する。
【０２０４】
［ステップＳ１４２］飽和多重度決定部１４４は、多重度の最小値と最大値との間を、等間隔に細分化する。細分化して得られた多重度の細分化区間を、多重度区間とする。ここで各多重度区間内の下限値をその多重度区間の多重度の区間開始値とし、多重度区間内の上限値をその多重度区間の多重度の終了値とする。
【０２０５】
例えば飽和多重度決定部１４４は、多重度の最小値と最大値の間を、所定数（例えば１００）の多重度区間に分割する。なお所定数に分割するのではなく、一定間隔ごと（例えば多重度０．１ごと）に分割してもよい。例えば、最少多重度「０」、最大多重度「５０」であれば、多重度「０」から多重度「５０」の間を０．５刻みで１００分割する。
【０２０６】
［ステップＳ１４３］飽和多重度決定部１４４は、多重度が少ない方から順に多重度区間を選択する。
［ステップＳ１４４］飽和多重度決定部１４４は、選択した多重度区間に含まれる多重度を有する集計区間の平均多重度と、それらの集計区間の平均スループットとを計算する。
【０２０７】
［ステップＳ１４５］飽和多重度決定部１４４は、直前に選択した多重度区間（隣接する多重度区間）との間の、多重度増加に伴うスループットの上昇率（傾き）を計算する。スループットの傾きは、例えば直前に選択した多重度区間との比較における平均スループットの変化量を、直前に選択した多重度区間との比較における平均多重度の変化量で除算した値である。
【０２０８】
ｉ番目に選択された多重度区間の傾きδiの計算を式で表すと、例えば以下のような計算となる。
【０２０９】
【数１】
【０２１０】
［ステップＳ１４６］飽和多重度決定部１４４は、ステップＳ１４５で計算した傾きが、閾値より小さいか否かを判断する。傾きの閾値としては、例えば平均多重度が最も小さな多重度区間の傾きδ1に、１未満の所定の係数を掛けた値（例えば０．２δ1）とする。飽和多重度決定部１４４は、傾きが所定の閾値より小さければ、処理をステップＳ１４９に進める。また飽和多重度決定部１４４は、傾きが所定の閾値以上であれば、処理をステップＳ１４７に進める。
【０２１１】
［ステップＳ１４７］飽和多重度決定部１４４は、未処理の多重度区間があるか否かを判断する。飽和多重度決定部１４４は、未処理の多重度区間があれば、処理をステップＳ１４３に進める。また飽和多重度決定部１４４は、全ての多重度区間の処理が終了していれば、処理をステップＳ１４８に進める。
【０２１２】
［ステップＳ１４８］飽和多重度決定部１４４は、全ての多重度区間において、傾きが閾値以上だった場合、飽和多重度をステップＳ１４１で求められた多重度の最大値に設定し、飽和多重度算出処理を終了する。
【０２１３】
［ステップＳ１４９］飽和多重度決定部１４４は、現在選択している多重度区間の多重度の区間開始値を飽和多重度に決定する。
例えば多重度「０」から多重度「５０」の間を０．５刻みで１００分割した場合において、１＜ｉ≦９の範囲まで傾きが閾値を下回らなかったとする。この場合、１０番目の多重度区間の多重度の範囲「４．５〜５．０」の区間開始値「４．５」（＝０．５×９）が、飽和多重度に決定される。
【０２１４】
このように、分割した多重度が小さな多重度区間から順番に、傾きの値が一定の閾値（例えば０．２δ1）を下回らないかどうかが調べられ、最初に下回るｉが求められる。そして多重度が小さな方からｉ番目の多重度区間の多重度の区間開始値が飽和多重度となる。
【０２１５】
＜ボトルネック判定＞
次に、飽和多重度に基づくボトルネック判定処理について説明する。分析部１４５は、飽和多重度を超えていない集計区間の割合に応じて、各階層の処理能力の余力を算出する。そして分析部１４５は、飽和多重度を超えていない集計区間の割合が所定の値より少ない階層を検出すると、その階層がボトルネックになっていると判断する。
【０２１６】
すなわち、図２６に示した散布図の各ドットは、１つ１つの集計区間に相当する。これらの集計区間の中で、多重度が飽和多重度を下回っていた区間は、その階層の処理能力に余力が残っていたと考えられる。そのような集計区間が、集計区間の総数に占める割合を求め、それを処理能力の余力とする。例えば、１８０秒分の時系列データを同時に処理する場合は、その中には１８００の集計区間が存在する（集計区間長が１００ｍｓの場合）。ここで１８００の集計区間の内の３８５の集計区間で多重度が飽和多重度を下回っていた場合、２１．４％（＝３８５／１８００×１００）の区間で余力を有していたという計算になる。
【０２１７】
例えば、第２の実施の形態では、分析部１４５は、飽和多重度を超えていない集計区間が第１の閾値を下回った場合に、その階層の処理能力の限界を超えた完全飽和状態であると判断する。そして、分析部１４５は、完全飽和状態となった階層をボトルネック原因と判定して報告する。
【０２１８】
また分析部１４５は、飽和多重度を超えていない集計区間の割合が、予め設定した第１の閾値より高い第２の閾値を下回った場合に、その階層は部分的に処理能力の限界を超えている半飽和状態であると判断する。これは、複数の階層が同時に半飽和状態に陥って、多階層システム全体としてはボトルネック状態となっている可能性があるためである。
【０２１９】
以下に、ボトルネック判定処理の手順について説明する。
図２８は、ボトルネック判定処理の手順の一例を示すフローチャートである。以下、図２８に示す処理をステップ番号に沿って説明する。
【０２２０】
［ステップＳ１５１］分析部１４５は、集計区間を１つ選択する。例えば分析部１４５は、処理対象となっている階層に対応する集計区間管理テーブル（図２２参照）の上位から順に、集計区間を選択する。
【０２２１】
［ステップＳ１５２］分析部１４５は、選択した集計区間の多重度が、飽和多重度以下か否かを判断する。分析部１４５は、飽和多重度以下であれば、処理をステップＳ１５３に進める。また分析部１４５は、飽和多重度より大きければ、処理をステップＳ１５４に進める。
【０２２２】
［ステップＳ１５３］分析部１４５は、未飽和区間数をカウントアップする。なお未飽和区間数は、ボトルネック判定処理の開始時に「０」に初期化されている。
［ステップＳ１５４］分析部１４５は、未処理の集計区間があるか否かを判断する。分析部１４５は、未処理の集計区間があれば、処理をステップＳ１５１に進める。分析部１４５は、未処理の集計区間がなければ、処理をステップＳ１５５に進める。
【０２２３】
［ステップＳ１５５］分析部１４５は、集計区間の総数に対する未飽和区間の割合が第１の閾値未満か否かを判断する。第１の閾値は、予め分析部１４５に設定されている。例えば分析部１４５は、未飽和区間数を集計区間の総数で除算し、未飽和区間の割合を求める。そして分析部１４５は、未飽和区間の割合と第１の閾値を比較し、未飽和区間の割合が第１の閾値未満か否かを判断する。分析部１４５は、未飽和区間の割合が第１の閾値未満であれば、処理をステップＳ１５６に進める。また分析部１４５は、未飽和区間の割合が第１の閾値以上であれば、処理をステップＳ１５７に進める。
【０２２４】
［ステップＳ１５６］分析部１４５は、現在の処理対象となっている階層が、ボトルネック要因であると判定する。分析部１４５は、例えば判定結果をモニタ１１などに出力する。その後、ボトルネック判定処理が終了する。
【０２２５】
［ステップＳ１５７］分析部１４５は、集計区間の総数に対する未飽和区間の割合が第２の閾値未満か否かを判断する。第２の閾値は、第１の閾値より大きな値であり、予め分析部１４５に設定されている。分析部１４５は、未飽和区間の割合が第２の閾値未満であれば、処理をステップＳ１５８に進める。また分析部１４５は、未飽和区間の割合が第２の閾値以上であれば、ボトルネック判定処理を終了する。
【０２２６】
［ステップＳ１５８］分析部１４５は、現在の処理対象となっている階層が、複合的なボトルネック要因の候補であると判定する。複合的なボトルネック要因とは、他の階層との複合的要因によって発生しているボトルネックである。分析部１４５は、例えば判定結果をモニタ１１などに出力する。その後、ボトルネック判定処理が終了する。
【０２２７】
このようにして、処理能力が残存していた集計区間（未飽和の集計区間）の割合に応じて、その階層が、多階層システムのボトルネックになっているかどうかを判定することができる。
【０２２８】
以下、図２９〜図３２を参照し、各階層のサーバの余力と、未飽和区間の割合との関係について説明する。
図２９は、階層が完全未飽和状態の一例を示す散布図である。階層が完全未飽和状態であるとは、負荷が非常に低くて、どの集計区間においても多重度が飽和多重度を超えていない状態である。図２９に示したように多重度が低い集計区間しかない場合には飽和多重度が求まらないことがある。すなわち図２７に示した処理において、全ての多重度区間において、傾きの大きさが閾値以上になることがある。このように、全ての多重度区間において、傾きの大きさが閾値以上となった場合、完全未飽和状態と判定できる。この場合、例えば分析部１４５は、分析対象の階層が完全未飽和状態であることを示す情報を出力する。
【０２２９】
図３０は、階層が未飽和状態の一例を示す散布図である。階層が未飽和状態であるとは、多重度が飽和多重度以下の集計区間の割合が、第２の閾値以上の状態である。例えば第１の閾値が「０．２」（２０％）、第２の閾値が「０．７」（７０％）の場合、多重度が飽和多重度以下の集計区間の割合が７０％以上の階層は、未飽和状態と判定される。この場合、例えば分析部１４５は、分析対象の階層が未飽和状態であることを示す情報を出力する。
【０２３０】
図３１は、階層が半飽和状態の一例を示す散布図である。階層が半飽和状態であるとは、多重度が飽和多重度以下の集計区間の割合が、第１の閾値以上、第２の閾値未満の状態である。半飽和状態の階層は、部分的に処理能力の限界を超えているものと考えられる。これは、複数の階層が同時に半飽和状態に陥って、多階層システム全体としてはボトルネック状態となっている可能性があるためである。例えば第１の閾値が「０．２」（２０％）、第２の閾値が「０．７」（７０％）の場合、多重度が飽和多重度以下の集計区間の割合が２０％以上、且つ７０％未満の階層は、半飽和状態と判定される。この場合、例えば分析部１４５は、分析対象の階層が半飽和状態（部分的ボトルネック）であることを示す情報を出力する。
【０２３１】
図３２は、階層が飽和状態の一例を示す散布図である。階層が飽和状態であるとは、多重度が飽和多重度以下の集計区間の割合が、第１の閾値未満の状態である。飽和状態の階層は、多階層システムにおけるボトルネックになっていると考えられる。例えば第１の閾値が「０．２」（２０％）の場合、多重度が飽和多重度以下の集計区間の割合が２０％未満の階層は、飽和状態と判定される。この場合、例えば分析部１４５は、分析対象の階層が飽和状態（ボトルネック）であることを示す情報を出力する。
【０２３２】
以上説明したように、第２の実施の形態では、精密なメッセージ送受時刻の記録から、各階層における処理の多重度とスループットを算出し、その関係を動的に求め、そこからボトルネック判定を行う。これにより、ボトルネックの判定を適切に行うことができる。
【０２３３】
すなわち、第２の実施の形態では、最初に、分析対象期間が短い時間間隔の集計区間に細分化され、それぞれの集計区間から各階層における処理多重度とスループットが計算される。こうして得られた集計区間ごとの多重度とスループットとの組から両者の関係が求められ、処理多重度が増加しているのにスループットが増加しなくなる多重度の値（飽和多重度と呼ぶ）を動的に求められる。そして、細分化された各集計区間の中で、多重度がその飽和多重度を超えていた区間の割合を求めることによって、各階層が余力を有しているかどうかが判定される。
【０２３４】
このような判定は、各階層で動くサーバは、そのハードウェアやＯＳやソフトウェア実装の制限によって、同時に実行できるジョブ数（並列度）が限られており、並列度が一定の値に達すると、それ以上はスループットが上昇しなくなるという現象に基づいている。
【０２３５】
また第２の実施の形態では、多重度とスループットの両者の関係でボトルネック発生を判定するので、ボトルネックの発生原因が何であるかに関係なく、ボトルネックが発生していることを検出できる。すなわち、ソフトウェアの多重度制限以外の原因でボトルネックが発生している場合あっても、特定の階層でボトルネックが発生していることを検出できる。
【０２３６】
多階層システム中のある階層のスループットが限界を迎える飽和多重度に影響を及ぼす原因は様々である。例えば飽和多重度は、ソフトウェア実装やジョブ種ごとの処理内容によって、使用するハードウェア資源の種類や量が異なることや、各レベル（ＯＳやソフトウェア内部）で行われるキューイングの影響を受ける。また、ジョブ種の混合率の変化に伴って、運用中に飽和多重度が動的に変わることも考えられる。このように、飽和多重度に影響を及ぼす要因を、外部からのＩＰパケットのキャプチャを観測によって、事前に知ることが非常に困難である。第２の実施の形態では、多重度とスループットとの関係からボトルネックの有無を判定するため、飽和多重度に影響を及ぼすサーバの内部要因に関する情報を用いずに、ボトルネックの判定を可能としている。
【０２３７】
例えば、個々のシステムリソースは枯渇していないのに、システム全体としては入力仕事量を増やしても性能（出力仕事量）が伸びなくなっている状態についても、その要因となっている階層（サーバ）を特定することが可能である。このような現象は、１つの階層の中において、複数の要因が複合してボトルネックを引き起こしている場合に発生する。複合的な要因には、ハードウェア・ＯＳ・ソフトウェア・ユーザアプリケーションなど全てを含むため、全ての階層において要因となるリソースを個別に分析して、さらに関係を分析すると、関係が複雑になりすぎ、正確な判断が難しい。第２の実施の形態では、各階層の多重度とスループットとの関係から、ボトルネックの要因を内在している階層を特定できるため、ボトルネックの発生要因となっているリソースを特定する作業の負担が軽減される。
【０２３８】
また第２の実施の形態では、非常に短い時間の集計区間における多重度とスループットとに基づいて、各階層の余力を判定するため、極めて短時間に発生するボトルネックであっても検出可能である。例えば、図３１の例であれば、サーバ単体での継続したボトルネックとはなっていないものの、飽和多重度を超えた多重度の集計区間が存在していることが分かる。このような集計区間は、瞬間的にボトルネックを生じさせている可能性がある。その結果、例えば、複数の階層間で、極短時間でボトルネック位置が推移し、システム全体としては入力仕事量を増やしても性能が伸びなくなっている状態において、その複数階層間でのボトルネック位置推移と、各階層の影響度合いを検出できる。
【０２３９】
〔第３の実施の形態〕
次に第３の実施の形態について説明する。第３の実施の形態は、集計区間のスループットの算出において、間接的な外部資源待ち時間を、処理時間から除外するものである。なお、第３の実施の形態を実現するシステム構成は第２の実施の形態と同様である。そこで、図４や図６に示した第２の実施の形態の各要素を用いて第３の実施の形態の機能を説明する。
【０２４０】
多階層システムにおいて、多重度とスループットの関連性から、システム性能の飽和度合いを測ろうとすると、この関連性を壊す要因が存在する。そのような要因の１つとして、ソフトウェアの実装によっては、階層間のメッセージ送受におけるレスポンスメッセージ待ちという直接的な待ち時間以外に、間接的に階層外部の資源を待っている時間が存在することがある。
【０２４１】
図３３は、多重度とスループットの関連性を壊す要因の一例を示す図である。例えば図３３の場合は、Ａｐｐサーバ３００上で動くアプリケーションがＤＢサーバ４００と通信するためＤＢコネクションを内部で一定量確保（プール）しておき、そのＤＢコネクションを使い回すという実装がなされていた場合に起こるケースである。なお、このような実装方法は、ＤＢコネクションプールという一般的な実装方法である。
【０２４２】
例えば、プールしてある上限までＤＢコネクションを使い切ってしまった場合、次の処理が行われる。Ａｐｐサーバ３００においてＤＢコネクションを新たに必要とするスレッドは、他のＤＢコネクションを使用しているスレッドが処理を終えてＤＢコネクションをプールへ解放するのを待つ。もし他のスレッドがＤＢサーバからの応答を待っていて処理が進まない場合は、これは間接的にＤＢサーバ４００の応答を待っていることになる。特に、ＤＢサーバ４００がボトルネックとなった場合においては、ＤＢサーバ４００の応答時間が指数関数的に増加するので、Ａｐｐサーバ３００において空きＤＢコネクションを待つ時間は極端に増加する（図３３の網掛け部分）。
【０２４３】
Ａｐｐサーバ３００における待ち時間は、外部資源を待っている時間なので、Ａｐｐサーバ３００のスループットや多重度の計算においては、本来はＡｐｐサーバ３００の処理時間からは省かれるべき時間である。しかし、外部観測においては、そのようなアプリケーション内部での、間接的な外部資源の待ち時間を測定する手段がない。
【０２４４】
同様のことは、Ｗｅｂサーバ２００やＡｐｐサーバ３００の空きスレッド待ちでも発生する。一般的に、Ｗｅｂサーバ２００やＡｐｐサーバ３００では、同時に使用できるスレッド数の上限を定めていて、使用されているスレッド数が上限に達すると、それ以降に到着したリクエストは空きスレッドができるのを待つことになる。下位の階層からレスポンスが遅延によりスレッドが空くのが遅れると、空きスレッドの待ち時間には、間接的にはさらに下位の階層のレスポンスを待っている時間が含まれることになる。特に下位の階層でボトルネックが発生しているときには、空きスレッドの待ち時間が非常に大きな待ち時間となる。
【０２４５】
このような間接的な外部資源待ち時間を含めてスループットと多重度とを計算すると、多重度を非常に大きな値にしてしまい、多重度とスループットの関連性を壊してしまう。そこで、第３の実施の形態では、間接的な外部資源待ち時間による悪影響を取り除くため、間接的な外部資源待ち時間が発生すると予め分かっている実行期間については、常にその実行期間を削除して、多重度とスループットを計算する。間接的な外部資源待ち時間が発生すると予め分かっている実行期間は、例えば、最下位の階層以外の階層における同一ジョブ内の最初の実行期間である。図３３の例では、網掛けで示されたＡｐｐサーバ３００における最初の実行期間全体を、多重度とスループットとの計算に使用する情報から削除する。もちろん、この方法では、その区間に含まれている、取り除く必要のない、その階層での処理時間も同時に取り除かれてしまい、その長さの分だけ誤差が発生する。それでも多重度とスループットの両方が低下するだけなので、本性能分析手法全体としては、影響は無視できる。
【０２４６】
第３の実施の形態は、第２の実施の形態のスループット計算処理（図２１のステップＳ１３２）と、多重度計算処理（図２１のステップＳ１３３）との処理を変更することで実現できる。変更内容は以下の通りである。
【０２４７】
＜スループット計算＞
集計部１４１は、スループットを算出する際に、各ジョブの最初の実行期間の長さを処理時間から除算する。例えば、図１９に示した例であれば、Ｗｅｂサーバ２００の「集計区間１」のスループットの計算において、ジョブ６１の実行期間６１ａは、ジョブ６１の実行期間から除外される。同様に、Ａｐｐサーバ３００の「集計区間１」のスループットの計算において、ジョブ６２の実行期間６２ａは、ジョブ６２の実行期間から除外される。
【０２４８】
なお、１つのジョブの実行が複数の集計区間に跨る場合は、それぞれの集計区間の中における処理時間の比率に応じて、先のスコアを各集計区間へ配分するが、この際にも、ジョブの先頭の実行期間は除外してスループットの配分が計算される。
【０２４９】
＜多重度計算＞
集計部１４１は、多重度を算出する際に、各ジョブの最初の実行期間の長さを、多重度算出時の処理時間から除外する。
【０２５０】
このように第３の実施の形態では、間接的な外部資源待ち時間を含む実行期間を、スループットと多重度との計算に用いないようにしたことで、間接的な外部資源待ちの影響を除去することができる。
【０２５１】
これによって、間接的な外部資源待ちの時間が、その階層上での処理時間として誤って算入されることを防ぐことができ、その影響で多重度とスループットの関係が不正確になることを防止することができる。特に、システム全体の処理性能が飽和しかかった状態では、このような間接的な外部資源待ち（ボトルネック階層の処理待ち）時間が急激に大きくなり、本来の処理時間よりも遥かに大きくなることは珍しくない。この間接的な外部資源待ち時間は、スループットは小さくする方向に働くのに対し、多重度に関してはその値を急激に高めるように働く。そのため、間接的な外部資源待ちの時間の影響が残存していると、スループットと多重度との関係が不正確となる。
【０２５２】
図３４は、間接的な外部資源待ち時間を除外しない場合の各集計区間のスループットと多重度との一例を示す散布図である。なお図３４の例は、間接的な外部資源待ち時間が発生したＡｐｐサーバ３００の階層のスループットと多重度とを計算したものである。図３４の例では、高い多重度の集計区間が多数存在することが分かる。
【０２５３】
図３４のスループットと多重度との計算の元となった時系列データを用い、間接的な外部資源待ち時間を除外してスループットと多重度とを再計算すると、図３５のようになる。
【０２５４】
図３５は、間接的な外部資源待ち時間を除外した場合の各集計区間のスループットと多重度との一例を示す散布図である。図３５の例では、図３４と比較して、多重度が非常に低くなっていることが分かる。このように、間接的な外部資源待ち時間を除外することで、各集計区間の多重度は少なくなる。
【０２５５】
第３の実施の形態のように、間接的な外部資源待ちの時間の影響を抑止すれば、間接的な外部資源待ち時間が存在する状況においても、その待ち時間によりスループットや多重度の正確性が低下することを抑止できる。すなわち、性能分析の正確性を向上させることができる。
【０２５６】
〔第４の実施の形態〕
次に第４の実施の形態について説明する。第４の実施の形態は、ジョブの処理数に変えて、出力メッセージ数を用いてスループットを計算するものである。なお、第４の実施の形態を実現するシステム構成は第２の実施の形態と同様である。そこで、図６に示した第２の実施の形態の各要素を用いて第４の実施の形態の機能を説明する。
【０２５７】
Ａｐｐサーバ３００などのサーバでは、Ｊａｖａ（登録商標） ＶＭ（virtual machine）がＦｕｌｌガーベージコレクション（以下「Ｆｕｌｌ−ＧＣ」と呼ぶ）を起こすことがある。ガーベージコレクションは、プログラムが動的に確保したヒープ（動的に確保可能なメモリ領域）上のメモリ領域のうち、不要になった領域を自動的に解放する処理である。Ｆｕｌｌ−ＧＣの場合、Ｆｕｌｌ−ＧＣ以外の全ての処理が、瞬間的に停止する。ジョブの実行が開始されてから終了するまでの間に、Ｆｕｌｌ−ＧＣによりジョブが停止する期間が含まれていると、ジョブの挙動を正確に検出することができないことがある。なぜならば、Ａｐｐサーバ３００上でＦｕｌｌ−ＧＣのためにジョブが瞬間停止させられると、その時間はＡｐｐサーバ３００外からの外部観測では、あたかもそのＡｐｐサーバ３００上での処理が継続しているかのように観測されてしまう。その結果、第２の実施の形態の方法では、実際にはジョブの停止期間であるにも拘わらず、その停止期間を実行期間と判断して、スループットや多重度が計算される。
【０２５８】
図３６は、Ｆｕｌｌ−ＧＣによる停止期間が発生した場合の一連の業務処理を示す図である。図３６の例では、Ｗｅｂサーバ２００のジョブ９１からのリクエストメッセージに応じてＡｐｐサーバ３００でジョブ９２が実行されている。Ａｐｐサーバ３００のジョブ９２は、ＤＢサーバ４００に対してリクエストメッセージを４回送信している。ＤＢサーバ４００では、Ａｐｐサーバ３００からのリクエストメッセージに応じて、４つのジョブ９３〜９６が実行されている。Ｗｅｂサーバ２００が実行したジョブ９１には、２つの実行期間９１ａ，９１ｂが含まれる。Ａｐｐサーバ３００が実行したジョブ９２には、５つの実行期間９２ａ，９２ｂ，９２ｃ，９２ｄ，９２ｅが含まれる。
【０２５９】
ここで、Ａｐｐサーバ３００では、実行期間９２ｃにおいて、Ｆｕｌｌ−ＧＣが発生したものとする。Ｆｕｌｌ−ＧＣが行われると、ジョブ９２の処理は停止するため、実行期間９２ｃは、実際にＡｐｐサーバ３００がジョブ９２の処理に費やした時間よりも長い処理時間となる。
【０２６０】
図３６に示した様な挙動は、多階層システム全体として考えると、Ｆｕｌｌ−ＧＣが発生した一瞬だけ、Ａｐｐサーバ３００の階層がボトルネックになっていると見做すことができる。第４の実施の形態では、そのような瞬間的なボトルネック発生を検出可能とする。そのために第４の実施の形態では、スループットを、その階層が出力するメッセージ数によって換算する。この出力メッセージには、下位の階層に送るリクエストも上位の階層へ返すレスポンスも含まれる。この出力メッセージ数を、ジョブ種間の差異を考慮して、各ジョブ種の低負荷時の処理時間に比例し、各ジョブ種のジョブ１つ当たりの平均出力メッセージ数に反比例するように正規化する。
【０２６１】
スループットの計算方法を置き換えたことで、１ジョブ当たりの正規化スループット値も、第２の実施の形態と異なる値となる。
図３７は、第４の実施の形態における正規化スループット値記憶部のデータ構造の一例を示す図である。正規化スループット値記憶部１４３には、正規化スループット値テーブル１４３ｂが格納されている。正規化スループット値テーブル１４３ｂには、ジョブ種、低負荷時の平均処理時間、平均出力メッセージ数、および正規化されたスループット値の欄が設けられている。
【０２６２】
ジョブ種の欄には、Ｗｅｂ三階層システムのいずれかのサーバで実行されるジョブのジョブ種名が設定される。
低負荷時の平均処理時間の欄には、対応するジョブ種のジョブを、サーバが低負荷時に実行した場合の平均処理時間が設定される。図３７の例では、低負荷時の平均処理時間の欄に、「ｍｓ」単位の数値が設定されている。低負荷時の平均処理時間は、例えば、システムの管理者が、予めＷｅｂ三階層システムの負荷が少ない状態で計測し、正規化スループット値テーブル１４３ｂに設定する。
【０２６３】
平均出力メッセージ数の欄には、対応するジョブ種のジョブが出力するメッセージ数の平均値である。このメッセージ数には、リクエストメッセージとレスポンスメッセージとの両方がカウントされる。
【０２６４】
正規化されたスループット値の欄には、各ジョブ種の１メッセージ当たりの処理時間を正規化したスループット値が設定される。例えば階層ごとに、代表ジョブ種が１つずつ選択される。図３７の例では、Ｗｅｂサーバ２００で実行されるジョブ種に関しては、ジョブ種名「Ｗ１」のジョブ種が、代表ジョブ種である。Ａｐｐサーバ３００で実行されるジョブ種に関しては、ジョブ種名「Ａ１」のジョブ種が、代表ジョブ種である。ＤＢサーバ４００で実行されるジョブ種に関しては、ジョブ種名「Ｄ１」のジョブ種が、代表ジョブ種である。各階層の代表ジョブ種に関しては、１メッセージ当たりの正規化されたスループット値は、「１．００」を平均出力メッセージ数で除算した値である。例えばＷｅｂサーバ２００の代表ジョブ種であるジョブ種「Ｗ１」は、平均出力メッセージ数が「２」であるため、正規化されたスループット値は、「０．５」（＝１／２）となる。
【０２６５】
代表ジョブ種以外のジョブ種に関しては、低負荷時における代表ジョブ種との平均処理時間の比率を、さらに各ジョブ種の平均出力メッセージ数で割った値が、各ジョブ種のジョブが発行するメッセージ１回あたりの正規化されたスループット値となる。例えばＷｅｂサーバ２００の階層のジョブ種「Ｗ２」は、低負荷時の平均処理時間が、代表ジョブ種（ジョブ種名「Ｗ１」）の平均処理時間の０．６０４倍（１３．４ｍｓ／２２．２ｍｓ）である。この比率「０．６０４」を、ジョブ種「Ｗ２」の平均出力メッセージ数「２．００」で除算した値「０．３０２」が、ジョブ種名「Ｗ２」のジョブ種の１メッセージ当たりの正規化されたスループット値となる。
【０２６６】
第４の実施の形態では、第２の実施の形態のスループット計算処理（図２１のステップＳ１３２）に代えて、図３７に示したジョブ種ごとの１メッセージ当たりの正規化されたスループット値を用いて、集計区間ごとのスループットが計算される。
【０２６７】
図３６に示した業務処理に基づいてスループットを計算すると以下のようになる。
Ｗｅｂサーバ２００の階層の場合は、「集計区間１」のスループットはジョブ種「Ｗ１」のジョブ９１が発行したメッセージ１回分の値「０．５００」である。「集計区間２」のスループットは「０」である。「集計区間３」のスループットは、ジョブ種「Ｗ１」のジョブ９１が発行したメッセージ１回分の値「０．５００」である。
【０２６８】
Ａｐｐサーバ３００の階層の場合は、「集計区間１」のスループットは、ジョブ種「Ａ１」が発行したメッセージ２回分の値「０．４１２」（＝０．２０６×２）である。「集計区間２」のスループットは、発行したメッセージが一つもないので「０」となる。「集計区間３」のスループットは、ジョブ種「Ａ１」のジョブ９２が発行したメッセージ３回分の値「０．６１８」（＝０．２０６×３）である。この３回の内の２回は下位のＤＢサーバ４００に対して送信したリクエストメッセージで、残りの１回は上位のＷｅｂサーバ２００に返信したレスポンスメッセージである。
【０２６９】
ＤＢサーバ４００の階層の「集計区間１」のスループットは、ジョブ種「Ｄ１」のジョブ９３が発行したメッセージ１回分の値「１．００」である。「集計区間２」のスループットは、ジョブ種「Ｄ２」のジョブ９４が発行したメッセージ１回分の値「３．７２」である。「集計区間３」のスループットは、ジョブ種「Ｄ３」の２つのジョブ９５，９６が発行したメッセージ２回分の値「１．５９」（＝０．７９６×２）である。
【０２７０】
なお、複数の業務処理が並列実行されている場合は、第２の実施の形態と同様に、階層ごとに、上記のようにして計算されたスループットの集計区間ごとの総和が計算される。そして、計算された総和が、各集計区間のスループットになる。
【０２７１】
このようにスループットを計算することによって、「集計区間２」におけるジョブ９２の実行期間９２ｃのように、実質的な処理とは無関係に時間が長くなっている区間にスループット値が割り当てられることを抑止できる。すなわち、瞬間的な挙動停止があると、停止期間はメッセージ出力が行われないため、スループット値の換算も「０」となる。これは、ジョブの処理がサーバで実際に実行されている時間のみを、正しくスループットとして換算できることを意味する。
【０２７２】
その結果として、Ｆｕｌｌ−ＧＣの発生などにより瞬間的にボトルネックとなっている集計区間を、正確に判別できるようになる。以下、図３８と図３９とを参照し、１ジョブ当たりの正規化スループット値に基づいてスループットを計算した場合と、１メッセージ当たりの正規化スループット値に基づいてスループットを計算した場合との違いを説明する。
【０２７３】
図３８は、１ジョブ当たりの正規化スループット値に基づいてスループットを計算した場合の散布図である。図３８の例は、Ａｐｐサーバ３００においてＦｕｌｌ−ＧＣが発生した期間を分析対象期間として、第２の実施の形態の手法でスループットを計算したものである。図３８のような多重度とスループットとの関係では、Ｆｕｌｌ−ＧＣによる瞬間的なボトルネックの発生が認識できない。
【０２７４】
図３９は、１メッセージ当たりの正規化スループット値に基づいてスループットを計算した場合の散布図である。図３９の例は、図３８のスループット計算時と同じ時系列データを用いて、第４の実施の形態の手法でスループットを計算したものである。
【０２７５】
このように第４の実施の形態でスループットを計算すると、瞬間的な挙動停止が直接的にスループットに反映される。そのためＦｕｌｌ−ＧＣが発生してスループットが完全に０になっていたり大きく落ち込んでいたりする集計区間が多数あることがグラフ上で明確に表されている。図３９では、楕円９９内の集計区間が、Ｆｕｌｌ−ＧＣなどによって引き起こされた異常な瞬間スループット低下が発生した集計区間である。
【０２７６】
このような瞬間スループット低下が発生した集計区間は、例えば分析部１４５が、多重度が飽和多重度を超えていながら、スループットが所定値以下の集計区間を集計区間情報記憶部１４２から検索することで、検出することができる。また分析部１４５が、図３９に示したような散布図をモニタ１１に表示し、管理者に瞬間スループット低下の発生を認識させることもできる。
【０２７７】
なお図３９に示した例では全体的にスループットのバラつきが大きくなっているが、これは、Ｆｕｌｌ−ＧＣ以外にもマイナーなガーベージコレクションが頻繁に発生しており、それがスループットを瞬間的に細かく上下させているためであると考える。
【０２７８】
また、例えば、ジョブ種が一種類の場合などには、スループットの正規化を行わなくてもよい。その場合、例えば、集計区間内に出力したメッセージ数を、スループットとする。また、ジョブ全体で出力されるメッセージ数のうち、集計区間内に出力したメッセージ数を、スループットとすることもできる。
【０２７９】
〔第５の実施の形態〕
次に第５の実施の形態について説明する。第５の実施の形態は、データのばらつきの影響を抑止した手法で、飽和多重度を求めるものである。なお、第５の実施の形態を実現するシステム構成は第２の実施の形態と同様である。そこで、図６に示した第２の実施の形態の各要素を用いて第５の実施の形態の機能を説明する。
【０２８０】
図２７に示した第２の実施の形態の飽和多重度算出手法では、データに細かなバラつきがある場合にそれに影響されて、傾きが早い時点で一時的に閾値を下回り、飽和多重度を小さな値に誤判定してしまう可能性がある。そこで第５の実施の形態では、飽和多重度をより正確に求めることができる手法で、飽和多重度を算出する。
【０２８１】
第５の実施の形態で採用した手法は、統計的な信頼区間を用いる。信頼区間とは、ある数がどのような数値の範囲にあるかを確率的に示すものである。多階層システムの性能分析においては、ある階層のサーバにおける多重度の値が低い時は、多重度とスループットは正比例に近い関係で、両者の傾きの値の分散は小さい。他方、その階層のサーバの処理能力が限界（ボトルネック）に近づいた時点で、両者の関係が急激に崩れ、分散が大きくなる。このように分散が大きくなると、傾きの値の統計的信頼区間が広がるという特徴がある。第５の実施の形態は、信頼区間のこのような特徴を利用することによって、データの細かなバラつきに影響されずに、飽和多重度を求めることを可能とする。
【０２８２】
図４０は、第５の実施の形態における飽和多重度算出処理の一例を示すフローチャートである。以下、図４０に示す処理をステップ番号に沿って説明する。なお図４０におけるステップＳ２０１〜ステップＳ２０５の処理は、それぞれ図２７に示した第２の実施の形態におけるステップＳ１４１〜ステップＳ１４５の処理と同じである。そこで、ステップＳ２０６以降の処理について説明する。なお、ステップＳ２０２の処理では、多重度の最小値「０」と最大値「５０」との間が、０．５刻みで１００分割されているものとする。
【０２８３】
［ステップＳ２０６］飽和多重度決定部１４４は、傾きの分布の統計的な信頼区間を計算する。例えば飽和多重度決定部１４４は、隣接する多重度区間の間で、両者の平均多重度と平均スループットの変化量から、変化量の傾きδiを、図２７のステップＳ１４５と同様の式（１）で求める。
【０２８４】
さらに飽和多重度決定部１４４は、分割した多重度区間の小さな方から順にｎk（ｎkは、１＜ｎk≦１００の範囲の整数）個の区間について、先に求めた傾きを使って、その統計上の信頼区間を以下の式で計算する。
【０２８５】
【数２】
【０２８６】
ここで、１．９６は９５％信頼区間の定数である。
［ステップＳ２０７］飽和多重度決定部１４４は、信頼区間の下限が所定の閾値より低いか否かを判断する。信頼区間の下限に関する閾値としては、例えば平均多重度が最も小さな多重度区間の傾きδ1に、１未満の所定の係数を掛けた値（例えば０．２δ1）とする。飽和多重度決定部１４４は、信頼区間の下限が閾値より低ければ、処理をステップＳ２１０に進める。また飽和多重度決定部１４４は、信頼区間の下限が閾値以上であれば、処理をステップＳ２０８に進める。
【０２８７】
［ステップＳ２０８］飽和多重度決定部１４４は、未処理の多重度区間があるか否かを判断する。飽和多重度決定部１４４は、未処理の多重度区間があれば、処理をステップＳ２０３に進める。また飽和多重度決定部１４４は、未処理の多重度区間がなければ、処理をステップＳ２０９に進める。
【０２８８】
［ステップＳ２０９］飽和多重度決定部１４４は、全ての多重度区間において、信頼区間の下限が閾値以上だった場合、飽和多重度をステップＳ２０１で求められた多重度の最大値に設定し、飽和多重度算出処理を終了する。
【０２８９】
［ステップＳ２１０］飽和多重度決定部１４４は、現在選択している多重度区間の多重度の区間開始値を飽和多重度に決定する。
このような処理により、式（２）で求めた信頼区間の下限が、予め定めておいた閾値を最初に下回るｎkが求められ、そのときの多重度区間の区間開始値が飽和多重度となる。例えば、多重度「０」から多重度「５０」の間を０．５刻みで１００分割した場合において、１＜ｎk≦９の範囲まで信頼区間の下限が閾値を下回らず、ｎk＝１０のときに初めて信頼区間の下限が閾値より低くなったものとする。この場合、１０番目の多重度区間の多重度の範囲「４．５〜５．０」の区間開始値「４．５」（＝０．５×９）が、飽和多重度に決定される。
【０２９０】
このように、第５の実施の形態では、分割した多重度区間の小さな方から順に、先に求めた傾きを加えていきながら、その統計上の信頼区間が計算され、その信頼区間の下限が、予め定めておいた閾値を下回った時点で、そのときの多重度が飽和多重度とされる。これにより、傾きの局所的なバラつきに影響されずに、多重度とスループットの関係が変化する飽和多重度を機械的に求めることが可能となる。
【０２９１】
例えば、第２の実施の形態における飽和多重度算出処理（図２７参照）では、傾きをそのまま多重度が小さい方から比較していき、傾きが変化する多重度を求めている。この場合、同種ジョブ間でも個々のジョブ間でのハードウェア資源消費量のバラつきが存在するので、求めた傾きが上下に振れてしまって、傾きが変化する多重度の位置を誤検出してしまう可能性がある。他方、図４０に示した第５の実施の形態の飽和多重度算出処理では、傾きの値の統計上の信頼区間を算出していき、その下限が閾値を超えるかどうかという判定基準によって飽和多重度を決定する。その結果、局所的な傾きのバラつきに影響されることなく、多重度とスループットの関係が変化する飽和多重度を求めることができる。
【０２９２】
〔第６の実施の形態〕
次に第６の実施の形態について説明する。第６の実施の形態は、各階層の残存処理能力を算出するものである。残存処理能力を算出することで、例えば各階層の最大処理能力の見積もり（キャパシティプランニング）が可能となる。なお、第６の実施の形態を実現するシステム構成は第２の実施の形態と同様である。そこで、図６に示した第２の実施の形態の各要素を用いて第６の実施の形態の機能を説明する。
【０２９３】
例えば図２８に示した第２の実施の形態のボトルネック判定処理では、多重度が飽和多重度以下の集計区間（未飽和区間）の割合が算出されている。未飽和区間は、処理能力の余力が残っている集計区間である。第６の実施の形態では、さらにその階層の処理能力の余力（限界処理能力に対する残存処理能力の割合）を求める。
【０２９４】
第６の実施の形態における集計区間情報記憶部１４２は、各集計区間が未飽和区間に該当するか否かのフラグを記憶することができる。
図４１は、第６の実施の形態の集計区間情報記憶部のデータ構造の一例を示す図である。集計区間情報記憶部１４２には、階層ごとの集計区間管理テーブル１４２ｄ，１４２ｅ，１４２ｆが格納されている。例えば集計区間管理テーブル１４２ｄは、ＤＢサーバ４００の階層に対応する。
【０２９５】
集計区間管理テーブル１４２ｄには、集計区間、期間、スループット、多重度、および未飽和区間フラグの欄が設けられている。集計区間の欄には、集計区間の名称が設定される。期間の欄には、集計区間の期間が設定される。スループットの欄には、集計区間のスループットが設定される。多重度の欄には、集計区間の多重度が設定される。未飽和区間フラグの欄には、集計区間が未飽和区間に該当するか否かを示すフラグ（未飽和区間フラグ）が設定される。例えば、集計区間が未飽和区間であれば、未飽和区間フラグの値に「１」が設定される。また集計区間が未飽和区間でなければ、未飽和区間フラグの値に「０」が設定される。なお未飽和区間フラグの初期値は、未飽和区間ではないことを示す値「０」であるものとする。
【０２９６】
このような集計区間管理テーブル１４２ｄ，１４２ｅ，１４２ｆを用いて、分析部１４５は、各階層のサーバの余力を算出する。分析部１４５は、例えば図１６に示した第２の実施の形態のボトルネック判定処理（ステップＳ１２４）に代えて、余力計算処理を実行する。なお、分析部１４５は、図１６に示した第２の実施の形態のボトルネック判定処理（ステップＳ１２４）と余力計算処理との両方を実行することもできる。
【０２９７】
図４２は、余力計算処理の手順の一例を示すフローチャートである。以下、図４２に示す処理をステップ番号に沿って説明する。
［ステップＳ３０１］分析部１４５は、処理対象となっている階層の集計区間を１つ選択する。例えば分析部１４５は、集計区間情報記憶部１４２に格納されている集計区間管理テーブル１４２ｄ，１４２ｅ，１４２ｆのうち、現在処理対象となっている階層に対応する集計区間管理テーブルの上位の集計区間から順に選択する。
【０２９８】
［ステップＳ３０２］分析部１４５は、選択した集計区間の多重度が飽和多重度以下か否かを判断する。例えば分析部１４５は、集計区間管理テーブル内の選択した集計区間のエントリにおける多重度と、飽和多重度決定部１４４で決定された多重度とを比較して、選択した集計区間の多重度が飽和多重度以下か否かを判断する。分析部１４５は、選択した集計区間の多重度が飽和多重度以下であれば、処理をステップＳ３０３に進める。また分析部１４５は、選択した集計区間の多重度が飽和多重度より大きければ、処理をステップＳ３０４に進める。
【０２９９】
［ステップＳ３０３］分析部１４５は、選択した集計区間の未飽和フラグを、未飽和区間に設定する。例えば分析部１４５は、処理対象の階層の集計区間管理テーブル内の選択した集計区間のエントリにおける未飽和フラグに「１」を設定する。
【０３００】
［ステップＳ３０４］分析部１４５は、未処理の集計区間があるか否かを判断する。分析部１４５は、未処理の集計区間があれば処理をステップＳ３０１に進める。また分析部１４５は、未処理の集計区間がなければ処理をステップＳ３０５に進める。
【０３０１】
［ステップＳ３０５］分析部１４５は、最大スループットを決定する。最大スループットは、例えば、飽和多重度から開始される多重度区間内に含まれる集計区間のスループットの最大値である。
【０３０２】
［ステップＳ３０６］分析部１４５は、以下の式（３）により余力を算出する。
【０３０３】
【数３】
【０３０４】
式（３）において、ｎ（０以上の整数）は、多重度が飽和多重度を下回っている集計区間（未飽和区間）の数である。ｔｐmaxは、飽和多重度のときに記録した最大スループットである。ｔｐkは、未飽和区間と判定された集計区間を並べたときのｋ番目（ｋは１以上ｎ以下の整数）の集計区間におけるスループットである。ＴＷnumallは、分析対象期間に含まれる集計区間の総数である。
【０３０５】
式（３）は、未飽和区間のスループットと最大スループットとの差分が、最大スループットに占める割合の平均値に、全ての集計区間に対する未飽和区間の区間数の割合を掛け合わせたものである。この計算の結果、処理対象となっている階層の残存処理能力が算出される。
【０３０６】
図４３は、余力計算処理を説明する図である。図４３には、説明をわかりやすくするため、集計区間の総数が１１の場合の例を示している。図４３の例では、飽和多重度以下の多重度を持つ集計区間（未飽和区間）の数は５であり、最大スループットは２８００である。よって、上記の式（３）は次のようになる。
双方向矢印で示された差分の総和／（２８００×５）×５／１１
ここで重要なのは、余力の計算において、飽和多重度よりも多重度が高い集計区間は、スループットが最大スループットより少なくても、残存処理能力に加えないことである。換言すると、飽和多重度を境界として、その前後で領域を分けて、飽和多重度以下の場合のみ、最大スループットとの差分を残存処理能力として計算している。例えば図４３の多重度１０以上の各集計区間のスループットは、最大スループットより少ない。しかしこの集計区間は、高多重度による過負荷のためにスループットが低下しているものと考えられる。過負荷によるスループットの低下が生じている集計区間には残存処理能力はないため、残存処理能力としては加えられていない。
【０３０７】
なお、全ての集計区間について、最大スループットと各集計区間のスループットの差分を求めて、その平均値を計算する方法を取ると、飽和多重度を過ぎて過負荷のオーバヘッドによるスループット低下が起きている場合まで、残存処理能力に加算されてしまう。第６の実施の形態では、このような過負荷のオーバヘッドによりスループットが低下している集計区間の残存処理能力を「０」にすることで、余力計算の正確性を向上させている。
【０３０８】
しかも、第６の実施の形態によって、処理性能が完全には飽和していない半飽和状態の階層においても、あとどれだけの処理能力を残しているかが見積もれるようになる。これによって、システム全体の処理能力が完全飽和する前に対策を打つことが可能になる。また、飽和状態の階層をスケールアウト（マシン台数の増加）して性能強化した時に、２番目に弱い階層が、あとどれだけ負荷量を増加した時に次にボトルネックとなるかを見積もることも可能となる。
【０３０９】
〔第７の実施の形態〕
次に第７の実施の形態について説明する。第７の実施の形態は、集計区間の長さの最適値を自動的に求めるものである。なお、第７の実施の形態を実現するシステム構成は第２の実施の形態と同様である。そこで、図６に示した第２の実施の形態の各要素を用いて第７の実施の形態の機能を説明する。
【０３１０】
第２の実施の形態では「異種ジョブ間でのハードウェア資源消費量の差異」は正規化しているが、「同種ジョブでも、各ジョブ間でのハードウェア資源消費量の差異」によって発生する揺らぎは、平均化されることを期待している。平均化のためには、集計区間に含まれるジョブの数は多い方が良いので、集計区間は長い方が有利になる。その一方で、集計区間が長くなると、その中での多重度推移が大きくなり、多重度とスループットの関係を正確に測れなくなる。そこで第７の実施の形態では、同一種ジョブ間でのハードウェア資源消費量の差異が許容できる範囲に収まるように、以下の方法で適切な長さの集計区間を決定する。
【０３１１】
第７の実施の形態では、多重度が低い区間では、多重度とスループットが正比例に近い関係を示すことを利用する。ただし、集計区間を短く設定しすぎた場合は、同種ジョブ内でのハードウェア資源消費量の差異によって発生する揺らぎが平均化されず、多重度とスループットの関係を乱すことになる。そのことを利用して、以下の手順で、個々のジョブ間の差異が平均化されるのに十分な集計区間の長さを求める。なお集計区間長の決定処理は、例えば図１６に示した第２の実施の形態における階層別性能分析処理における、ステップＳ１２１の前に行われる。
【０３１２】
図４４は、集計区間長決定処理の手順を示すフローチャートである。以下、図４４に示す処理をステップ番号に沿って説明する。
［ステップＳ４０１］集計部１４１は、集計区間長の初期値を設定する。設定する初期値は、想定される集計区間長よりも非常に小さな値とする。例えば仮集計区間長として１０ｍｓを設定する。
【０３１３】
［ステップＳ４０２］集計部１４１は、分析対象期間を仮集計区間長で分割する。これにより、複数の集計区間が生成される。
［ステップＳ４０３］集計部１４１は、ステップＳ４０４〜ステップＳ４０７の処理が未処理の集計区間のうちの１つを選択する。
【０３１４】
［ステップＳ４０４］集計部１４１は、選択した集計区間の多重度を計算する。
［ステップＳ４０５］集計部１４１は、選択した集計区間の多重度が閾値より低いか否かを判断する。閾値としては、例えば０．５や１．０といった値が予め集計部１４１に設定されている。集計部１４１は、多重度が閾値より低ければ、処理をステップＳ４０６に進める。また集計部１４１は、多重度が閾値以上であれば、処理をステップＳ４０３に進める。
【０３１５】
［ステップＳ４０６］集計部１４１は、選択した集計区間のスループットを計算する。
［ステップＳ４０７］集計部１４１は、多重度が閾値より低いとｉ番目（ｉは、１以上の整数）に判断された集計区間について、「スループット÷多重度」の逆正接となる角度θiを、以下の式で求める。
θi=ｔａｎ-1（ｔｐi／ｌｄi）
［ステップＳ４０８］集計部１４１は、未処理の集計区間があるか否かを判断する。集計部１４１は、未処理の集計区間がある場合、処理をステップＳ４０３に進める。また集計部１４１は、全ての集計区間に対してステップＳ４０４〜ステップＳ４０７の処理が終了していれば、処理をステップＳ４０９に進める。
【０３１６】
［ステップＳ４０９］集計部１４１は、多重度が閾値より低い集計区間が十分にあるか否かを判断する。例えば集計部１４１は、集計区間の総数に対する、多重度が閾値より低い集計区間の割合が、予め設定された所定値以上であれば、多重度が閾値より低い集計区間が十分にあると判断する。集計部１４１は、多重度が閾値より低い集計区間が十分にあれば、処理をステップＳ４１１に進める。また集計部１４１は、多重度が閾値より低い集計区間が十分にはなければ、処理をステップＳ４１０に進める。
【０３１７】
［ステップＳ４１０］集計部１４１は、多重度が閾値より低い集計区間が十分にない場合、集計区間長を決定するには負荷が過大であり、集計区間長を決定できないと判断し、集計区間長決定処理を終了する。
【０３１８】
なお集計区間長が決定できなかった場合、集計部１４１は、以後の処理（図１６のステップＳ１２１）では、例えば予め設定されていた値（例えば１００ｍｓ）を集計区間長とする。また集計区間長が決定できなかった場合、集計部１４１は、以後の処理において、同一階層の他の解析対象区間に対する集計区間長決定処理で求められた集計区間長を使用することもできる。
【０３１９】
［ステップＳ４１１］集計部１４１は、変動係数ＣＶを算出する。変動係数ＣＶは、相対的なばらつきを表す数値である。変動係数ＣＶは、ステップＳ４０７で得られた角度θiの標準偏差を、平均値で割ることによって得られる。式で表すと以下の式となる。
【０３２０】
【数４】
【０３２１】
ここで、ｍはステップＳ４０６に処理が進んだ集計区間の数である。
［ステップＳ４１２］集計部１４１は、変動係数が所定の閾値より大きいか否かを判断する。所定の閾値としては、例えば０．１が設定される。集計部１４１は、変動係数が所定の閾値より大きければ、処理をステップＳ４１３に進める。また集計部１４１は、変動係数が所定の閾値以下であれば、処理をステップＳ４１４に進める。
【０３２２】
［ステップＳ４１３］集計部１４１は、仮集計区間長を一定割合長くする。例えば集計部１４１は、現在の仮集計区間長に１０ｍｓを加算した値を、新たな仮集計区間長とする。その後、集計部１４１は、処理をステップＳ４０２に進め、新たな仮集計区間長の場合の変動係数を計算する。
【０３２３】
［ステップＳ４１４］集計部１４１は、変動係数が閾値以下になった場合、現在の仮集計区間長を、集計区間長に決定する。
このようにして、最適な集計区間長を決定することができる。この手法は、多重度が低い時（例えば常に１以下）には、多重度（ジョブ量）の増加に伴ってスループットは単調に増加するという考えに基づいている。多重度が低い時に限って、その両者の関係を測定し、それが一定の分布の範囲に収まっていれば、集計区間長は短すぎず、同一種ジョブ間でのハードウェア資源消費量の差異は平均化されていると判断する。逆に、多重度とスループットの関係の分散が大きい時には、同一種ジョブ間でのハードウェア資源消費量の差異の影響が出ていると判断し、集計区間長を大きくする。
【０３２４】
第７の実施の形態によって、収集されたデータから集計区間の長さを自動的に決定できるようになり、集計区間を事前に調整する手間が省ける。また、不適切な集計区間の設定によって、誤った性能分析結果を得ることも避けられる。
【０３２５】
〔第８の実施の形態〕
次に第８の実施の形態について説明する。第８の実施の形態は、最適化のための低負荷時の平均処理時間を、分析対象期間に取得された時系列データの中から取得するものである。なお、第８の実施の形態を実現するシステム構成は第２の実施の形態と同様である。そこで、図６に示した第２の実施の形態の各要素を用いて第８の実施の形態の機能を説明する。
【０３２６】
第２の実施の形態におけるスループットの正規化では、低負荷時に予め採取したデータから算出した平均処理時間を使用している（図２３参照）。第８の実施の形態は、この平均処理時間を、性能分析に使用するのと同一の時系列データから採取する。
【０３２７】
図４５は、低負荷時の平均処理時間算出処理の一例を示すフローチャートである。この処理は、例えば、図９に示した第２の実施の形態のステップＳ１１３の処理の後に実行される。以下、図４５に示す処理をステップ番号に沿って説明する。
【０３２８】
［ステップＳ５０１］集計部１４１は、分析対象期間を集計区間長で、複数の集計区間に分割する。
［ステップＳ５０２］集計部１４１は、ステップＳ５０３〜Ｓ５０５の処理が未処理の集計区間を１つ選択する。
【０３２９】
［ステップＳ５０３］集計部１４１は、選択した集計区間の多重度を計算する。例えば集計部１４１は、処理中の階層のサーバで選択した集計区間内に存在しているジョブの、集計区間内での処理時間の合計を求める。そして集計部１４１は、求めた合計を集計区間長で除算し、除算結果を集計区間の多重度とする。
【０３３０】
［ステップＳ５０４］集計部１４１は、選択した集計区間の多重度が、所定の閾値より低いか否かを判断する。所定の閾値としては、例えば０．５や１．０という値が予め設定される。集計部１４１は、多重度が閾値より低い場合、処理をステップＳ５０５に進める。また集計部１４１は、多重度が閾値以上の場合、処理をステップＳ５０６に進める。
【０３３１】
［ステップＳ５０５］集計部１４１は、選択した集計区間を、低負荷区間のリストに登録する。低負荷区間のリストは、例えばＲＡＭ１０３内に保持される。
［ステップＳ５０６］集計部１４１は、ステップＳ５０３〜Ｓ５０５の処理が未処理の集計区間があるか否かを判断する。集計部１４１は、未処理の集計区間があれば、処理をステップＳ５０２に進める。また集計部１４１は、未処理の集計区間がなければ、処理をステップＳ５０７に進める。
【０３３２】
［ステップＳ５０７］集計部１４１は、低負荷区間のリストに含まれる集計区間内で実行されたジョブを用いて、ジョブ種ごとの平均処理時間を計算する。集計部１４１は、計算したジョブ種ごとの平均処理時間を、正規化スループット値記憶部１４３に格納する。
【０３３３】
［ステップＳ５０８］集計部１４１は、ジョブ種ごとの平均処理時間を用いて、各ジョブ種の１ジョブ当たりの正規化されたスループット値を計算する。１ジョブ当たりの正規化されたスループット値の計算手法は、第２の実施の形態で説明した通りである。集計部１４１は、計算したジョブごとの正規化されたスループット値を、正規化スループット値記憶部１４３に格納する。
【０３３４】
なお第４の実施の形態のように、出力されるメッセージ数でスループットを計算する場合もある。この場合、ステップＳ５０８の処理では、集計部１４１は、１ジョブ当たりの正規化されたスループット値の計算に代えて、各ジョブ種の１メッセージ当たりの正規化されたスループット値を計算する。１メッセージ当たりの正規化されたスループット値の計算手法は、第４の実施の形態で説明した通りである。
【０３３５】
このようにして、分析対象期間に採取された時系列データから、ジョブ種ごとの平均処理時間を算出することができる。
図４６は、多重度が閾値以下の集計区間の抽出例を示す図である。図４６の例では、５秒分の時系列データの５０の集計区間（集計区間長は０．１秒）の中で、多重度が１．０以下の集計区間が２３個含まれている。そして、多重度が１．０以下の２３個の集計区間に含まれているジョブだけから、ジョブ種ごとの平均処理時間が計算される。多重度が低いこれらの区間は、ジョブ同士の衝突が少なく、理想的な処理時間に近い値が収集できる。
【０３３６】
ここで、多重度の閾値を０．５に設定すると、得られる集計区間の数は１４に下がる。この閾値は低く設定した方が、ジョブ同士の衝突が少なく、算出される平均処理時間の精度は高くなる。他方、閾値は低く設定しすぎると、得られるデータ量が少なくなり、平均処理時間を計算できないジョブ種が生じる可能性がある。
【０３３７】
第８の実施の形態の手法は、一般的に多重度は増減が激しいものなので、ある程度の長さの時系列データを収集すれば、その中には多重度の低い部分も含まれていることが多いという考えに基づいている。また、多重度が低い部分は、ジョブ同士の衝突が起きる確率が低いので、理想に近い平均処理時間が得られるという考えにも基づいている。
【０３３８】
このように分析対象期間の時系列データからジョブ種ごとの平均処理時間を算出することによって、低負荷時のデータを別途収集する必要がなくなるので、管理者の手間が省ける。しかも、同一の時系列データから全ての情報を取得し、事前に取得する情報を必要としないので、負荷の特性（例えばジョブの平均処理時間など）が動的に変化した場合にも、適切な平均処理時間に基づく分析ができる。すなわち、正規化用の平均応答時間を測定した時の負荷と実運用時の負荷との負荷傾向の違いによって引き起こされる性能分析の不正確さを避けることができる。
【０３３９】
〔第９の実施の形態〕
次に第９の実施の形態について説明する。第９の実施の形態は、瞬間スループット低下を検出するものである。なお、第９の実施の形態を実現するシステム構成は第２の実施の形態と同様である。そこで、図６に示した第２の実施の形態の各要素を用いて第９の実施の形態の機能を説明する。
【０３４０】
Ａｐｐサーバ３００上でＪａｖａ（登録商標）ＶＭがＦｕｌｌ−ＧＣを起こした場合には、非常に短い時間の間、Ｊａｖａ（登録商標）ＶＭの動作が止まり、Ａｐｐサーバ３００の階層のスループットが一瞬だけ急激に低下することがある。このような現象が発生していることは、以下の手順で検出することが可能である。なお以下の瞬間スループット低下検出処理は、例えば図１６に示した第２の実施の形態のボトルネック判定処理（ステップＳ１２４）に代えて、分析部１４５により実行される。なお、分析部１４５は、図１６に示した第２の実施の形態のボトルネック判定処理（ステップＳ１２４）と瞬間スループット低下検出処理との両方を実行することもできる。
【０３４１】
図４７は、瞬間スループット低下検出処理の手順を示すフローチャートである。また以下、図４７に示す処理をステップ番号に沿って説明する。
［ステップＳ６０１］分析部１４５は、集計区間を１つ選択する。例えば分析部１４５は、処理対象となっている階層に対応する集計区間管理テーブル（図２２参照）の上位から順に、集計区間を選択する。
【０３４２】
［ステップＳ６０２］分析部１４５は、集計区間の多重度の最小値と最大値とを求める。
［ステップＳ６０３］分析部１４５は、ステップＳ６０２の処理が未処理の集計区間があるか否かを判断する。分析部１４５は、未処理の集計区間があれば、処理をステップＳ６０１に進める。また分析部１４５は、未処理に集計区間がなければ、処理をステップＳ６０４に進める。
【０３４３】
［ステップＳ６０４］分析部１４５は、多重度の最小値と最大値との間を等間隔に分割する。例えば分析部１４５は、多重度の最小値と最大値の間を、一定数（例えば１００）もしくは一定間隔ごと（例えば多重度０．１ごと）に分割する。例えば図２６に示す散布図に示されるような多重度が得られた場合、０と５０の間を０．５刻みで１００分割する（説明を簡便にするために５０を超えている多重度は無視している）。分割によって、複数の多重度区間が生成される。
【０３４４】
［ステップＳ６０５］分析部１４５は、分割によって生成された多重度区間のうち、ステップＳ６０６〜Ｓ６０７の処理が未処理の多重度区間を１つ選択する。
［ステップＳ６０６］分析部１４５は、スループットの統計上の信頼区間を算出する。例えば分析部１４５は、選択した多重度区間の範囲に属する多重度を持つ全ての集計区間から、スループットの平均値と標準偏差を計算し、以下の式（５）の信頼区間を得る。ここでは、例として信頼度を９５％として信頼区間を求める。
【０３４５】
【数５】
【０３４６】
式（５）中で、１．９６は９５％信頼区間の定数である。
［ステップＳ６０７］分析部１４５は、スループットが信頼区間の下限未満の集計区間を計数する。
【０３４７】
［ステップＳ６０８］分析部１４５は、ステップＳ６０６〜Ｓ６０７の処理が未処理の多重度区間があるか否かを判断する。分析部１４５は、未処理の多重度区間があれば、処理をステップＳ６０５に進める。また分析部１４５は、未処理の多重度区間がなければ、処理をステップＳ６０９に進める。
【０３４８】
［ステップＳ６０９］分析部１４５は、集計区間全体に対する、ステップＳ６０７で計数されたスループットが信頼区間の下限未満であった集計区間の割合を算出する。例えば分析部１４５は、９５％信頼区間を求めた場合、スループットの９５％信頼区間を下回るスループットを持っていた集計区間の割合を求める。
【０３４９】
［ステップＳ６１０］分析部１４５は、ステップＳ６０９で算出した割合が、閾値を超えているか否かを判断する。このときの閾値は、集計区間のスループットが信頼区間の下限を下回る統計的な確率よりも大きな値が、予め設定される。例えば９５％信頼区間の場合は、下限を下回る統計的確率が２．５％あるので、それよりも大きな値（例えば５％）が、閾値に設定される。分析部１４５は、割合が閾値を超えている場合、処理をステップＳ６１１に進める。また分析部１４５は、割合が閾値を超えていない場合、処理をステップＳ６１２に進める。
【０３５０】
［ステップＳ６１１］分析部１４５は、異常な瞬間スループットの低下が発生していると判断する。分析部１４５は、例えば判断結果をモニタ１１に表示する。その後、分析部１４５は、瞬間スループット低下検出処理を終了する。
【０３５１】
［ステップＳ６１２］分析部１４５は、異常な瞬間スループットの低下が発生していないと判断する。分析部１４５は、例えば判断結果をモニタ１１に表示する。その後、分析部１４５は、瞬間スループット低下検出処理を終了する。
【０３５２】
このようにして、信頼区間を下回るスループットを持つ集計区間の、全体に占める割合が、予め決めた閾値を超えた場合は、その階層において異常な瞬間スループット低下が発生していると判断される。例えばＡｐｐサーバ３００上のＪａｖａ（登録商標）ＶＭがＦｕｌｌ−ＧＣを起こした場合などのように、多重度に関係なく瞬間的なスループット低下を起こした場合に、演算処理によって、異常な瞬間スループット低下の発生を検出することが可能となる。
【０３５３】
図４８は、第９の実施の形態により異常な瞬間スループット低下が検出される散布図の一例である。図４８に示すように、Ｊａｖａ（登録商標）ＶＭのＦｕｌｌ−ＧＣなどによって引き起こされた異常な瞬間スループット低下の発生が、容易に検出できる。
【０３５４】
なお、第９の実施の形態は、第４の実施の形態と組み合わせることで、効果が顕著となる。例えば、図３８、図３９で示したように、第４の実施の形態を用いると瞬間的なスループット低下が顕著に表れる。このように顕在化させた瞬間スループットの低下を、第９の実施の形態の手法によって、機械的処理で検出可能となる。
【０３５５】
〔その他の実施形態〕
第２の実施の形態では、ネットワークからキャプチャしたＩＰパケットに基づいてメッセージを再現しているが、この手法はプロトコルメッセージを再現する手法の１つに過ぎず、他の手法でメッセージを再現することも可能である。例えば、多階層システムに含まれる各サーバで、実行したジョブのログを記録しておき、各サーバに記録されたログに基づいてメッセージを再現することも可能である。
【０３５６】
ただし、ＩＰパケットをキャプチャしてメッセージを再現すれば、コンピュータ間の時計誤差の問題の発生が抑止されるという利点がある。すなわち、多階層システムにおいて、各サーバの時刻を正確に一致させるのは難しく、若干の誤差が生じてしまうことが多い。しかし、メッセージフローを再現するには、異なるサーバから送信されたメッセージ間の前後関係を正確に判別できることが重要である。複数のサーバの時刻間にずれがあると、各サーバでデータを採取した時刻にずれが生じ、メッセージフローの再現性が低下する。各階層のサーバでログを記録する手法の場合、異なるサーバのログを比較する際に、各ログの時刻が不正確であることで、ログ間の前後関係の正確な判定が困難となる。他方、ＩＰパケットを１つの装置でキャプチャすれば、パケットが転送された時刻の前後関係を正確に判断できる。その結果、メッセージを正確に再現することが可能となる。
【０３５７】
また、ＩＰパケットをキャプチャしてメッセージを再現する手法には、多階層システムに含まれるサーバにおいてデータを保存したり、保存したデータを分析装置に転送したりする処理が不要である利点もある。例えば多階層システムに含まれる各サーバで取得したログからメッセージを再現する手法では、各サーバがログを記憶し、さらに記憶したログを分析装置に転送することとなる。ＩＰパケットをキャプチャしてメッセージを再現する手法であれば、各サーバでログを記憶せずにすみ、ネットワーク上に新たなパケット転送を生じさせることもない。
【０３５８】
なお、上記の各実施の形態に示した処理機能は、コンピュータによって実現することができる。その場合、情報処理装置１または分析サーバ１００が有する機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記憶装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記憶装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ／ＲＷなどがある。光磁気記録媒体には、ＭＯなどがある。
【０３５９】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【０３６０】
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。
【０３６１】
また、上記の処理機能の少なくとも一部を、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）などの電子回路で実現することもできる。
【０３６２】
以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。ただし、スループットを算出する具体的な手法については、第２の実施の形態と第４の実施の形態とのいずれか一方の手法を採用することができる。また、飽和多重度の決定手法については、第２の実施の形態と第５の実施の形態とのいずれかの手法を採用することができる。
【０３６３】
以上の実施の形態に開示された技術には、以下の付記に示す技術が含まれる。
（付記１） コンピュータに、
分析対象装置で分析対象期間内に実行された処理の実行期間を示す情報を記憶手段から取得し、該取得した情報に基づいて、前記分析対象期間を細分化して得られる集計区間ごとに、集計区間内で実行された処理それぞれの実行に費やされた時間を合計した合計処理時間と、集計区間内で実行された処理それぞれの進行量を合計した合計進行量とを計算し、
集計区間ごとの合計処理時間と合計進行量とに基づいて、合計処理時間の増加量に対する合計進行量の増加量が所定値以下となる合計処理時間の閾値を決定し、
合計処理時間が前記閾値以上の集計区間を検出する、
処理を実行させるプログラム。
【０３６４】
（付記２） 集計区間で実行された処理の進行量は、該処理を依頼した処理要求に応じて実行される処理全体のうちの、該集計区間で実行された割合であることを特徴とする付記１記載のプログラム。
【０３６５】
（付記３） 集計区間で実行された処理の進行量は、該処理を依頼した処理要求に応じて実行される処理全体のうちの、該集計区間で実行された割合に、各処理種別に属する処理の低負荷時の処理時間に基づく重み付けを行った値であることを特徴とする付記１記載のプログラム。
【０３６６】
（付記４） 集計区間の総数に対する、前記閾値以上の合計処理時間の集計区間の割合が所定数以上の場合、前記分析対象期間において前記分析対象装置の処理が処理能力の限界に達していると判断することを特徴とする付記１乃至３のいずれかに記載のプログラム。
【０３６７】
（付記５） 他の装置への処理要求の送信を伴う処理については、処理の最初の実行期間を除外して、合計処理時間と合計進行量とを計算することを特徴とする付記１乃至４のいずれかに記載のプログラム。
【０３６８】
（付記６） 集計区間で実行された処理の進行量は、該集計区間に出力されたメッセージ数に応じた値であることを特徴とする付記１記載のプログラム。
（付記７） 集計区間で実行された処理の進行量は、該処理の全体で出力されるメッセージ数のうち、該集計区間に出力されたメッセージ数の割合に、各処理種別に属する処理の低負荷時の処理時間に基づく重み付けを行った値であることを特徴とする付記６記載のプログラム。
【０３６９】
（付記８） 集計区間それぞれの合計処理時間の最小値から最大値までの範囲を細分化して得られる細分化区間ごとに、細分化区間内の合計処理時間を有する集計区間の合計処理時間を平均した平均処理時間と、細分化区間内の合計処理時間を有する集計区間の合計進行量を平均した平均処理進行量とを計算し、隣接する細分化区間における平均処理時間の増加量に対する平均処理進行量の変化量を示す傾きを計算し、隣接する細分化区間の傾きに基づいて、前記閾値を決定することを特徴とする付記１乃至７のいずれかに記載のプログラム。
【０３７０】
（付記９） 集計区間それぞれの合計処理時間の最小値から最大値までの範囲を細分化して得られる細分化区間ごとに、細分化区間内の合計処理時間を有する集計区間から合計処理時間と合計進行量それぞれの平均値を計算し、範囲に含む合計処理時間の短い細分化区間から順に、合計処理時間と合計進行量それぞれの平均値から計算される傾きを一つずつ加えていきながら、傾きの統計上の信頼区間を求めていき、該信頼区間の下限が所定値を下回った細分化区間の合計処理時間を、前記閾値とすることを特徴とする付記１乃至７のいずれかに記載のプログラム。
【０３７１】
（付記１０） 前記閾値未満の合計処理時間の集計区間それぞれの合計進行量と最大合計処理進行量との差分の総和を、前記分析対象装置の余力と判断することを特徴とする付記１乃至９のいずれかに記載のプログラム。
【０３７２】
（付記１１） 分析対象期間を集計区間に分割する際には、合計処理時間が所定値より低い集計区間それぞれにおける合計処理時間と合計進行量との関係を示す数値のばらつきが所定値より低くなる範囲内の最も短い時間を、集計区間の長さとすることを特徴とする付記１乃至１０のいずれかに記載のプログラム。
【０３７３】
（付記１２） 合計処理時間が所定値以下の集計区間を抽出し、抽出した集計区間内で実行された処理の、処理種別ごとの平均処理時間を計算し、処理種別の平均処理時間に応じた値を、各処理種別に属する処理の重みとすることを特徴とする付記３または７のいずれかに記載のプログラム。
【０３７４】
（付記１３） 集計区間それぞれの合計処理時間の最小値から最大値までの範囲を細分化して得られる細分化区間ごとに、細分化区間内の合計処理時間を有する集計区間から合計進行量の分布の統計上の信頼区間を求め、信頼区間の下限値以下の合計進行量を有する集計区間の、集計区間全体に対する割合を求め、該割合が一定の閾値を超えている場合に、前記分析対象装置において前記分析対象期間内で異常な瞬間性能低下が発生していると判断することを特徴とする付記１乃至１２のいずれかに記載のプログラム。
【０３７５】
（付記１４） コンピュータが、
分析対象装置で分析対象期間内に実行された処理の実行期間を示す情報を記憶手段から取得し、該取得した情報に基づいて、前記分析対象期間を細分化して得られる集計区間ごとに、集計区間内で実行された処理それぞれの実行に費やされた時間を合計した合計処理時間と、集計区間内で実行された処理それぞれの進行量を合計した合計進行量とを計算し、
集計区間ごとの合計処理時間と合計進行量とに基づいて、合計処理時間の増加量に対する合計進行量の増加量が所定値以下となる合計処理時間の閾値を決定し、
合計処理時間が前記閾値以上の集計区間を検出する、
処理を実行する分析方法。
【０３７６】
（付記１５） 分析対象装置で分析対象期間内に実行された処理の実行期間を示す情報を記憶手段から取得し、該取得した情報に基づいて、前記分析対象期間を細分化して得られる集計区間ごとに、集計区間内で実行された処理それぞれの実行に費やされた時間を合計した合計処理時間と、集計区間内で実行された処理それぞれの進行量を合計した合計進行量とを計算する計算手段と、
集計区間ごとの合計処理時間と合計進行量とに基づいて、合計処理時間の増加量に対する合計進行量の増加量が所定値以下となる合計処理時間の閾値を決定する決定手段と、
合計処理時間が前記閾値以上の集計区間を検出する検出手段と、
を有する情報処理装置。
【符号の説明】
【０３７７】
１ 情報処理装置
１ａ 監視手段
１ｂ 記憶手段
１ｃ 計算手段
１ｄ 決定手段
１ｅ 検出手段
２ ネットワーク
３ 端末装置
４ Ｗｅｂサーバ
５ Ａｐｐサーバ
６ ＤＢサーバ
【技術分野】
【０００１】
本発明は、コンピュータシステムの性能を分析するプログラム、分析方法、および情報処理装置に関する。
【背景技術】
【０００２】
従来、複数のコンピュータが階層的に処理を分担するコンピュータシステム（多階層システムという）が利用されている。以下、多階層システムを構成するコンピュータを「サーバ」と呼ぶ。多階層システムとして、例えばシステム利用のためのインタフェースを提供するＷｅｂサーバ、システム上の業務処理を実行するＡｐｐ（Application）サーバおよびデータを管理するＤＢ（Database）サーバを有する三階層システムが知られている。各サーバは、ユーザからの処理要求に対して連携して処理を実行し、その処理要求に応答する。このように、各サーバに処理を分担させることで、システムの負担を分散させると共に、各階層のコンピュータの量を適切に調整することによって、信頼性や応答性を向上できる。
【０００３】
このようなＷｅｂ三階層システムに代表される多階層システムにおいて、エンドユーザにおける応答時間の増大が発生した際には、問題が発生しているサーバが属する階層を特定することが、障害対応の第一歩として非常に重要である。そのために、各階層のサーバにおける処理時間を測定し、その推移を監視することによって問題の有無を判定する手法が広く一般に採用されている。
【０００４】
例えば、トランザクションモデルを生成し、スイッチを介して送受信されたメッセージからトランザクションモデルに沿って進行するメッセージの受け渡しを検出する技術が考えられている。この技術により、任意のトランザクションを構成するメッセージの集合を特定し、そのトランザクションの解析が可能となる。例えば、ユーザのリクエストからレスポンスまでの各アプリケーションの処理を追跡することができる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００６−１１６８３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかし、従来の方法では、分析対象であるサーバが処理に要した時間を把握することはできるものの、サーバの処理能力に余力があるかどうかについてはわからなかった。
１つの側面では、本発明は、分析対象装置の処理能力の余力の有無を判断することができるプログラム、分析方法、および情報処理装置を提供することを目的とする。
【課題を解決するための手段】
【０００７】
１つの案では、コンピュータに、分析対象装置で分析対象期間内に実行された処理の実行期間を示す情報を記憶手段から取得し、該取得した情報に基づいて、前記分析対象期間を細分化して得られる集計区間ごとに、集計区間内で実行された処理それぞれの実行に費やされた時間を合計した合計処理時間と、集計区間内で実行された処理それぞれの進行量を合計した合計進行量とを計算し、集計区間ごとの合計処理時間と合計進行量とに基づいて、合計処理時間の増加量に対する合計進行量の増加量が所定値以下となる合計処理時間の閾値を決定し、合計処理時間が前記閾値以上の集計区間を検出する、処理を実行させるプログラムが提供される。
【発明の効果】
【０００８】
分析対象装置の処理能力の余力の有無を判断することができるようになる。
【図面の簡単な説明】
【０００９】
【図１】第１の実施の形態に係るシステムの構成の一例を示す図である。
【図２】第１の実施の形態の分析処理の手順の一例を示すフローチャートである。
【図３】第１の実施の形態による余力判定例を示す図である。
【図４】第２の実施の形態の業務システムの全体構成を示す図である。
【図５】第２の実施の形態に用いるコンピュータのハードウェアの一構成例を示す図である。
【図６】第２の実施の形態に係る分析サーバの機能の一例を示すブロック図である。
【図７】キャプチャ処理の手順の一例を示すフローチャートである。
【図８】キャプチャデータ記憶部のデータ構造の一例を示す図である。
【図９】性能分析処理の手順の一例を示すフローチャートである。
【図１０】メッセージデータ記憶部のデータ構造の一例を示す図である。
【図１１】抽象化ルール記憶部のデータ構造の一例を示す図である。
【図１２】ＨＴＴＰのプロトコルのジョブ種の例を示す図である。
【図１３】ＤＢのプロトコルのジョブ種の例を示す図である。
【図１４】ジョブ種が識別されたメッセージフローの一例を示す図である。
【図１５】メッセージフロー情報記憶部のデータ構造の一例を示す図である。
【図１６】階層別性能分析処理の手順の一例を示すフローチャートである。
【図１７】多重度とスループットとの関係を示す図である。
【図１８】集計区間への分割例を示す図である。
【図１９】実行期間の集計区間への振り分け例を示す図である。
【図２０】並列で処理が実行される状況を示す図である。
【図２１】スループット・多重度算出処理の手順の一例を示すフローチャートである。
【図２２】集計区間情報記憶部のデータ構造の一例を示す図である。
【図２３】正規化スループット値記憶部のデータ構造の一例を示す図である。
【図２４】スループットの時系列推移の一例を示す図である。
【図２５】多重度の時系列推移の一例を示す図である。
【図２６】多重度とスループットとの関係の一例を示す散布図である。
【図２７】飽和多重度算出処理の一例を示すフローチャートである。
【図２８】ボトルネック判定処理の手順の一例を示すフローチャートである。
【図２９】階層が完全未飽和状態の一例を示す散布図である。
【図３０】階層が未飽和状態の一例を示す散布図である。
【図３１】階層が半飽和状態の一例を示す散布図である。
【図３２】階層が飽和状態の一例を示す散布図である。
【図３３】多重度とスループットの関連性を壊す要因の一例を示す図である。
【図３４】間接的な外部資源待ち時間を除外しない場合の各集計区間のスループットと多重度との一例を示す散布図である。
【図３５】間接的な外部資源待ち時間を除外した場合の各集計区間のスループットと多重度との一例を示す散布図である。
【図３６】Ｆｕｌｌ−ＧＣによる停止期間が発生した場合の一連の業務処理を示す図である。
【図３７】第４の実施の形態における正規化スループット値記憶部のデータ構造の一例を示す図である。
【図３８】１ジョブ当たりの正規化スループット値に基づいてスループットを計算した場合の散布図である。
【図３９】１メッセージ当たりの正規化スループット値に基づいてスループットを計算した場合の散布図である。
【図４０】第５の実施の形態における飽和多重度算出処理の一例を示すフローチャートである。
【図４１】第６の実施の形態の集計区間情報記憶部のデータ構造の一例を示す図である。
【図４２】余力計算処理の手順の一例を示すフローチャートである。
【図４３】余力計算処理を説明する図である。
【図４４】集計区間長決定処理の手順の一例を示すフローチャートである。
【図４５】低負荷時の平均処理時間算出処理の一例を示すフローチャートである。
【図４６】多重度が閾値以下の集計区間の抽出例を示す図である。
【図４７】瞬間スループット低下検出処理の手順の一例を示すフローチャートである。
【図４８】第９の実施の形態により異常な瞬間スループット低下が検出される散布図の一例である。
【発明を実施するための形態】
【００１０】
以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第１の実施の形態〕
第１の実施の形態は、単位期間における処理の合計処理時間の平均と、その単位期間における処理の合計進行量との関連を求め、合計処理時間が上昇しても合計進行量が上昇しなくなっている場合に、処理性能が限界に達していると判定するものである。
【００１１】
図１は、第１の実施の形態に係るシステムの構成の一例を示す図である。第１の実施の形態では、情報処理装置１が、例えばＷｅｂ三階層システム中の各サーバを分析対象装置とし、ネットワーク２を介してサーバの性能分析を行う。Ｗｅｂ三階層システムは、端末装置３からの要求に応じて、複数のサーバが連携して処理を実行するコンピュータシステムである。Ｗｅｂ三階層システムは、例えばＷｅｂサーバ４、Ａｐｐサーバ５、ＤＢサーバ６で構成される。
【００１２】
情報処理装置１は、例えば監視手段１ａ、記憶手段１ｂ、計算手段１ｃ、決定手段１ｄ、および検出手段１ｅを有する。
監視手段１ａは、分析対象期間内のＷｅｂサーバ４、Ａｐｐサーバ５、ＤＢサーバ６の動作を監視し、各サーバの処理の実行期間を示す情報を取得する。そして監視手段１ａは、取得した情報を記憶手段１ｂに格納する。
【００１３】
記憶手段１ｂは、分析対象装置で分析対象期間内に実行された処理の実行期間を示す情報を記憶する。
計算手段１ｃは、分析対象装置で分析対象期間内に実行された処理の実行期間を示す情報を記憶手段１ｂから取得する。次に計算手段１ｃは、取得した情報に基づいて、分析対象期間を細分化して得られる集計区間ごとに、集計区間内で実行された処理それぞれの進行量を合計した合計進行量を計算する。さらに計算手段１ｃは、取得した情報に基づいて、分析対象期間を細分化して得られる集計区間ごとに、集計区間内で実行された処理それぞれの実行に費やされた時間を合計した合計処理時間を計算する。
【００１４】
決定手段１ｄは、集計区間ごとの合計処理時間と合計進行量とに基づいて、合計処理時間の増加量に対する合計進行量の増加量が所定値以下となる合計処理時間の閾値を決定する。
【００１５】
検出手段１ｅは、合計処理時間が閾値以上の集計区間を検出する。
このような構成のシステムにおいて、以下のような処理が行われる。
図２は、第１の実施の形態の分析処理の手順の一例を示すフローチャートである。以下、図２に示す処理をステップ番号に沿って説明する。
【００１６】
［ステップＳ１］監視手段１ａは、分析対象期間内のＷｅｂサーバ４、Ａｐｐサーバ５、ＤＢサーバ６の動作を監視する。例えば監視手段１ａは、Ｗｅｂサーバ４、Ａｐｐサーバ５、ＤＢサーバ６に入出力されるメッセージをネットワーク２からキャプチャする。監視手段１ａは、監視内容に基づいて、Ｗｅｂサーバ４、Ａｐｐサーバ５、ＤＢサーバ６から、処理の実行状況に関する情報を、監視結果として取得する。そして監視手段１ａは、監視結果を記憶手段１ｂに格納する。
【００１７】
［ステップＳ２］計算手段１ｃは、記憶手段１ｂに格納されている情報に基づいて、分析対象装置であるサーバごとに、合計進行量を計算する。例えば計算手段１ｃは、分析対象期間を細分化して、集計区間を生成する。次に計算手段１ｃは、生成した集計区間ごとに、各サーバにおいて集計区間内で実行された処理それぞれの進行量を計算する。そして計算手段１ｃは、サーバごとに、各集計区間の進行量を合計し、合計進行量とする。
【００１８】
［ステップＳ３］計算手段１ｃは、記憶手段１ｂに格納されている情報に基づいて、分析対象装置であるサーバごとに、合計処理時間を計算する。例えば計算手段１ｃは、分析対象期間を細分化して、集計区間を生成する。次に計算手段１ｃは、生成した集計区間ごとに、各サーバにおいて集計区間内で実行された処理それぞれの実行に費やされた時間を計算する。そして計算手段１ｃは、サーバごとに、各集計区間の実行に費やされた時間を合計し、合計処理時間とする。なお各サーバでは、複数の処理を並列実行する場合がある。そのため、合計処理時間は、集計区間の長さ（時間幅）より大きくなる場合もある。
【００１９】
［ステップＳ４］決定手段１ｄは、集計区間ごとの合計処理時間と合計進行量とに基づいて、合計処理時間の増加量に対する合計進行量の増加量が所定値以下となる合計処理時間の閾値を決定する。
【００２０】
［ステップＳ５］検出手段１ｅは、合計処理時間が閾値以上の集計区間を検出する。
このようにして検出された集計区間は、合計処理時間が増加しても、処理の進行が増加しなくなっている時間帯である。すなわち、性能の余力がなくなっている時間帯である。合計処理時間が閾値以上の集計区間が多数検出されたサーバは、余力がなくなりつつあることが分かる。また合計処理時間が閾値以上の集計区間がほとんど検出されていないサーバは、性能の余力が十分にあることが分かる。
【００２１】
図３は、第１の実施の形態による余力判定例を示す図である。図３の例では、各サーバにおいて、処理要求が入力されてから応答を返すまでに、処理要求に応じて実行された処理全体で、処理の進行を示す単位量を「１」としている。複数の集計区間を跨って実行された処理は、処理の単位量を処理時間に応じて、各集計区間に比例配分される。
【００２２】
Ｗｅｂサーバ４では、１つの処理要求に応じて、「集計区間１」と「集計区間２」とで２回に分けて処理７が行われている。「集計区間１」における処理時間は「１４ｍｓ」であり、「集計区間２」における処理時間は「１１ｍｓ」である。そこで進行の単位量「１」を２つの集計区間に比例配分すると、「集計区間１」の進行量が「０．５６」、「集計区間２」の進行量が「０．４４」となる。図３の例では、「集計区間１」と「集計区間２」との間に１つの処理要求に応じた処理７のみが実行されているため、合計進行量も、「集計区間１」が「０．５６」、「集計区間２」が「０．４４」となる。
【００２３】
Ａｐｐサーバ５では、１つの処理要求に応じて、「集計区間１」と「集計区間２」とで５回に分けて処理８が行われている。「集計区間１」における処理時間は、「１９ｍｓ」と「９ｍｓ」であり、合計「２８ｍｓ」である。「集計区間２」における処理時間は「１０ｍｓ」と「１２ｍｓ」と「２１ｍｓ」であり、合計「４３ｍｓ」である。そこで進行の単位量「１」を２つの集計区間に比例配分すると、「集計区間１」の進行量が「０．３９４」、「集計区間２」の進行量が「０．６０６」となる。図３の例では、「集計区間１」と「集計区間２」との間に１つの処理要求に応じた処理８のみが実行されているため、合計進行量も、「集計区間１」が「０．３９４」、「集計区間２」が「０．６０６」となる。
【００２４】
ＤＢサーバ６では、４つの処理要求に応じて、「集計区間１」と「集計区間２」とで、処理要求ごとに１回ずつ、計４回の処理９ａ，９ｂ，９ｃ，９ｄが行われている。２つめの処理要求に応じた処理９ｂは、「集計区間１」と「集計区間２」とに跨って実行されている。このように２つの集計区間に跨って実行された処理９ｂに関しては、処理進行の単位量「１」が、処理時間に応じて比例配分される。処理９ｂの「集計区間１」における処理時間は「１０ｍｓ」であり、「集計区間２」における処理時間は「２４ｍｓ」であり、合計「３４ｍｓ」である。そこで処理９ｂに関する進行の単位量「１」を２つの集計区間に比例配分すると、「集計区間１」の進行量が「０．２９」、「集計区間２」の進行量が「０．７１」となる。図３の例では、「集計区間１」において処理９ａが完結しており、その処理９ａの進行の単位量「１」と処理９ｂの進行量「０．２９」の合計値「１．２９」が、「集計区間１」の合計進行量となる。また「集計区間２」において処理９ｃ，９ｄが完結しており、その処理９ｃ，９ｄそれぞれの進行の単位量「１」と処理９ｂの進行量「０．７１」の合計値「２．７１」が、「集計区間２」の合計進行量となる。
【００２５】
サーバごとの各集計区間の合計処理時間は、集計区間内で処理の実行に要した時間の合計である。Ｗｅｂサーバ４では、「集計区間１」の合計処理時間は「１４ｍｓ」、「集計区間２」の合計処理時間は「１１ｍｓ」である。Ａｐｐサーバ５では、「集計区間１」の合計処理時間は「２８ｍｓ」、「集計区間２」の合計処理時間は「４３ｍｓ」である。ＤＢサーバ６では、「集計区間１」の合計処理時間は「１９ｍｓ」、「集計区間２」の合計処理時間は「３９ｍｓ」である。
【００２６】
このようにして集計された情報に基づいて、サーバごとに、合計処理時間の増加量に対する合計進行量の増加量が所定値以下となる閾値が計算される。なお、所定値としては、例えば、合計処理時間が少ない時間帯の合計処理時間の増加量に対する合計進行量の増加量の割合に、所定の係数（１より小さい値）を掛けた値とする。
【００２７】
このようにして求められた閾値よりも合計処理時間が長い集計区間が、複数のサーバそれぞれに関して検出される。例えば図３の例では、Ｗｅｂサーバ４とＤＢサーバ６とについては、合計処理時間が閾値以上となっている集計区間の、全体の集計区間に対する割合は半分以下であり、少ない。他方、Ａｐｐサーバ５については、ほとんどの集計区間において、合計処理時間が閾値以上となっている。そうすると、Ａｐｐサーバ５において処理能力の余力がなくなっており、Ｗｅｂ三階層システムにおけるボトルネックとなっていることが分かる。
【００２８】
ここで言うボトルネックとは、システム全体としての処理性能の上昇を阻害している要因のことである。またボトルネックの検出とは、複数のコンピュータが階層的に処理を分担するシステム（多階層システム）の内のどの階層に問題があって、システム全体としての性能が頭打ちになっているのかを求めることである。
【００２９】
このように、第１の実施の形態によれば、各サーバの処理能力の余力の有無を検出することができる。これにより、多階層システムにおいて、ボトルネックとなっているサーバを容易に特定できる。
【００３０】
ところで、従来は、多階層システムにおけるボトルネックとなっているサーバの検出は、難しかった。以下、多階層システムにおいて、システム全体の処理性能が限界を迎えた場合の、ボトルネックとなっているコンピュータの検出の困難性について説明する。
【００３１】
多階層システムの運用中に発生したボトルネックの検出に利用可能と考えられる技術を大別すると、下記の５通りに分類される。
・第１の手法：システムリソースの利用状況を監視する。
・第２の手法：アプリケーション内部の詳細な動作状況を監視する。
・第３の手法：コンピュータ上でアプリケーションの外部挙動（応答時間や各階層での滞在時間）を監視する。
・第４の手法：ネットワーク上でアプリケーションの外部挙動（応答時間や各階層での滞在時間）を監視する。
・第５の手法：システム運用前に予め負荷テストを行い、負荷量とスループットの関係を学習し、その知識を利用して運用中のボトルネックを特定する。
【００３２】
次に、各手法について詳細に説明する。
＜第１の手法＞
第１の手法に該当する技術は、例えば多階層システムに含まれるコンピュータ上に特定のプロセス（エージェントと呼ばれることが多い）を用意しておき、そのプロセスが様々な測定値を収集する手法である。取得する測定値の例としては、マシン全体でのＣＰＵ利用率やメモリ使用量などの、マシン単位でのシステムリソース利用状況がある。また取得する測定値の別の例としては、プロセスごとのＣＰＵ利用率やファイルオープン数などの、プロセス単位の情報がある。
【００３３】
第１の手法では、分析対象の各コンピュータ上で収集されたデータは、一旦そのコンピュータ上の記録装置へ書き出しておいて、後で分析を行うコンピュータで回収される。または分析対象のコンピュータがネットワーク経由で直接、分析を行うコンピュータに送信する。これによって、多階層システムに含まれるコンピュータ以外の特定のコンピュータに集められる。そしてデータが集められたコンピュータにおいて、多階層システム内の全コンピュータのデータを突き合わせて分析することによって、ボトルネックを検出することになる。
【００３４】
＜第２の手法＞
第２の手法に該当する技術としては、例えばアプリケーションソフトウェアの機能を利用したり、アプリケーションソフトウェアに改造を加えたりして、アプリケーションソフトウェア内部の情報を取得する手法である。取得する情報は、例えばデータベース（ＤＢ）ソフトウェアにおけるＤＢ問い合わせ処理時間、同時接続ユーザ数、各内部メソッドの開始・終了時刻などである。これらの情報は、エージェントのような別プロセスから当該ソフトウェアに問い合わせて得られる場合もあるし、当該アプリケーションソフトウェア自身がログなどの形式で出力する場合もある。
【００３５】
第２の手法においても、第１の手法と同様に、各コンピュータ上で収集されたデータは、一旦そのコンピュータ上の記録装置へ書き出しておいて、後でそのコンピュータとは別の特定のコンピュータに集められる。そしてデータが集められたコンピュータにおいて、データが分析され、ボトルネックが検出される。
【００３６】
＜第３の手法＞
第３の手法における外部挙動を監視する技術としては、応答時間を測定する手法が一般的である。応答時間は、多階層システムのあらゆる階層において測ることが考えられる。
【００３７】
第３の手法では、例えば各コンピュータ上のアプリケーションソフトウェアの機能を利用したり、アプリケーションソフトウェアに改造を加えたりすることによって、アプリケーションソフトウェアが他コンピュータとメッセージ送受を行ったことを記録する。そしてアプリケーションソフトウェアは、その中から各処理要求の受信時刻と処理結果の返信時刻を抜き出して応答時間を求める手法である。
【００３８】
第３の手法においても、第１の手法と同様に、各コンピュータ上で収集されたデータは、一旦そのコンピュータ上の記録装置へ書き出しておいて、後でそのコンピュータとは別の特定のコンピュータに集められる。そしてデータが集められたコンピュータにおいて、データが分析され、ボトルネックが検出される。
【００３９】
＜第４の手法＞
第４の手法における外部挙動を監視する技術も、第３の手法と同様、応答時間を、多階層システムの各階層において測定する手法が一般的である。第３の手法と第４の手法との違いは、応答時間の測定方法にある。
【００４０】
第４の手法では、例えば多階層システムに含まれるコンピュータには手を加えず、ネットワーク上を流れる通信パケットを、多階層システムに含まれないコンピュータで取得する。そして、通信パケットを取得したコンピュータが、取得した通信パケットから、多階層システムに含まれるコンピュータ間のメッセージ送受を解析し、それらの送受時刻から応答時間を求める。
【００４１】
第４の手法には、他の全ての手法と違って、各コンピュータ内には一切手を加えないので各コンピュータ本来の挙動に一切影響を与えないという利点がある。以下に、第４の手法をさらに詳細に説明する。コンピュータネットワーク上から通信パケットを取得する方法として、ネットワークスイッチの持つポートミラーリング機能を利用する方法がある。ポートミラーリング機能は、ネットワークスイッチ上の特定のポートを流れるＩＰ（Internet Protocol）パケットをコピーし、そのコピーを指定したポートに転送する。そのポートの先に接続したコンピュータにおいて、転送されてきたＩＰパケットをキャプチャして記録することができる。
【００４２】
こうして取得したデータは、コンピュータ間でサーバプログラム同士がやり取りするメッセージの形式ではなく、細分化されたＩＰパケットという形式である。ここからメッセージ上の情報を取得するには、まず細分化されたＩＰパケット同士を組み立て、さらにはそのパケットをメッセージのプロトコル種別に従って解析することとなる。メッセージを解析することによって、各処理の要求と、その要求に対する返信のペア（メッセージペア）を見つけだすことができる。メッセージペアが検出できれば、メッセージペアの時刻情報の差分を取れば応答時間を求めることができる。
【００４３】
さらには、各メッセージの情報から、処理要求の内容に関する情報も取得することができる。例えば、ＨＴＴＰ（HyperText Transfer Protocol）要求の場合は、取得を要求しているＵＲＬ（Uniform Resource Locator）であるとか、ＤＢ要求の場合はＳＱＬ（Structured Query Language）文などの情報である。これらの内容と応答時間とから、どのような業務処理にどれくらいの応答時間を要しているか判断することができる。この応答時間の平均値の推移を監視することによって、特定の階層でだけ応答時間が増加すれば、それはその階層下の処理に何らかの問題が発生していると考え、ボトルネック検出の手掛かりとすることができる。また、業務処理内容ごとに集計すれば、特定の業務処理の応答時間だけが低下した場合に、その業務処理に関連している部分にボトルネックが存在すると考えることもできる。
【００４４】
＜第５の手法＞
第５の手法は、事前の負荷テストによってデータ収集を行うことを前提とする。事前の負荷テストでは、例えば多階層システムに含まれないコンピュータ（負荷生成器）から多階層システムに対して運用時を模した負荷を掛ける。例えば、負荷生成器から多階層システムに、同時アクセスユーザ数を変えながら、多数のパターンの要求を入力する。そして、処理結果を観測するコンピュータにおいて、同時アクセスユーザ数ごとの多階層システムのスループットを測定する。処理結果を観測するコンピュータでは、システムに掛かる同時アクセスユーザ数とスループットの関係から、スループットが上限に達する同時アクセスユーザ数を判定し、判定した同時アクセスユーザ数を限界同時アクセスユーザ数とする。このような事前処理を行った後、その監視対象の多階層システムの運用時に同時アクセスユーザ数を監視しておき、先に得た限界同時アクセスユーザ数に達すると、システムの性能が限界に達したと判定する。
【００４５】
以上のような第１から第５の手法のいずれかを用いて多階層システムのボトルネックを検出した場合、以下のような課題が残ってしまう。
＜第１の手法の課題＞
特定のシステムリソースを消費し尽くしていない状況で発生したボトルネックは検出できない。
【００４６】
システムリソースの利用状況の監視では、ボトルネックを検出できない場合がある。これは、以下のような理由により、特定のリソースが枯渇していなくても、そのコンピュータがボトルネックとなることがあるからである。
１．ソフトウェア設定やユーザアプリ内部において、並列度を制限している場合
２．複数リソースが複合してボトルネックとなっている場合
なお第２の手法を使用して、アプリケーション内部の詳細な動作状況を監視する場合、１．の問題は解決できる可能性があるが、それも適切なデータを取得できた場合に限られる。アプリケーション内部でボトルネック要因になると考えられる要素は、一般的に非常に多く存在する。そのため、それらの全てについて網羅的に詳細な記録を取り続けることは、データの記録装置への書き出しに要する時間とシステム負荷を考えると、現実的には困難である。
【００４７】
＜第１〜第３の手法に共通の課題＞
第１〜第３の手法には、極短時間で変化するボトルネックが検出できないという問題がある。
【００４８】
各コンピュータ上でデータを測定する手法には、以下の２つの要因があって、極短い時間間隔ごとの詳細な分析を行うことが難しいという問題がある。
極短い時間間隔ごとの詳細なデータはデータ量が大きくなり、コンピュータ上の記録装置に一旦格納して後から取り出す場合においても、直接ネットワーク経由で外部へ送り出す場合においても、そのコンピュータに掛かる負担が大きくなる。そのため、データの収集処理が、コンピュータ上で動作しているアプリケーションの挙動に大きく影響を及ぼしてしまう。その結果として、そのアプリケーションの本来の挙動とは大きく異なる挙動を観測してしまうことになる。
【００４９】
コンピュータ間で時計の誤差があり、これはＮＴＰ（Network Time Protocol）等の時計同期システムを使用したとしても、数ミリ秒単位の誤差は免れない。これでは、複数コンピュータから収集したデータを付き合わせて分析する際に、タイムスタンプ間に誤差が生じていて、正しく突き合わせを実行することができず、極短い時間間隔での精密な分析はできなくなる。
【００５０】
極短い時間間隔ごとの詳細な分析を行えない結果として、例えば、一つのコンピュータ上で、測定期間より短い一瞬一瞬だけの短時間に発生しているボトルネックは、測定期間内で平均化されてしまい、その後の分析で検出できないことになる。また、複数の階層間で測定期間より短い極短時間の内にボトルネック要因が推移している場合は、同様に検出できない。
【００５１】
＜第４の手法の課題＞
アプリケーションの外部挙動を監視する第４の手法には、以下の課題がある。
応答時間／処理時間などの外部観測ではボトルネックを見誤る場合がある。このようなことは、外部観測では外面の挙動しか観測しておらず、そのような挙動が発生する原因となる内部処理については何も情報を得ていないために発生する。
【００５２】
例えば、発生しがちなケースとして次のようなことがある。ある層がボトルネックになった際に、その層に送られてくる処理要求の数が処理可能な数を超えて際限なく増加していく場合は、その階層における応答時間が大きく悪化する。しかし、その階層へ送られてくる処理要求の数が適切にコントロールされている場合は、その階層へはそれ以上処理要求が送られて来なくなる。それによって、応答時間の低下は小さく留まる。その代わりに、その層へ処理要求を送る上位の階層では、下位の階層へ処理を送るまでの待ち時間が指数関数的に増加する。外部観測で処理時間の推移を監視していると、その待ち時間の増加と純粋な処理時間の増加の区別が付かないために、あたかもその待ち時間が増加した階層にボトルネックが存在するかのように誤認してしまう。
【００５３】
＜第５の手法の課題＞
システム運用前に予め負荷テストを行い、負荷量とスループットの関係を学習し、その知識を利用して運用中のボトルネックを特定する第５の手法には、以下の課題がある。
【００５４】
第５の手法を多階層システムに適用する場合、多階層システムの最上段に掛かる多重度（同時アクセスユーザ数）と、その時のスループットは測定できても、階層ごとの多重度・スループットの関係は測定できないという問題がある。また、このような手法では、システムに掛かる多重度を変化させるために負荷生成器の発生する負荷量を変化させながら、何回も測定し直す必要がある。さらには、多階層システムの場合は、各階層のコンピュータの台数を動的に変更すること（スケールアウト）があり、その考えられる全ての構成について、このような事前測定を行っておくのは困難である。さらに、多階層システムにおいて各階層に掛かる負荷は、そのシステム上で動く複数種類の処理の混合割合やその実行タイミングによっても変わってくる。その全ての組み合わせを事前にテストして完全なデータを揃えておくことは、非常に困難で現実的ではない。
【００５５】
また、同様の手法を最上段以外の階層に直接適用して、負荷生成器から中間階層へ直接負荷を掛けて、多重度とスループットの関係を測定しようとすると、実環境に即した負荷をどのようにして生成するかという非常に困難な問題が発生する。現在の多階層システムは挙動が非常に複雑で、各階層が上位層からある処理を受けた際に下位層へどのようなタイミングでどのような負荷を発行するかは、アプリケーションのプログラム内容だけでなく、ハードウェア構成やＯＳ実装を含む種々の要因が複雑に絡んで決まる。そのため、負荷の生成要因を正確に理解して再現することは非常に困難であり、現実的ではない。
【００５６】
よって、第５の手法は、システム運用前のテスト手法としては利用できるが、実運用中に発生した性能問題の原因分析（ボトルネック特定）には利用できない。
以上のように、第１〜第５の手法では、いずれも課題があり、多階層システムのボトルネックを適切に検出するのが難しかった。
【００５７】
第１の実施の形態に示した手法では、精密なメッセージ送受時刻の記録などの情報から、各階層における処理の合計進行量と合計処理時間を算出し、その関係を動的に求め、そこからボトルネック判定を行うことを可能とする。これにより、各階層のサーバが処理性能の限界まで使用されているのかどうかを正確に把握することができ、上記課題も解消可能である。
【００５８】
例えば、第１の実施の形態では、各サーバのシステムリソースの消費状況の情報ではなく、各サーバの処理の実行期間を示す情報に基づいてボトルネックを検出できる。そのため、上記第１の手法の「特定のシステムリソースを消費し尽くしていない状況で発生したボトルネックは検出できない」という課題は解消している。
【００５９】
また第１の実施の形態では、分析対象期間を細分化した集計区間単位で、合計処理時間が閾値以上か否かを判断する。そのため上記第１〜第３の手法における「極短時間で変化するボトルネックが検出できない」という課題も解決されている。
【００６０】
また第１の実施の形態では、合計処理時間と合計進行量という２つの測定値からボトルネックを判定している。一方で、上記第４の手法は、それら２つの測定値からも算出可能な応答時間／処理時間という単一の測定値からボトルネックの検出を行っている。第４の手法の課題「応答時間／処理時間などの外部観測ではボトルネックを見誤る場合がある」の原因の大きな要素は、単なる下位の階層のサーバからの応答待ち時間の増加をボトルネックと見誤る可能性があることである。第１の実施の形態では、合計処理時間と合計進行量という２つの測定値から二次元の関係を利用してボトルネック判定を行っているため、単なる下位の階層のサーバからの応答待ち時間の増加をボトルネックと見誤る可能性が、抑止されている。
【００６１】
また第１の実施の形態では、各階層のサーバごとにボトルネックの発生の有無を検出できる。そのため、上記第５の手法の課題「階層ごとの多重度・スループットの関係は測定できない」について解消している。
【００６２】
なお、図１に示した監視手段１ａ、計算手段１ｃ、決定手段１ｄ、および検出手段１ｅは、情報処理装置１が有するＣＰＵ（Central Processing Unit）により実現することができる。また、記憶手段１ｂは、情報処理装置１が有するＲＡＭ（Random Access Memory）やハードディスクドライブ（ＨＤＤ:Hard Disk Drive）などにより実現することができる。
【００６３】
また、図１に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。
〔第２の実施の形態〕
次に第２の実施の形態について説明する。第２の実施の形態は、ネットワーク上でのアプリケーションの外部挙動を観測するアプローチを採用する。第２の実施の形態では、スイッチングハブのポートミラーリング機能を使ってネットワークを流れるＩＰパケットをキャプチャし、そこからプロトコルメッセージを再現することによって情報を得る。ここで、プロトコルメッセージは、所定のプロトコルに準拠した情報である。以下、プロトコルメッセージを、単に「メッセージ」と呼ぶ。
【００６４】
なお、コンピュータの単位時間当たりの処理能力は、スループットと呼ばれる。そこで、第２の実施の形態では、第１の実施の形態に示した合計進行量に相当する値を、スループットと呼ぶこととする。
【００６５】
また第２の実施の形態では、第１の実施の形態における合計処理時間を、集計区間の長さで除算することで、集計区間内の処理の多重度の平均値を求め、集計区間内の多重度とする。各集計区間の長さは同じである。そのため、第１の実施の形態で示した性能分析における合計処理時間に代えて多重度を用いても、分析結果に影響はない。そこで第２の実施の形態では、集計区間の多重度を用いて、装置の性能の余力などの分析を行うものとする。
【００６６】
また第２の実施の形態では、複数階層システムとしてＷｅｂ３階層システムを例として説明する。Ｗｅｂ３階層システムとは、Ｗｅｂサーバ、アプリケーションサーバ（以降、Ａｐｐサーバ）、データベースサーバ（以降、ＤＢサーバ）からなる複数階層コンピュータシステムである。エンドユーザのコンピュータ上のブラウザが出力する処理要求は、ＷｅｂサーバがＨＴＴＰに従ったメッセージで受ける。処理要求が静的コンテンツの取得であれば、Ｗｅｂサーバが、保持しているコンテンツを直接エンドユーザのコンピュータへ返信する。他方、処理要求がプログラムによって生成される動的コンテンツの取得の場合、Ｗｅｂサーバは、処理をＡｐｐサーバへ依頼する。処理の依頼を受けたＡｐｐサーバは、Ｊａｖａ（登録商標）などで記述されたプログラムによってその処理要求を実行する。Ａｐｐサーバは、処理の過程において使用されるデータを、それを保持するＤＢサーバに対して処理要求を発行して取得する。
【００６７】
図４は、第２の実施の形態の業務システムの全体構成を示す図である。この業務システムは、分析サーバ１００、Ｗｅｂサーバ２００、Ａｐｐサーバ３００およびＤＢサーバ４００を有する。分析サーバ１００、Ｗｅｂサーバ２００、Ａｐｐサーバ３００およびＤＢサーバ４００は、スイッチ装置１０を介して相互に接続されている。また、スイッチ装置１０は、ネットワーク２０を介して端末装置２１，２２，２３に接続されている。
【００６８】
端末装置２１，２２，２３は、スイッチ装置１０およびネットワーク２０を介してＷｅｂサーバ２００にアクセス可能である。端末装置２１，２２，２３のユーザは、Ｗｅｂサーバ２００が提供するＧＵＩ（Graphical User Interface）を端末装置２１，２２，２３から操作して業務システムを利用できる。ネットワーク２０は、例えばイントラネットである。
【００６９】
なお、ネットワーク２０がインターネットである場合も考えられる。その場合、スイッチ装置１０はファイアウォールとして機能させることもできる。また、Ｗｅｂサーバ２００の属するネットワークセグメントは、例えばＤＭＺ（Demilitarized Zone）として扱われる。
【００７０】
分析サーバ１００は、Ｗｅｂサーバ２００、Ａｐｐサーバ３００およびＤＢサーバ４００の稼働状況を管理する。分析サーバ１００は、そのための情報をスイッチ装置１０から取得することができる。すなわち、スイッチ装置１０は、ポートミラーリング機能を有しており、Ｗｅｂサーバ２００、Ａｐｐサーバ３００およびＤＢサーバ４００の間で送受信される通信パケットを分析サーバ１００にも送信する。ポートミラーリング機能とは、スイッチ装置１０上の設定したポートを流れるＩＰパケットをコピーして、指定した別のポートへ転送する機能である。この転送先として指定されたポートの先に、ＩＰパケット記録や解析を行う分析サーバ１００が配置される。
【００７１】
分析サーバ１００は、スイッチ装置１０から送信される通信パケットを受信して、記憶する（パケットキャプチャ）。なお、分析サーバ１００で単にパケットキャプチャを行う用途であれば、スイッチ装置１０をリピータハブで代用することもできる。分析サーバ１００は、この転送されてくるＩＰパケットを受信可能なネットワークインタフェースを有している。そして分析サーバ１００は、転送されてきたＩＰパケット格納用の十分に大きなハードディスクを有している。さらに、分析サーバ１００は、ＩＰパケットをキャプチャするのに十分なＣＰＵ性能を保有していることが望ましい。転送されてきたＩＰパケットは、分析サーバ１００上でキャプチャされ、その後にメッセージを抽出するための処理が実施される。
【００７２】
Ｗｅｂサーバ２００は、端末装置２１，２２，２３で実行されるＷｅｂブラウザから業務システムに対する処理要求（メッセージ）を受け付ける。ここで、Ｗｅｂサーバ２００と端末装置２１，２２，２３とのメッセージ交換は、ＨＴＴＰによって行われるものとする。ただし、他のプロトコルが用いられてもよい。
【００７３】
以下では、端末装置２１，２２，２３からＷｅｂサーバ２００へ送信する処理要求をＨＴＴＰリクエストと呼ぶこととする。また、それに対する応答をＨＴＴＰレスポンスと呼ぶこととする。なお、リクエスト／レスポンスともに処理要求の一例である。
【００７４】
Ｗｅｂサーバ２００は、端末装置２１，２２，２３から受信したＨＴＴＰリクエストに基づいて、静的コンテンツに関しては自装置でＨＴＴＰレスポンスを生成し、端末装置２１，２２，２３に送信する。なお、動的コンテンツに関しては、Ａｐｐサーバ３００に依頼すべき処理の処理要求（メッセージ）を生成して、Ａｐｐサーバ３００に送信する。
【００７５】
ここで、Ｗｅｂサーバ２００とＡｐｐサーバ３００とのメッセージ交換は、ＩＩＯＰ（Internet Inter-ORB（Object Request Broker） Protocol）によって行われるものとする。ただし、他のプロトコルが用いられてもよい。
【００７６】
以下では、Ｗｅｂサーバ２００からＡｐｐサーバ３００へ送信する処理要求をＩＩＯＰリクエストと呼ぶこととする。また、それに対する応答をＩＩＯＰレスポンスと呼ぶこととする。
【００７７】
Ｗｅｂサーバ２００は、ＩＩＯＰリクエストに対するＩＩＯＰレスポンスを受信すると、その内容に基づいてＨＴＴＰレスポンスを生成して、端末装置２１，２２，２３に送信する。
【００７８】
Ａｐｐサーバ３００は、Ｗｅｂサーバ２００から受信したＩＩＯＰリクエストに基づいてＤＢサーバ４００に依頼すべき処理のクエリを生成し、ＤＢサーバ４００に送信する。
ここで、Ａｐｐサーバ３００が生成するクエリは、例えばＳＱＬ文によって表記され、ＤＢサーバに固有のプロトコルでＤＢサーバへと送信される。以下では、Ａｐｐサーバ３００がＤＢサーバ４００に送信するクエリをＤＢリクエストと呼ぶこととする。また、それに対する応答をＤＢレスポンスと呼ぶこととする。
【００７９】
Ａｐｐサーバ３００は、ＤＢリクエストに対するＤＢレスポンスを受信すると、その内容に基づいてＩＩＯＰレスポンスを生成してＷｅｂサーバ２００に送信する。
ＤＢサーバ４００は、Ａｐｐサーバ３００から受信したＤＢリクエストに含まれるＳＱＬ文を実行してＤＢの参照や更新等の処理を実行する。ＤＢサーバ４００は、その処理結果に基づいてＤＢレスポンスを生成し、Ａｐｐサーバ３００に送信する。
【００８０】
なお、業務システムにおいてＷｅｂサーバ２００、Ａｐｐサーバ３００およびＤＢサーバ４００と各層（Ｗｅｂ層、Ａｐｐ層およびＤＢ層）一台ずつの構成を例示したが、各層にそれぞれ複数台のサーバを設けてもよい。各層に複数のサーバがある場合、各層において負荷分散処理が行われる。
【００８１】
階層間を跨って送受信されるメッセージを取得する手法には何通りか考えられるが、第２の実施の形態では、ネットワーク上を流れるＩＰパケットから情報を取得するものとする。この場合、ポートミラーリング機能を有するスイッチ装置１０が用いられる。
【００８２】
また、以下では各サーバという場合、Ｗｅｂサーバ２００、Ａｐｐサーバ３００およびＤＢサーバ４００を示すものとする。さらに、Ｗｅｂサーバ２００は、Ａｐｐサーバ３００およびＤＢサーバ４００よりも上位層のサーバであるとする。また、Ａｐｐサーバ３００は、ＤＢサーバ４００よりも上位層のサーバであるとする。このような階層関係を定義する情報は、分析サーバ１００に予め格納される。
【００８３】
図５は、第２の実施の形態に用いるコンピュータのハードウェアの一構成例を示す図である。分析サーバ１００は、ＣＰＵ１０１、ＲＯＭ（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）のアクティビティ図で用いられる同期バー３１，３２を用いて、並列処理を表している。同期バー３１は、特にフォークと呼ばれ、１つの処理が２つ以上の並列処理に分割されることを示す。同期バー３２は、特にジョインと呼ばれ、２つ以上の処理の流れを１つに統合することを示す。
【０１０９】
以下、図７に示す処理をステップ番号に沿って説明する。
［ステップＳ１０１］キャプチャ部１１１は、スイッチ装置１０のミラーポートから出力されたＩＰパケットをキャプチャする。キャプチャ部１１１は、例えばキャプチャしたＩＰパケットを、一時的にＲＡＭ１０３に格納する。この際、キャプチャ部１１１は、受信したＩＰパケットに受信時刻を付与する。
【０１１０】
［ステップＳ１０２］キャプチャ部１１１は、キャプチャの開始、またはキャプチャデータの前回のファイル出力から、所定のファイル出力周期が経過したか否かを判断する。ファイル出力周期は、例えば１８０秒といった値が予めキャプチャ部１１１に設定されている。キャプチャ部１１１は、ファイル出力周期が経過した場合、処理をステップＳ１０３に進める。またキャプチャ部１１１は、ファイル出力周期が経過していなければ、処理をステップＳ１０１に進め、ＩＰパケットのキャプチャを継続する。
【０１１１】
［ステップＳ１０３］キャプチャ部１１１は、ＲＡＭ１０３などに一時的に保管してあるキャプチャデータを、ファイル１１２ａに出力する。例えばキャプチャ部１１１は、新規のファイルを作成し、作成したファイル１１２ａにキャプチャデータを出力する。そしてキャプチャ部１１１は、キャプチャデータを含むファイルをキャプチャデータ記憶部１１２に格納する。
【０１１２】
［ステップＳ１０４］キャプチャ部１１１は、停止コマンドが入力されたか否かを判断する。停止コマンドは、例えば管理者が、キーボード１２やマウス１３を操作して分析サーバ１００に入力する。キャプチャ部１１１は、停止コマンドが入力された場合、キャプチャ処理を終了する。またキャプチャ部１１１は、停止コマンドが入力されていなければ、処理をステップＳ１０１に進める。
【０１１３】
このようにして、ファイル出力周期ごとにキャプチャしたデータを含むファイル１１２ａが生成され、順次キャプチャデータ記憶部１１２に格納される。
［ステップＳ１０５］メッセージ解析部１２１は、キャプチャデータ記憶部１１２から、性能分析処理を行っていない、未処理のファイル１１２ａがあるか否かを判断する。未処理のファイルは、キャプチャ部１１１により、ファイル出力周期で定期的にキャプチャデータ記憶部１１２に順次格納されている。従って、メッセージ解析部１２１は、ファイル出力周期で、未処理のファイルを検出できる。
【０１１４】
［ステップＳ１０６］メッセージ解析部１２１は、キャプチャデータ記憶部１１２内の未処理のファイル１１２ａからキャプチャデータを読み込む。
［ステップＳ１０７］分析サーバ１００内の各機能が連携して性能分析を行う。この処理の詳細は後述する。
【０１１５】
［ステップＳ１０８］メッセージ解析部１２１は、停止コマンドが入力されたか否かを判断する。停止コマンドは、例えば管理者が、キーボード１２やマウス１３を操作して分析サーバ１００に入力する。メッセージ解析部１２１は、停止コマンドが入力された場合、分析処理を終了する。またメッセージ解析部１２１は、停止コマンドが入力されていなければ、処理をステップＳ１０５に進める。
【０１１６】
このように、キャプチャされたデータは、一定時間分（例えば１８０秒間）だけ貯められて、一定時間間隔で、その一定時間分のデータを使用して性能分析処理が行われる。このとき、データの収集処理（ステップＳ１０１〜Ｓ１０４）と性能分析処理（ステップＳ１０７）は切り離して非同期で行ってもよい。ただし、ボトルネック発生をリアルタイムに監視するためには、図７に示すようにデータの収集処理（ステップＳ１０１〜Ｓ１０４）と性能分析処理（ステップＳ１０７）を同期して動作させ、収集されたデータをすぐに処理するのが理想的である。
【０１１７】
図８は、キャプチャデータ記憶部のデータ構造の一例を示す図である。キャプチャデータ記憶部１１２には、複数のファイル１１２ａ，１１２ｂ，１１２ｃ，・・・が格納されている。
【０１１８】
ファイル１１２ａには、複数のＩＰパケット１１２ｄ−１〜１１２ｄ−７が含まれている。またＩＰパケット１１２ｄ−１〜１１２ｄ−７それぞれには、受信時刻１１２ｅ−１〜１１２ｅ−７が付与されている。他のファイル１１２ｂ，１１２ｃ，・・・も、ファイル１１２ａと同様に、受信時刻が付与されたＩＰパケットを含んでいる。
【０１１９】
次に、性能分析処理について詳細に説明する。
図９は、性能分析処理の手順を示すフローチャートである。以下、図９に示す処理をステップ番号に沿って説明する。
【０１２０】
［ステップＳ１１１］メッセージ解析部１２１は、取得したファイルに含まれるＩＰパケットに基づいて、メッセージを再構築する。メッセージ解析部１２１は、再構築したメッセージを、メッセージデータ記憶部１２２に時系列に格納する。
【０１２１】
［ステップＳ１１２］メッセージフロー検出部１３２は、メッセージデータ記憶部１２２に格納されたメッセージから、一つの業務処理リクエストに応じて多階層システム内で発行された一連のメッセージ送受関係を示すメッセージフローを検出する。
【０１２２】
第２の実施の形態では、メッセージは階層ごとに異なるプロトコルが使われている。端末装置２１〜２３からの一つのリクエストに関連して、多階層システム内の各階層で発行される異なるプロトコルのメッセージ間には、それらを関連付けるための情報が含まれていない場合が多い。そこで第２の実施の形態では、これらの異なるプロトコル間のメッセージを、既知のモデルと照合することで関連付ける。例えばメッセージフロー検出部１３２は、予め用意されたメッセージフローのモデルと、メッセージデータ記憶部１２２に格納されたメッセージとを比較し、モデルに合致するメッセージの組み合わせを作成する。そしてメッセージフロー検出部１３２は、作成されたメッセージの組み合わせをメッセージフローとする。
【０１２３】
［ステップＳ１１３］メッセージフロー検出部１３２は、検出したメッセージフローに含まれるリクエストメッセージに応じて、各階層のサーバで実行される処理のジョブ種を判定する。例えばメッセージフロー検出部１３２は、抽象化ルール記憶部１３１に格納されている抽象化ルールに従って、リクエストメッセージを抽象化する。そしてメッセージフロー検出部１３２は、抽象化後の内容が同じリクエストメッセージ同士をまとめて、１つのジョブ種とする。検出されたジョブ種には、識別名（ジョブ種名）が付与される。
【０１２４】
そしてメッセージフロー検出部１３２は、リクエストメッセージにジョブ種名が付与されたメッセージフローを、メッセージフロー情報記憶部１３３に格納する。
［ステップＳ１１４］飽和多重度決定部１４４は、未処理の階層を選択する。例えば飽和多重度決定部１４４には、多階層システムを構成する各階層のサーバに入力するリクエストメッセージのプロトコル名が予め設定されている。Ｗｅｂ３階層であれば、例えばプロトコル名「ＨＴＴＰ」、「ＩＩＯＰ」、「ＤＢ」の各プロトコル名が飽和多重度決定部１４４に設定されている。飽和多重度決定部１４４は、設定されているプロトコル名に対応する階層を順に選択する。
【０１２５】
［ステップＳ１１５］飽和多重度決定部１４４と分析部１４５とが連携し、選択したプロトコル名に対応する階層の性能分析処理を行う。この処理の詳細は後述する（図１６参照）。
【０１２６】
［ステップＳ１１６］飽和多重度決定部１４４は、全ての階層について階層別の性能分析処理を実行したか否かを判断する。例えば飽和多重度決定部１４４は、予め設定されているプロトコル名で示される全ての階層が選択済みであれば、未処理の階層なしと判断する。未処理の階層がある場合、飽和多重度決定部１４４は、処理をステップＳ１１４に進める。未処理の階層がなければ、飽和多重度決定部１４４は、性能分析処理を終了する。
【０１２７】
このように、性能分析処理では、まずメッセージが再構築され、メッセージデータ記憶部１２２に格納される。
図１０は、メッセージデータ記憶部のデータ構造の一例を示す図である。メッセージデータ記憶部１２２には、復元された複数のメッセージが、時系列に格納されている。このように時系列に並べられたメッセージが、時系列データである。図１０では、各メッセージの左に、メッセージデータ記憶部１２２内での行番号を示している。なお、メッセージデータ記憶部１２２には、各階層間の処理要求および応答に関連するメッセージ以外のメッセージに関しては図示を省略している。
【０１２８】
各行に示されるメッセージには、日付フィールド１２２ａ、時刻フィールド１２２ｂ、セッション番号フィールド１２２ｃ、送信元アドレスフィールド１２２ｄ、送信先アドレスフィールド１２２ｅ、コマンド種別フィールド１２２ｆおよびメッセージフィールド１２２ｇが含まれる。
【０１２９】
日付フィールド１２２ａは、メッセージをキャプチャした日付を示すフィールドである。
時刻フィールド１２２ｂは、メッセージをキャプチャした時刻を示すフィールドである。
【０１３０】
セッション番号フィールド１２２ｃは、業務システムにおけるメッセージの送受信に用いるリソースを管理するためのセッション番号を示すフィールドである。
送信元アドレスフィールド１２２ｄは、メッセージの送信元のコンピュータのＩＰアドレスおよびポート番号を示すフィールドである。
【０１３１】
送信先アドレスフィールド１２２ｅは、メッセージの送信先のコンピュータのＩＰアドレスおよびポート番号を示すフィールドである。
コマンド種別フィールド１２２ｆは、コマンドのリクエスト／レスポンス属性やプロトコル（ＨＴＴＰ、ＩＩＯＰおよびＤＢクエリ用等）の種別を示すフィールドである。
【０１３２】
メッセージフィールド１２２ｇは、コマンド種別フィールド１２２ｆに示されたリクエスト等のメッセージ内容を示すフィールドである。
このようなメッセージデータ記憶部１２２内のメッセージを参照することで、何れのサーバに対して、どのようなメッセージが送信されたかを検出することができる。
【０１３３】
ここで、メッセージデータ記憶部１２２内のメッセージ中のその他のＩＰアドレスと各装置との対応関係は次の通りである。
“１９４．２３．５．２２６”は、Ｗｅｂサーバ２００のＩＰアドレスを示す。“１９４．２３．７．１６８”は、Ａｐｐサーバ３００のＩＰアドレスを示す。“１９４．２３．８．１９８”は、ＤＢサーバのＩＰアドレスを示す。“１９４．１８５．３９．２４”は、端末装置２２のＩＰアドレスを示す。
【０１３４】
なお、日付フィールド１２２ａおよび時刻フィールド１２２ｂの情報として、メッセージ解析部１１０が通信パケットをキャプチャしたタイミングにおけるタイムスタンプを設定するものとしたが、設定方法はこれに限らない。例えば、通信パケット中に各サーバにおけるパケットの生成時刻や送信時刻の情報が含まれている場合には、その日時を日付フィールド１２２ａおよび時刻フィールド１２２ｂの情報としてもよい。その場合、各サーバで精度良く時刻同期が行われていることが望ましい。
【０１３５】
メッセージが再構築されると、メッセージフロー検出部１３２は、検出されたメッセージフロー内のリクエストメッセージに関し、そのリクエストメッセージによって実行されるジョブのジョブ種を識別する。ここでいうジョブ種は、同様の処理内容のリクエストをグループ化したものである。メッセージフロー検出部１３２は、ジョブ種を識別する場合、抽象化ルール記憶部１３１に設定された抽象化ルールに基づいて、リクエストメッセージを抽象化する。
【０１３６】
図１１は、抽象化ルール記憶部のデータ構造の一例を示す図である。抽象化ルール記憶部１３１には、プロトコルごとの抽象化ルールが格納されている。
例えばプロトコルがＨＴＴＰのメッセージの場合は、メッセージフロー検出部１３２は、コマンド名と、ＵＲＬ内のローカルアドレス部分に、残すべきと指定されたＣＧＩ（Common Gateway Interface）パラメータを連結したもので、ジョブ種を区別する。コマンド名は、ＧＥＴやＰＯＳＴ等である。ＵＲＬ内のローカルアドレス部分は、ＵＲＬから“プロトコル名://ホスト名:ポート番号”の部分を削除したものである。そしてＨＴＴＰ用の抽象化ルール１３１ａには、残すべきＣＧＩパラメータが定義されている。例えば、図１１の例では、「type」、「comment＿table」の各パラメータを残し、他のパラメータは削除することが示されている。
【０１３７】
またＤＢプロトコルのメッセージの場合は、メッセージフロー検出部１３２は、使用するＤＢプロトコル固有のコマンド名とＳＱＬ文とを、正規表現で記述したルールで置換する。そしてメッセージフロー検出部１３２は、置換によって抽象化されたメッセージによりジョブ種を区別する。ＤＢプロトコル用の抽象化ルール１３１ｂには、正規表現を用いた置換規則が定義されている。図１１の例では、Ｐｅｒｌと同じ記法による置換規則が定義されている。例えば１行目の置換規則「s/INSERT INTO ([^ \(]+).*/INSERT INTO $1 VALUES (..)/」の先頭の「s」は、置換処理であることを示している。最初の「/」と２つめの「/」で囲われた文字列「INSERT INTO ([^ \(]+).*」が、置換元の文字列である。また２つめの「/」と３つめの「/」で囲われた文字列「INSERT INTO $1 VALUES (..)」が、置換後の文字列である。置換元の文字列の「(」と「)」とで囲われた文字列は、変数として記憶される。１行目の置換規則の「(」、「)」で囲われた文字列「[^ \(]+」は、「(」以外の文字の１回以上の繰り返しが、正規表現で示されている。「(」と「)」とで囲われた文字列は、左から順に記憶される。ｎ番目に記憶された文字列には、「$n」（ｎは、１以上の整数）という変数名が与えられる。変数に記憶された文字列は、置換後の文字列内に、変数名で指定された位置に挿入される。
【０１３８】
このような抽象化ルールに従ってリクエストメッセージが抽象化される。そして、抽象化された後の内容が同じリクエストメッセージ同士が、同じジョブ種となる。
図１２は、ＨＴＴＰのプロトコルのジョブ種の例を示す図である。図１２の例では、ＨＴＴＰのプロトコルに関するジョブ種名に対応付けて、コマンド名と、抽象化されたジョブ内容とが示されている。例えば、ジョブ種名「Ｗ１」のジョブ種は、コマンド名「GET」であり、ジョブ内容が「/RUBBOS/SERVLET/EDU.RICE.RUBBOS.SERVLETS.STORIESOFTHEDAY」である。
【０１３９】
図１３は、ＤＢのプロトコルのジョブ種の例を示す図である。図１３の例では、ＤＢのプロトコルに関するジョブ種名に対応付けて、コマンド名と、抽象化されたジョブ内容とが示されている。例えば、ジョブ種名「Ｄ１」のジョブ種は、コマンド名「EXECREADREQ」であり、ジョブ内容が「SELECT .. FROM STORIES, USERS WHERE ..」である。
【０１４０】
メッセージの抽象化が終了すると、メッセージフロー検出部１３２によりメッセージ同士の関連付けが行われ、関連付けられたメッセージを時系列に並べたメッセージフローが検出される。メッセージフローは、各階層のプロトコル間のメッセージにおいて、同一のトランザクションによって発行された関連するメッセージ同士を紐付けたものである。例えば上位層のプロトコルによって、その下の階層のサーバに送られたメッセージと、その処理に伴って生成された下位層のプロトコルのメッセージとの間が紐付けされる。このようなメッセージ間の紐付けを全ての階層のプロトコル間で行うことによって、最上位層から最下位層までの間で、一連のトランザクションを構成する全てのメッセージ送受の関係が再現される。このようなメッセージフローの検出方法として、例えば特開２００６−０１１６８３号公報に記載の方法を利用することができる。
【０１４１】
図１４は、ジョブ種が識別されたメッセージフローの一例を示す図である。なお図１４では、各サーバがジョブに関する処理を実行している期間を実線で示し、ジョブに関する処理を実行していない期間を破線で示している。サーバがジョブに関する処理を実行していない期間とは、例えば、下位層のサーバにリクエストメッセージを送信し、そのリクエストメッセージに対するレスポンスメッセージを待っている期間である。
【０１４２】
図１４の例では、Ｗｅｂサーバ２００では、ＨＴＴＰリクエストメッセージ４１に応じて、ジョブ種「Ｗ１」のジョブ６１が実行されている。Ｗｅｂサーバ２００は、ジョブ種「Ｗ１」のジョブ６１の実行途中で、Ａｐｐサーバ３００に対してＩＩＯＰリクエストメッセージ４２を送信している。
【０１４３】
Ａｐｐサーバ３００では、ＩＩＯＰリクエストメッセージ４２に応じて、ジョブ種「Ａ１」のジョブ６２が実行されている。Ａｐｐサーバ３００は、ジョブ種「Ａ１」のジョブ６２の実行途中で、ＤＢサーバ４００に対してＤＢリクエストメッセージ４３を送信している。
【０１４４】
ＤＢサーバ４００では、ＤＢリクエストメッセージ４３に応じて、ジョブ種「Ｄ１」のジョブ６３が実行されている。ＤＢサーバ４００は、ジョブ種「Ｄ１」のジョブ６３の実行が終了すると、Ａｐｐサーバ３００に対してＤＢレスポンスメッセージ４４を送信している。
【０１４５】
以後、Ａｐｐサーバ３００からＤＢサーバ４００へのＤＢリクエストメッセージ４５，４７，４９の送信と、ＤＢサーバ４００からＡｐｐサーバ３００へのレスポンスメッセージ４６，４８，５０とが繰り返し行われる。ＤＢサーバ４００では、ＤＢリクエストメッセージ４５，４７，４９に応じたジョブ６４〜６６が実行されている。
【０１４６】
Ａｐｐサーバ３００では、ＤＢレスポンスメッセージ５０に応じて、ジョブ種「Ａ１」のジョブ６２の実行が再開されている。Ａｐｐサーバ３００は、ジョブ種「Ａ１」のジョブ６１の処理が終了すると、Ｗｅｂサーバ２００に対してＩＩＯＰレスポンスメッセージ５１を送信している。Ｗｅｂサーバ２００では、ＩＩＯＰレスポンスメッセージ５１に応じて、ジョブ種「Ｗ１」のジョブ６１の実行が再開されている。Ｗｅｂサーバ２００は、ジョブ種「Ｗ１」のジョブ６１の処理が終了すると、ＨＴＴＰリクエストメッセージ４１を送信した端末装置に対してＨＴＴＰレスポンスメッセージ５２を送信している。
【０１４７】
メッセージフロー検出部１３２は、ジョブ種を識別したメッセージフローに関するメッセージフロー情報を、メッセージフロー情報記憶部１３３に格納する。
図１５は、メッセージフロー情報記憶部のデータ構造の一例を示す図である。メッセージフロー情報記憶部１３３には、トランザクションごとのメッセージフロー情報１３３ａ，１３３ｂ，１３３ｃ，・・・が格納されている。
【０１４８】
メッセージフロー情報１３３ａには、項番を示す項目、時刻を示す項目、セッション番号を示す項目、プロトコルを示す項目、Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅを示す項目、およびジョブ種を示す項目が設けられている。各項目の横方向に並べられた情報同士が互いに関連付けられて、１つのメッセージに関する情報を示す。
【０１４９】
項番を示す項目には、レコードを識別する番号が設定される。時刻を示す項目には、メッセージに対応する通信パケットをキャプチャした時刻が設定される。セッション番号を示す項目には、メッセージを送信するために用いられたセッションを識別するセッション番号が設定される。プロトコルを示す項目には、メッセージが何れのプロトコルによるものかを示す情報が設定される。Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅを示す項目には、そのメッセージがリクエスト／レスポンスの何れのものであるかを示す情報が設定される。ジョブ種を示す項目には、リクエストメッセージで要求している処理のジョブ種の名称（ジョブ種名）が設定される。 メッセージフロー情報１３３ａには、例えば、項番が“１”、時刻が“０１：５８：１９．９８７”、セッション番号が“１５２２９０”、プロトコルが“ＨＴＴＰ”、Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅが“Ｒｅｑｕｅｓｔ”、ジョブ種“Ｗ１”という情報が設定される。
【０１５０】
図１５の例では、時刻には、ミリ秒までの時間単位で設定している。この点、さらに短い時間単位（例えば、マイクロ秒単位）で時刻を取得してもよい。また、セッション番号には図１０に示したセッション番号フィールド１２２ｃに含まれる情報のうち、リクエスト／レスポンスの組を特定するために必要な最低限の情報を設定している。以下、セッション番号という場合、メッセージフロー情報１３３ａのセッション番号を示す項目に設定された情報を示すものとする。
【０１５１】
メッセージフロー情報には、各メッセージの通信時刻が設定されている。すなわち、キャプチャしたパケットに基づいて、メッセージフローを構成する各メッセージの通信時刻が測定されている。また、ある階層へ処理要求のメッセージが到着して、その処理に関連して下位層へ処理を要求するメッセージが送信された場合に、それらの間の関連付けは、メッセージフロー内の連続するメッセージに基づいて判断できる。すなわち、プロトコル「ＩＩＯＰ」のリクエストメッセージの後に、プロトコル「ＤＢ」のリクエストメッセージがあれば、「ＩＩＯＰ」のリクエストメッセージに関連して「ＤＢ」のリクエストメッセージが出力されたことが分かる。また、上位層のリクエストメッセージからレスポンスメッセージまでの時間帯内の下位層の各リクエストメッセージは、その上位層のリクエストメッセージに応じて実行された処理に関連して実行されていることが分かる。
【０１５２】
このように第２の実施の形態では、ネットワーク上を流れるＩＰパケットをキャプチャして、そこからメッセージ送受の情報を取得することで、一連の処理を示すメッセージフロー情報を生成している。この方法の利点としては、観測対象のシステムに余計な負荷を与えないので正確な挙動を観測できるということがある。また、１か所のサーバでキャプチャしてその際にタイムスタンプを付与できるのでサーバ間の時計誤差を気にしなくてよいという利点もある。
【０１５３】
なお第２の実施の形態では、各メッセージ上にそれらを関連付ける情報が付加されてない場合を想定している。そのため、メッセージフロー検出部１３０によるトランザクションモデルとの適合の有無の判定などが行われている。他方、各メッセージ上にそれらを関連付ける情報が付加されている場合もあり得る。例えば、最上位のサーバ（Ｗｅｂサーバ２００）に入力されたリクエストメッセージに応じて実行されるトランザクションの識別情報が、そのトランザクションで通信される各メッセージに付与しているような場合である。このような場合、メッセージフロー検出部１３０は、同一の識別情報が付与されたメッセージを抽出して、メッセージフローを生成することができる。
【０１５４】
なお、第２の実施の形態では、特開２００６−０１１６８３号公報に記載の方法を利用してメッセージフロー情報を作成しているが、メッセージフロー情報の作成手法は特開２００６−０１１６８３号公報に記載の方法に限定されるものではない。すなわち、個々の業務処理に関する複数階層間を跨った一連のメッセージフローを測定し、その中での各メッセージの正確な送受時刻を取得する手法は何通りか考えられる。
【０１５５】
他の方法としては、例えば、Ｗｅｂ３階層システムを構成する各Ｗｅｂサーバ２００、Ａｐｐサーバ３００、およびＤＢサーバ４００でファイルなどに記録したメッセージ送信／受信ログを利用する方法がある。この方法を適用する場合、Ｗｅｂサーバ２００、Ａｐｐサーバ３００、およびＤＢサーバ４００が、受信メッセージとその処理に関連した送信メッセージの関連付けを行い、ログ情報としてＨＤＤなどの記録装置に記録する。分析サーバ１００は、Ｗｅｂサーバ２００、Ａｐｐサーバ３００、およびＤＢサーバ４００から、記録した情報を取得する。この手法では、Ｗｅｂサーバ２００、Ａｐｐサーバ３００、およびＤＢサーバ４００が、受信したリクエストメッセージと、そのリクエストメッセージに応じた処理により下位の層のサーバへ出力したリクエストメッセージとを関連付けている。そのため、分析サーバ１００では、１つのトランザクションを構成する上位層のメッセージと下位層のメッセージとを容易に関連付けることができ、メッセージフローの作成が容易となる。ただし、この方法を適用する場合、Ｗｅｂサーバ２００、Ａｐｐサーバ３００、およびＤＢサーバ４００各サーバの内部時計を、正確に同期させておくことが好ましい。
【０１５６】
メッセージデータ記憶部１２２に格納されたメッセージから検出可能な全てのメッセージフローがメッセージフロー情報記憶部１３３に格納された後、Ｗｅｂ三階層システムの階層ごとの性能分析が行われる。
【０１５７】
図１６は、階層別性能分析処理の手順の一例を示すフローチャートである。以下、図１６に示す処理をステップ番号に沿って説明する。
［ステップＳ１２１］集計部１４１は、分析対象期間を、十分に細かい粒度で分割する。分析対象期間は、キャプチャデータ記憶部１１２内の現在処理対象となっている時系列データの生成元となったＩＰパケットの採取期間である。また分析対象期間を分割することで生成された複数の期間を、集計区間とする。飽和多重度決定部１４４は、例えば、個々の集計区間の期間を示す情報を、集計区間情報記憶部１４２に格納する。
【０１５８】
［ステップＳ１２２］集計部１４１は、各集計区間のスループットと多重度とを算出する。この処理の詳細は後述する（図２１参照）。
［ステップＳ１２３］飽和多重度決定部１４４は、飽和多重度を算出する。この処理の詳細は後述する（図２７参照）。
【０１５９】
［ステップＳ１２４］分析部１４５は、性能分析対象となっている階層がボトルネックとなっているか否かを判定する。この処理の詳細は後述する（図２８参照）。その後、階層別性能分析処理が終了する。
【０１６０】
次に、図１６に示す各ステップの処理を詳細に説明する。
＜集計区間への分割＞
分析対象期間の集計区間への分割処理について説明する。集計部１４１は、分析対象期間を、十分に細かい粒度の集計区間に分割する。
【０１６１】
なお、第２の実施の形態の手法を実施する場合、細分化した一つの集計区間の長さは十分に短くするのが適切である。なぜならば、多重度はジョブの平均処理時間に近い極短時間で大きく変化する。また、一般的に多重度とスループットの関係は図１７のような関係となる。
【０１６２】
図１７は、多重度とスループットとの関係を示す図である。図１７では、細粒度で集計区間を分割した場合の、各集計区間の多重度とスループットとを表Ａに示している。また各集計区間の多重度とスループットとの関係をグラフＢに示している。
【０１６３】
図１７に示すように、集計区間の長さを十分に細かくすると、集計区間それぞれの多重度は、大きく異なる。もし集計区間を長くして、例えば図１７の「集計区間１」から「集計区間８」までを１つの集計区間にまとめると、まとめられた集計区間の多重度は、もとの集計区間の多重度の平均となる。集計区間ごとのばらつきが大きい多重度を平均化した結果として、多重度とスループットとの関係を不正確に捉えてしまう結果となる。このことを避けるために、この細分化された集計区間の長さは、集計区間内での多重度変化が小さくなるように、ジョブの平均処理時間に応じて、短く設定する。例えば、集計区間の長さは「１００ｍｓ」とする。
【０１６４】
図１８は、集計区間への分割例を示す図である。図１８の例では、１００ｍｓの集計区間長で、分析対象期間が分割されている。なお第２の実施の形態では、集計区間長は、例えば、予め集計部１４１に設定されている。
【０１６５】
図１８に示すように、分析対象期間の分割に伴い、各ジョブの実行期間は、いずれかの集計区間に振り分けられる。これにより、集計区間ごとに、非常に短い時系列データが構成される。
【０１６６】
図１９は、実行期間の集計区間への振り分け例を示す図である。Ｗｅｂサーバ２００で実行されたジョブ６１は、２回の実行期間６１ａ，６１ｂにおいて、処理が実行されている。１回目の実行期間６１ａは、「集計区間１」の時間帯に含まれているため、「集計区間１」に振り分けられる。また実行期間６１ｂは、「集計区間２」の時間帯に含まれているため、「集計区間２」に振り分けられる。
【０１６７】
Ａｐｐサーバ３００で実行されたジョブ６２は、５回の実行期間６２ａ，６２ｂ，６２ｃ，６２ｄ，６２ｅにおいて、処理が実行されている。１回目と２回目との実行期間６２ａ，６２ｂは、「集計区間１」の時間帯に含まれているため、「集計区間１」に振り分けられる。３回目〜５回目の実行期間６２ｃ，６２ｄ，６２ｅは、「集計区間２」の時間帯に含まれているため、「集計区間２」に振り分けられる。
【０１６８】
ＤＢサーバ４００で実行されたジョブ６３〜６６は、各ジョブが１回ずつの実行期間で実行されている。ジョブ６３は、「集計区間１」の時間帯に実行されているため、「集計区間１」に振り分けられる。ジョブ６５，６６は、「集計区間２」の時間帯に実行されているため、「集計区間２」に振り分けられる。
【０１６９】
ジョブ６４は、「集計区間１」と「集計区間２」とに跨って実行されている。このように、実行期間が複数の集計区間を跨り、複数の集計区間に属する実行期間も存在する。この場合、複数の集計区間に属する実行期間が、各集計区間に属する期間ごとに分割される。例えばジョブ６４の全体の実行期間は、「集計区間１」に属する実行期間６４ａと「集計区間２」に属する実行期間６４ｂとに分割される。そして分割後の各実行期間６４ａ，６４ｂが、各集計区間に振り分けられる。
【０１７０】
なお図１８、図１９には、１つの業務処理に応じて行われた一連の処理について示しているが、複数の業務処理が、各階層のサーバにおいて並列で実行される場合もある。
図２０は、並列で処理が実行される状況を示す図である。図２０の例では、「集計区間１」と「集計区間２」との間に、３つの業務処理が並列で実行されている。ジョブ６１〜６６によって１つの業務処理が実行され、ジョブ７１〜７５によって１つの業務処理が実行され、ジョブ８１〜８３によって１つの業務処理が実行されている。なお、図２０において、各ジョブを示す矩形内の文字は、各ジョブのジョブ種を示している。
【０１７１】
このように複数の業務処理が並列で実行される場合も、図１９に示したように、各ジョブの実行期間が、その実行期間を包含する集計区間に振り分けられる。
次にスループットと多重度との算出処理について詳細に説明する。
【０１７２】
図２１は、スループット・多重度算出処理の手順の一例を示すフローチャートである。以下、図２１に示す処理をステップ番号に沿って説明する。
［ステップＳ１３１］集計部１４１は、未処理の集計区間を１つ選択する。例えば集計部１４１は、集計区間情報記憶部１４２に設定されている集計区間を、先頭のエントリから順に選択する。
【０１７３】
［ステップＳ１３２］集計部１４１は、選択した集計区間のスループットを計算する。例えば集計部１４１は、ジョブ種ごとの１ジョブ当たりの正規化したスループット値により、各ジョブに重み付けを行うことで、処理負荷の異なる複数のジョブを処理する場合のスループット算出の正確性を向上させる。集計部１４１は、計算したスループットを、例えば集計区間情報記憶部１４２に格納する。
【０１７４】
［ステップＳ１３３］集計部１４１は、選択した集計区間の多重度を計算する。例えば集計部１４１は、処理中の階層のサーバで選択した集計区間内に存在しているジョブの、集計区間内での処理時間の合計を求める。そして集計部１４１は、求めた合計を集計区間長で除算し、除算結果を集計区間の多重度とする。この多重度は、集計区間内の平均的な多重度を表している。集計部１４１は、計算した多重度を、例えば集計区間情報記憶部１４２に格納する。
【０１７５】
［ステップＳ１３４］集計部１４１は、未処理の集計区間があるか否かを判断する。例えば集計部１４１は、集計区間情報記憶部１４２に設定されている集計区間の最後のエントリの処理が終了した場合、未処理の集計区間はないと判断する。未処理の集計区間がある場合、集計部１４１は、処理をステップＳ１３１に進める。未処理の集計区間がなければ、集計部１４１は、スループット・多重度算出処理を終了する。
【０１７６】
図２２は、集計区間情報記憶部のデータ構造の一例を示す図である。集計区間情報記憶部１４２には、階層ごとの集計区間管理テーブル１４２ａ，１４２ｂ，１４２ｃが格納されている。例えば集計区間管理テーブル１４２ａは、ＤＢサーバ４００の階層に対応する。
【０１７７】
集計区間管理テーブル１４２ａには、集計区間、期間、スループット、および多重度の欄が設けられている。集計区間の欄には、集計区間の名称が設定される。期間の欄には、集計区間の期間が設定される。スループットの欄には、集計区間のスループットが設定される。多重度の欄には、集計区間の多重度が設定される。
【０１７８】
＜スループット・多重度計算＞
次に、スループットの計算と多重度の計算とについて、詳細に説明する。
＜＜スループット計算＞＞
まず、スループット計算処理について詳細に説明する。飽和多重度決定部１４４は、集計区間ごとに、その集計区間に属するジョブの処理時間に基づいて、スループットを計算する。この際、飽和多重度決定部１４４は、ジョブ種間の差異を考慮した重み付けを行って、正規化したスループットを計算する。
【０１７９】
ここで、スループットの正規化の有用性について説明する。第２の実施の形態では、分析対象期間を短い集計区間に細分化する。ここで、正規化を行わずに多重度とスループットの関係を求めようとすると、下記の２つの要素が両者の関係における揺らぎとなって、関連性を失わせる可能性がある。すると、多重度とスループットとの関連性を用いたボトルネック判定の信頼性が低下してしまう。
１．異種ジョブ間でのハードウェア資源消費量の差異
２．同種ジョブの個々のジョブ間でのハードウェア資源消費量の差異
特に１．は差異の絶対量が大きく、また、短い時間区間に区切ると、各区間同士の間でジョブ種の混合割合が偏るので、結果として大きな影響を及ぼすことになる。一方、２．の方は、同種ジョブということで、ある程度は平均化した分布（正規分布など）となることが期待できる。
【０１８０】
そこで、第２の実施の形態では、低負荷時に測定したジョブ種ごとの平均処理時間を利用して、異種ジョブ間でのハードウェア資源消費量の差異を正規化することによって、１．の問題を解決した正確なスループットを得る。ジョブ種間の差異を考慮した重みの判断指標となる情報は、予め正規化スループット値記憶部１４３に格納されている。
【０１８１】
図２３は、正規化スループット値記憶部のデータ構造の一例を示す図である。正規化スループット値記憶部１４３には、正規化スループット値テーブル１４３ａが格納されている。正規化スループット値テーブル１４３ａには、ジョブ種、低負荷時の平均処理時間、および正規化されたスループット値の欄が設けられている。
【０１８２】
ジョブ種の欄には、Ｗｅｂ三階層システムのいずれかのサーバで実行されるジョブのジョブ種名が設定される。
低負荷時の平均処理時間の欄には、対応するジョブ種のジョブを、サーバが低負荷時に実行した場合の平均処理時間が設定される。図２３の例では、低負荷時の平均処理時間の欄に、「ｍｓ」単位の数値が設定されている。低負荷時の平均処理時間は、例えば、システムの管理者が、予めＷｅｂ三階層システムの負荷が少ない状態で計測し、正規化スループット値テーブル１４３ａに設定する。
【０１８３】
正規化されたスループット値の欄には、各ジョブ種の１ジョブ当たりの正規化されたスループット値が設定される。例えば階層ごとに、代表ジョブ種が１つずつ選択される。図２３の例では、Ｗｅｂサーバ２００で実行されるジョブ種に関しては、ジョブ種名「Ｗ１」のジョブ種が、代表ジョブ種である。Ａｐｐサーバ３００で実行されるジョブ種に関しては、ジョブ種名「Ａ１」のジョブ種が、代表ジョブ種である。ＤＢサーバ４００で実行されるジョブ種に関しては、ジョブ種名「Ｄ１」のジョブ種が、代表ジョブ種である。各階層の代表ジョブ種に関しては、１ジョブ当たりの正規化されたスループット値は「１．００」である。
【０１８４】
代表ジョブ種以外のジョブ種に関しては、同じ階層の代表ジョブ種と比較し場合に、低負荷時の平均処理時間が何倍となるかを示す数値が、そのジョブ種の１ジョブ当たりの正規化されたスループット値となる。例えばジョブ種名「Ｗ２」のジョブ種は、低負荷時の平均処理時間が、代表ジョブ種（ジョブ種名「Ｗ１」）の平均処理時間の０．６０４倍（１３．４ｍｓ／２２．２ｍｓ）である。従って、ジョブ種名「Ｗ２」のジョブ種の１ジョブ当たりの正規化されたスループット値は、「０．６０４」となる。
【０１８５】
このような１ジョブ当たりの正規化されたスループット値を用いて、集計部１４１は、細分化した各集計区間について、その集計区間内の平均スループットを計算する。すなわち集計部１４１は、低負荷時に収集したジョブ種ごとの平均処理時間を利用して、スループットの重み付けを行う。例えば集計部１４１は、各ジョブの処理（要求を受けてから返信を返すまで）に関し、スループットの基準スコアを「１」とする。そして集計部１４１は、基準スコアに、低負荷時のジョブ種別ごとの平均処理時間を元に計算された１ジョブ当たりの正規化されたスループット値による重み付けを行い、ジョブごとの１ジョブ当たりのスコアを求める。さらに集計部１４１は、ジョブ全体の実行期間のうち、各集計区間に属している割合に応じた比率で、１つのジョブのスコアを、そのジョブの実行期間が属する集計区間に分配する。そして集計部１４１は、分配したスコアを、各集計区間のスループットに加算する。
【０１８６】
以下、図１９に示した集計区間のスループット計算例を示す。なお図１９に示したように、各階層のジョブ６１〜６６のうち、各階層のサーバで処理を行っている期間のみが実行期間となり、他の階層へリクエストメッセージを送信してからレスポンスメッセージを待っている期間は、実行期間から除外される。
【０１８７】
まずＷｅｂサーバ２００の階層におけるスループットの計算例を示す。図１９の例では、ジョブ６１の２つの実行期間６１ａ，６１ｂのうち、１回目の実行期間６１ａのみが「集計区間１」に含まれ、２回目の実行期間は「集計区間２」に含まれる。実行期間６１ａの長さ（処理時間）は「１４ｍｓ」であり、実行期間６１ｂの長さ（処理時間）は「１１ｍｓ」である。するとジョブ６１の合計の処理時間は「２５ｍｓ」である。またジョブ６１のジョブ種は「Ｗ１」であり、正規化スループット値テーブル１４３ａ（図２３参照）では、１ジョブ当たりの正規化されたスループット値は「１．００」である。正規化されたスループット値で示されるスコア「１．００」が、「集計区間１」と「集計区間２」とに含まれる処理時間比率で分配される。すると「集計区間１」のスコアが「０．５６」（＝１．００×１４／２５）、「集計区間２」のスコアが「０．４４」（＝１．００×１１／２５）となる。得られたスコアが、Ｗｅｂサーバ２００の階層における各集計区間のスループットに加算される。
【０１８８】
次にＡｐｐサーバ３００の階層におけるスループットの計算例を示す。図１９の例では、ジョブ６２の５つの実行期間６２ａ，６２ｂ，６２ｃ，６２ｄ，６２ｅのうち、２つの実行期間６２ａ，６２ｂが「集計区間１」に含まれ、３つの実行期間６２ｃ，６２ｄ，６２ｅが「集計区間２」に含まれる。実行期間６２ａの長さは「１９ｍｓ」、実行期間６２ｂの長さは「９ｍｓ」、実行期間６２ｃの長さ（処理時間）は「１０ｍｓ」、実行期間６２ｄの長さは「１２ｍｓ」、実行期間６１ｅの長さは「２１ｍｓ」である。するとジョブ６２の合計の処理時間は「７１ｍｓ」である。またジョブ６２のジョブ種は「Ａ１」であり、正規化スループット値テーブル１４３ａ（図２３参照）では、１ジョブ当たりの正規化されたスループット値は「１．００」である。正規化されたスループット値で示されるスコア「１．００」が「集計区間１」と「集計区間２」とに含まれる処理時間比率で分配される。すると「集計区間１」のスコアが「０．３９４」（＝１．００×（１９＋９）／７１）、「集計区間２」のスコアが「０．６０６」（＝１．００×（１０＋１２＋２１）／７１）となる。得られたスコアが、Ａｐｐサーバ３００の階層における各集計区間のスループットに加算される。
【０１８９】
次にＤＢサーバ４００の階層におけるスループットの計算例を示す。図１９の例では、ジョブ６３の実行期間は、全体が「集計区間１」に含まれ、処理時間は「９ｍｓ」である。またジョブ６３のジョブ種は「Ｄ１」であり、正規化スループット値テーブル１４３ａ（図２３参照）では、１ジョブ当たりの正規化されたスループット値は「１．００」である。そこで、正規化されたスループット値で示されるスコア「１．００」が、ＤＢサーバ４００の階層における「集計区間１」のスループットに加算される。
【０１９０】
ジョブ６４の実行期間は、図１９の例では、前半の実行期間６４ａが「集計区間１」に含まれ、後半の実行期間６４ｂは「集計区間２」に含まれる。実行期間６４ａの長さ（処理時間）は「１０ｍｓ」であり、実行期間６４ｂの長さは「２４ｍｓ」である。するとジョブ６４の合計の処理時間は「３４ｍｓ」である。またジョブ６４のジョブ種は「Ｄ２」であり、正規化スループット値テーブル１４３ａ（図２３参照）では、１ジョブ当たりの正規化されたスループット値は「３．７２」である。正規化されたスループット値で示されるスコア「３．７２」が、「集計区間１」と「集計区間２」とに含まれる処理時間比率で分配される。すると「集計区間１」のスコアが「１．０９」（＝３．７２×１０／３４）、「集計区間２」のスコアが「２．６３」（＝３．７２×２４／３４）となる。得られたスコアが、ＤＢサーバ４００の階層における各集計区間のスループットに加算される。
【０１９１】
ジョブ６５の実行期間は、図１９の例では、全体が「集計区間２」に含まれ、処理時間は「８ｍｓ」である。またジョブ６５のジョブ種は「Ｄ３」であり、正規化スループット値テーブル１４３ａ（図２３参照）では、１ジョブ当たりの正規化されたスループット値は「０．７９６」である。そこで、正規化されたスループット値で示されるスコア「０．７９６」が、ＤＢサーバ４００の階層における「集計区間２」のスループットに加算される。
【０１９２】
ジョブ６６の実行期間は、図１９の例では、全体が「集計区間２」に含まれ、処理時間は「７ｍｓ」である。またジョブ６６のジョブ種は「Ｄ４」であり、正規化スループット値テーブル１４３ａ（図２３参照）では、１ジョブ当たりの正規化されたスループット値は「３．１９」である。そこで、正規化されたスループット値で示されるスコア「３．１９」が、ＤＢサーバ４００の階層における「集計区間２」のスループットに加算される。
【０１９３】
以上よりＤＢサーバ４００の階層における「集計区間１」のスループットは、ジョブ６３に基づくスコアと、ジョブ６４の実行期間６４ａに基づくスコアとの合計となり、「２．０９」となる。またＤＢサーバ４００の階層における「集計区間２」のスループットは、ジョブ６４の実行期間６４ｂに基づくスコア、および２つのジョブ６５，６６それぞれに基づくスコアの合計となり、「６．６１６」となる。
【０１９４】
図２０に示したように、複数の業務処理が並列実行されている場合は、階層ごとに、各集計区間において、各業務処理に関するジョブによるスコアの総和が求められ、得られた総和が、各階層の集計区間ごとのスループットとなる。
【０１９５】
このようなスループットを集計区間ごとに求めることで、スループットの時系列推移が得られる。
図２４は、スループットの時系列推移の一例を示す図である。図２４では、ＤＢサーバ４００の階層におけるスループットの時系列推移をグラフで表している。図２４に示したグラフは、横軸が時刻、縦軸がスループットである。横軸の１目盛が各集計区間に対応する。
【０１９６】
＜＜多重度計算＞＞
次に多重度計算処理について詳細に説明する。第２の実施の形態における多重度は、その集計区間内で、平均すると同時に何件のジョブが同時に実行されていたかを示す値である。この多重度は、次の式で求めることができる。
多重度＝集計区間内での全てのジョブの処理時間の合計÷集計区間の長さ
最下位の階層以外の階層における多重度の計算では、「ジョブの処理時間」には、その階層において処理が行われている時間だけを含め、他の階層へ処理を送ってから返信を待っている間の時間は含めない。
【０１９７】
図１９の例を用い、多重度の計算例を示す。Ｗｅｂサーバ２００の階層の「集計区間１」の多重度は「０．１４」（＝１４／１００）、「集計区間２」の多重度は「０．１１」（＝１１／１００）である。Ａｐｐサーバ３００の階層の「集計区間１」の多重度は「０．２８」（＝（１９＋９）／１００）、「集計区間２」の多重度は「０．４３」（＝（１０＋１２＋２１）／１００）である。ＤＢサーバ４００の階層の「集計区間１」の多重度は「０．１９」（＝（９＋１０）／１００）、「集計区間２」の多重度は「０．３９」（＝（２４＋８＋７）／１００）である。
【０１９８】
図２０の場合のように、複数の業務処理が並列実行されている場合にも、この計算法は変わらない。すなわち、集計区間に存在する複数の業務処理のジョブを区別することなく、各ジョブの処理時間の総和を計算して、計算された総和を集計区間長で割ればよい。
【０１９９】
このような多重度を集計区間ごとに求めることで、多重度の時系列推移が得られる。
図２５は、多重度の時系列推移の一例を示す図である。図２５では、ＤＢサーバ４００の階層における多重度の時系列推移をグラフで表している。図２５に示したグラフは、横軸が時刻、縦軸が多重度である。横軸の１目盛が各集計区間に対応する。
【０２００】
＜飽和多重度算出＞
次に、飽和多重度算出処理について詳細に説明する。
飽和多重度決定部１４４は、スループットと多重度との関係から、飽和多重度を動的に求める。例えば飽和多重度決定部１４４は、各集計区間について計算されたスループットと多重度とから、両者の関係を求め、多重度の上昇に伴うスループットの上昇が止まる飽和多重度の値を求める。
【０２０１】
多重度の上昇に伴うスループットの上昇が止まる位置があることは、例えば、各集計区間の多重度とスループットとの関係を散布図で表すことで容易に理解できる。
図２６は、多重度とスループットとの関係の一例を示す散布図である。図２６に示した散布図は、横軸（Ｘ軸）に多重度、縦軸にスループットを採っている。そして各集計区間のスループットと多重度とに応じた点を、図中にプロットしている。
【０２０２】
図２６に示した散布図からも分かるように、多重度がある程度の値までは、多重度の上昇に伴ってスループットは上昇するが、それ以降は多重度が上昇してもスループットは上昇しなくなる。飽和多重度決定部１４４は、この境界となる多重度を飽和多重度として求める。
【０２０３】
図２７は、飽和多重度算出処理の一例を示すフローチャートである。以下、図２７に示す処理をステップ番号に沿って説明する。
［ステップＳ１４１］飽和多重度決定部１４４は、多重度の最小値と最大値とを求める。例えば飽和多重度決定部１４４は、現在処理対象となっている階層の集計区間管理テーブルの多重度の欄から、設定されている値の最小値と最大値とを抽出する。
【０２０４】
［ステップＳ１４２］飽和多重度決定部１４４は、多重度の最小値と最大値との間を、等間隔に細分化する。細分化して得られた多重度の細分化区間を、多重度区間とする。ここで各多重度区間内の下限値をその多重度区間の多重度の区間開始値とし、多重度区間内の上限値をその多重度区間の多重度の終了値とする。
【０２０５】
例えば飽和多重度決定部１４４は、多重度の最小値と最大値の間を、所定数（例えば１００）の多重度区間に分割する。なお所定数に分割するのではなく、一定間隔ごと（例えば多重度０．１ごと）に分割してもよい。例えば、最少多重度「０」、最大多重度「５０」であれば、多重度「０」から多重度「５０」の間を０．５刻みで１００分割する。
【０２０６】
［ステップＳ１４３］飽和多重度決定部１４４は、多重度が少ない方から順に多重度区間を選択する。
［ステップＳ１４４］飽和多重度決定部１４４は、選択した多重度区間に含まれる多重度を有する集計区間の平均多重度と、それらの集計区間の平均スループットとを計算する。
【０２０７】
［ステップＳ１４５］飽和多重度決定部１４４は、直前に選択した多重度区間（隣接する多重度区間）との間の、多重度増加に伴うスループットの上昇率（傾き）を計算する。スループットの傾きは、例えば直前に選択した多重度区間との比較における平均スループットの変化量を、直前に選択した多重度区間との比較における平均多重度の変化量で除算した値である。
【０２０８】
ｉ番目に選択された多重度区間の傾きδiの計算を式で表すと、例えば以下のような計算となる。
【０２０９】
【数１】
【０２１０】
［ステップＳ１４６］飽和多重度決定部１４４は、ステップＳ１４５で計算した傾きが、閾値より小さいか否かを判断する。傾きの閾値としては、例えば平均多重度が最も小さな多重度区間の傾きδ1に、１未満の所定の係数を掛けた値（例えば０．２δ1）とする。飽和多重度決定部１４４は、傾きが所定の閾値より小さければ、処理をステップＳ１４９に進める。また飽和多重度決定部１４４は、傾きが所定の閾値以上であれば、処理をステップＳ１４７に進める。
【０２１１】
［ステップＳ１４７］飽和多重度決定部１４４は、未処理の多重度区間があるか否かを判断する。飽和多重度決定部１４４は、未処理の多重度区間があれば、処理をステップＳ１４３に進める。また飽和多重度決定部１４４は、全ての多重度区間の処理が終了していれば、処理をステップＳ１４８に進める。
【０２１２】
［ステップＳ１４８］飽和多重度決定部１４４は、全ての多重度区間において、傾きが閾値以上だった場合、飽和多重度をステップＳ１４１で求められた多重度の最大値に設定し、飽和多重度算出処理を終了する。
【０２１３】
［ステップＳ１４９］飽和多重度決定部１４４は、現在選択している多重度区間の多重度の区間開始値を飽和多重度に決定する。
例えば多重度「０」から多重度「５０」の間を０．５刻みで１００分割した場合において、１＜ｉ≦９の範囲まで傾きが閾値を下回らなかったとする。この場合、１０番目の多重度区間の多重度の範囲「４．５〜５．０」の区間開始値「４．５」（＝０．５×９）が、飽和多重度に決定される。
【０２１４】
このように、分割した多重度が小さな多重度区間から順番に、傾きの値が一定の閾値（例えば０．２δ1）を下回らないかどうかが調べられ、最初に下回るｉが求められる。そして多重度が小さな方からｉ番目の多重度区間の多重度の区間開始値が飽和多重度となる。
【０２１５】
＜ボトルネック判定＞
次に、飽和多重度に基づくボトルネック判定処理について説明する。分析部１４５は、飽和多重度を超えていない集計区間の割合に応じて、各階層の処理能力の余力を算出する。そして分析部１４５は、飽和多重度を超えていない集計区間の割合が所定の値より少ない階層を検出すると、その階層がボトルネックになっていると判断する。
【０２１６】
すなわち、図２６に示した散布図の各ドットは、１つ１つの集計区間に相当する。これらの集計区間の中で、多重度が飽和多重度を下回っていた区間は、その階層の処理能力に余力が残っていたと考えられる。そのような集計区間が、集計区間の総数に占める割合を求め、それを処理能力の余力とする。例えば、１８０秒分の時系列データを同時に処理する場合は、その中には１８００の集計区間が存在する（集計区間長が１００ｍｓの場合）。ここで１８００の集計区間の内の３８５の集計区間で多重度が飽和多重度を下回っていた場合、２１．４％（＝３８５／１８００×１００）の区間で余力を有していたという計算になる。
【０２１７】
例えば、第２の実施の形態では、分析部１４５は、飽和多重度を超えていない集計区間が第１の閾値を下回った場合に、その階層の処理能力の限界を超えた完全飽和状態であると判断する。そして、分析部１４５は、完全飽和状態となった階層をボトルネック原因と判定して報告する。
【０２１８】
また分析部１４５は、飽和多重度を超えていない集計区間の割合が、予め設定した第１の閾値より高い第２の閾値を下回った場合に、その階層は部分的に処理能力の限界を超えている半飽和状態であると判断する。これは、複数の階層が同時に半飽和状態に陥って、多階層システム全体としてはボトルネック状態となっている可能性があるためである。
【０２１９】
以下に、ボトルネック判定処理の手順について説明する。
図２８は、ボトルネック判定処理の手順の一例を示すフローチャートである。以下、図２８に示す処理をステップ番号に沿って説明する。
【０２２０】
［ステップＳ１５１］分析部１４５は、集計区間を１つ選択する。例えば分析部１４５は、処理対象となっている階層に対応する集計区間管理テーブル（図２２参照）の上位から順に、集計区間を選択する。
【０２２１】
［ステップＳ１５２］分析部１４５は、選択した集計区間の多重度が、飽和多重度以下か否かを判断する。分析部１４５は、飽和多重度以下であれば、処理をステップＳ１５３に進める。また分析部１４５は、飽和多重度より大きければ、処理をステップＳ１５４に進める。
【０２２２】
［ステップＳ１５３］分析部１４５は、未飽和区間数をカウントアップする。なお未飽和区間数は、ボトルネック判定処理の開始時に「０」に初期化されている。
［ステップＳ１５４］分析部１４５は、未処理の集計区間があるか否かを判断する。分析部１４５は、未処理の集計区間があれば、処理をステップＳ１５１に進める。分析部１４５は、未処理の集計区間がなければ、処理をステップＳ１５５に進める。
【０２２３】
［ステップＳ１５５］分析部１４５は、集計区間の総数に対する未飽和区間の割合が第１の閾値未満か否かを判断する。第１の閾値は、予め分析部１４５に設定されている。例えば分析部１４５は、未飽和区間数を集計区間の総数で除算し、未飽和区間の割合を求める。そして分析部１４５は、未飽和区間の割合と第１の閾値を比較し、未飽和区間の割合が第１の閾値未満か否かを判断する。分析部１４５は、未飽和区間の割合が第１の閾値未満であれば、処理をステップＳ１５６に進める。また分析部１４５は、未飽和区間の割合が第１の閾値以上であれば、処理をステップＳ１５７に進める。
【０２２４】
［ステップＳ１５６］分析部１４５は、現在の処理対象となっている階層が、ボトルネック要因であると判定する。分析部１４５は、例えば判定結果をモニタ１１などに出力する。その後、ボトルネック判定処理が終了する。
【０２２５】
［ステップＳ１５７］分析部１４５は、集計区間の総数に対する未飽和区間の割合が第２の閾値未満か否かを判断する。第２の閾値は、第１の閾値より大きな値であり、予め分析部１４５に設定されている。分析部１４５は、未飽和区間の割合が第２の閾値未満であれば、処理をステップＳ１５８に進める。また分析部１４５は、未飽和区間の割合が第２の閾値以上であれば、ボトルネック判定処理を終了する。
【０２２６】
［ステップＳ１５８］分析部１４５は、現在の処理対象となっている階層が、複合的なボトルネック要因の候補であると判定する。複合的なボトルネック要因とは、他の階層との複合的要因によって発生しているボトルネックである。分析部１４５は、例えば判定結果をモニタ１１などに出力する。その後、ボトルネック判定処理が終了する。
【０２２７】
このようにして、処理能力が残存していた集計区間（未飽和の集計区間）の割合に応じて、その階層が、多階層システムのボトルネックになっているかどうかを判定することができる。
【０２２８】
以下、図２９〜図３２を参照し、各階層のサーバの余力と、未飽和区間の割合との関係について説明する。
図２９は、階層が完全未飽和状態の一例を示す散布図である。階層が完全未飽和状態であるとは、負荷が非常に低くて、どの集計区間においても多重度が飽和多重度を超えていない状態である。図２９に示したように多重度が低い集計区間しかない場合には飽和多重度が求まらないことがある。すなわち図２７に示した処理において、全ての多重度区間において、傾きの大きさが閾値以上になることがある。このように、全ての多重度区間において、傾きの大きさが閾値以上となった場合、完全未飽和状態と判定できる。この場合、例えば分析部１４５は、分析対象の階層が完全未飽和状態であることを示す情報を出力する。
【０２２９】
図３０は、階層が未飽和状態の一例を示す散布図である。階層が未飽和状態であるとは、多重度が飽和多重度以下の集計区間の割合が、第２の閾値以上の状態である。例えば第１の閾値が「０．２」（２０％）、第２の閾値が「０．７」（７０％）の場合、多重度が飽和多重度以下の集計区間の割合が７０％以上の階層は、未飽和状態と判定される。この場合、例えば分析部１４５は、分析対象の階層が未飽和状態であることを示す情報を出力する。
【０２３０】
図３１は、階層が半飽和状態の一例を示す散布図である。階層が半飽和状態であるとは、多重度が飽和多重度以下の集計区間の割合が、第１の閾値以上、第２の閾値未満の状態である。半飽和状態の階層は、部分的に処理能力の限界を超えているものと考えられる。これは、複数の階層が同時に半飽和状態に陥って、多階層システム全体としてはボトルネック状態となっている可能性があるためである。例えば第１の閾値が「０．２」（２０％）、第２の閾値が「０．７」（７０％）の場合、多重度が飽和多重度以下の集計区間の割合が２０％以上、且つ７０％未満の階層は、半飽和状態と判定される。この場合、例えば分析部１４５は、分析対象の階層が半飽和状態（部分的ボトルネック）であることを示す情報を出力する。
【０２３１】
図３２は、階層が飽和状態の一例を示す散布図である。階層が飽和状態であるとは、多重度が飽和多重度以下の集計区間の割合が、第１の閾値未満の状態である。飽和状態の階層は、多階層システムにおけるボトルネックになっていると考えられる。例えば第１の閾値が「０．２」（２０％）の場合、多重度が飽和多重度以下の集計区間の割合が２０％未満の階層は、飽和状態と判定される。この場合、例えば分析部１４５は、分析対象の階層が飽和状態（ボトルネック）であることを示す情報を出力する。
【０２３２】
以上説明したように、第２の実施の形態では、精密なメッセージ送受時刻の記録から、各階層における処理の多重度とスループットを算出し、その関係を動的に求め、そこからボトルネック判定を行う。これにより、ボトルネックの判定を適切に行うことができる。
【０２３３】
すなわち、第２の実施の形態では、最初に、分析対象期間が短い時間間隔の集計区間に細分化され、それぞれの集計区間から各階層における処理多重度とスループットが計算される。こうして得られた集計区間ごとの多重度とスループットとの組から両者の関係が求められ、処理多重度が増加しているのにスループットが増加しなくなる多重度の値（飽和多重度と呼ぶ）を動的に求められる。そして、細分化された各集計区間の中で、多重度がその飽和多重度を超えていた区間の割合を求めることによって、各階層が余力を有しているかどうかが判定される。
【０２３４】
このような判定は、各階層で動くサーバは、そのハードウェアやＯＳやソフトウェア実装の制限によって、同時に実行できるジョブ数（並列度）が限られており、並列度が一定の値に達すると、それ以上はスループットが上昇しなくなるという現象に基づいている。
【０２３５】
また第２の実施の形態では、多重度とスループットの両者の関係でボトルネック発生を判定するので、ボトルネックの発生原因が何であるかに関係なく、ボトルネックが発生していることを検出できる。すなわち、ソフトウェアの多重度制限以外の原因でボトルネックが発生している場合あっても、特定の階層でボトルネックが発生していることを検出できる。
【０２３６】
多階層システム中のある階層のスループットが限界を迎える飽和多重度に影響を及ぼす原因は様々である。例えば飽和多重度は、ソフトウェア実装やジョブ種ごとの処理内容によって、使用するハードウェア資源の種類や量が異なることや、各レベル（ＯＳやソフトウェア内部）で行われるキューイングの影響を受ける。また、ジョブ種の混合率の変化に伴って、運用中に飽和多重度が動的に変わることも考えられる。このように、飽和多重度に影響を及ぼす要因を、外部からのＩＰパケットのキャプチャを観測によって、事前に知ることが非常に困難である。第２の実施の形態では、多重度とスループットとの関係からボトルネックの有無を判定するため、飽和多重度に影響を及ぼすサーバの内部要因に関する情報を用いずに、ボトルネックの判定を可能としている。
【０２３７】
例えば、個々のシステムリソースは枯渇していないのに、システム全体としては入力仕事量を増やしても性能（出力仕事量）が伸びなくなっている状態についても、その要因となっている階層（サーバ）を特定することが可能である。このような現象は、１つの階層の中において、複数の要因が複合してボトルネックを引き起こしている場合に発生する。複合的な要因には、ハードウェア・ＯＳ・ソフトウェア・ユーザアプリケーションなど全てを含むため、全ての階層において要因となるリソースを個別に分析して、さらに関係を分析すると、関係が複雑になりすぎ、正確な判断が難しい。第２の実施の形態では、各階層の多重度とスループットとの関係から、ボトルネックの要因を内在している階層を特定できるため、ボトルネックの発生要因となっているリソースを特定する作業の負担が軽減される。
【０２３８】
また第２の実施の形態では、非常に短い時間の集計区間における多重度とスループットとに基づいて、各階層の余力を判定するため、極めて短時間に発生するボトルネックであっても検出可能である。例えば、図３１の例であれば、サーバ単体での継続したボトルネックとはなっていないものの、飽和多重度を超えた多重度の集計区間が存在していることが分かる。このような集計区間は、瞬間的にボトルネックを生じさせている可能性がある。その結果、例えば、複数の階層間で、極短時間でボトルネック位置が推移し、システム全体としては入力仕事量を増やしても性能が伸びなくなっている状態において、その複数階層間でのボトルネック位置推移と、各階層の影響度合いを検出できる。
【０２３９】
〔第３の実施の形態〕
次に第３の実施の形態について説明する。第３の実施の形態は、集計区間のスループットの算出において、間接的な外部資源待ち時間を、処理時間から除外するものである。なお、第３の実施の形態を実現するシステム構成は第２の実施の形態と同様である。そこで、図４や図６に示した第２の実施の形態の各要素を用いて第３の実施の形態の機能を説明する。
【０２４０】
多階層システムにおいて、多重度とスループットの関連性から、システム性能の飽和度合いを測ろうとすると、この関連性を壊す要因が存在する。そのような要因の１つとして、ソフトウェアの実装によっては、階層間のメッセージ送受におけるレスポンスメッセージ待ちという直接的な待ち時間以外に、間接的に階層外部の資源を待っている時間が存在することがある。
【０２４１】
図３３は、多重度とスループットの関連性を壊す要因の一例を示す図である。例えば図３３の場合は、Ａｐｐサーバ３００上で動くアプリケーションがＤＢサーバ４００と通信するためＤＢコネクションを内部で一定量確保（プール）しておき、そのＤＢコネクションを使い回すという実装がなされていた場合に起こるケースである。なお、このような実装方法は、ＤＢコネクションプールという一般的な実装方法である。
【０２４２】
例えば、プールしてある上限までＤＢコネクションを使い切ってしまった場合、次の処理が行われる。Ａｐｐサーバ３００においてＤＢコネクションを新たに必要とするスレッドは、他のＤＢコネクションを使用しているスレッドが処理を終えてＤＢコネクションをプールへ解放するのを待つ。もし他のスレッドがＤＢサーバからの応答を待っていて処理が進まない場合は、これは間接的にＤＢサーバ４００の応答を待っていることになる。特に、ＤＢサーバ４００がボトルネックとなった場合においては、ＤＢサーバ４００の応答時間が指数関数的に増加するので、Ａｐｐサーバ３００において空きＤＢコネクションを待つ時間は極端に増加する（図３３の網掛け部分）。
【０２４３】
Ａｐｐサーバ３００における待ち時間は、外部資源を待っている時間なので、Ａｐｐサーバ３００のスループットや多重度の計算においては、本来はＡｐｐサーバ３００の処理時間からは省かれるべき時間である。しかし、外部観測においては、そのようなアプリケーション内部での、間接的な外部資源の待ち時間を測定する手段がない。
【０２４４】
同様のことは、Ｗｅｂサーバ２００やＡｐｐサーバ３００の空きスレッド待ちでも発生する。一般的に、Ｗｅｂサーバ２００やＡｐｐサーバ３００では、同時に使用できるスレッド数の上限を定めていて、使用されているスレッド数が上限に達すると、それ以降に到着したリクエストは空きスレッドができるのを待つことになる。下位の階層からレスポンスが遅延によりスレッドが空くのが遅れると、空きスレッドの待ち時間には、間接的にはさらに下位の階層のレスポンスを待っている時間が含まれることになる。特に下位の階層でボトルネックが発生しているときには、空きスレッドの待ち時間が非常に大きな待ち時間となる。
【０２４５】
このような間接的な外部資源待ち時間を含めてスループットと多重度とを計算すると、多重度を非常に大きな値にしてしまい、多重度とスループットの関連性を壊してしまう。そこで、第３の実施の形態では、間接的な外部資源待ち時間による悪影響を取り除くため、間接的な外部資源待ち時間が発生すると予め分かっている実行期間については、常にその実行期間を削除して、多重度とスループットを計算する。間接的な外部資源待ち時間が発生すると予め分かっている実行期間は、例えば、最下位の階層以外の階層における同一ジョブ内の最初の実行期間である。図３３の例では、網掛けで示されたＡｐｐサーバ３００における最初の実行期間全体を、多重度とスループットとの計算に使用する情報から削除する。もちろん、この方法では、その区間に含まれている、取り除く必要のない、その階層での処理時間も同時に取り除かれてしまい、その長さの分だけ誤差が発生する。それでも多重度とスループットの両方が低下するだけなので、本性能分析手法全体としては、影響は無視できる。
【０２４６】
第３の実施の形態は、第２の実施の形態のスループット計算処理（図２１のステップＳ１３２）と、多重度計算処理（図２１のステップＳ１３３）との処理を変更することで実現できる。変更内容は以下の通りである。
【０２４７】
＜スループット計算＞
集計部１４１は、スループットを算出する際に、各ジョブの最初の実行期間の長さを処理時間から除算する。例えば、図１９に示した例であれば、Ｗｅｂサーバ２００の「集計区間１」のスループットの計算において、ジョブ６１の実行期間６１ａは、ジョブ６１の実行期間から除外される。同様に、Ａｐｐサーバ３００の「集計区間１」のスループットの計算において、ジョブ６２の実行期間６２ａは、ジョブ６２の実行期間から除外される。
【０２４８】
なお、１つのジョブの実行が複数の集計区間に跨る場合は、それぞれの集計区間の中における処理時間の比率に応じて、先のスコアを各集計区間へ配分するが、この際にも、ジョブの先頭の実行期間は除外してスループットの配分が計算される。
【０２４９】
＜多重度計算＞
集計部１４１は、多重度を算出する際に、各ジョブの最初の実行期間の長さを、多重度算出時の処理時間から除外する。
【０２５０】
このように第３の実施の形態では、間接的な外部資源待ち時間を含む実行期間を、スループットと多重度との計算に用いないようにしたことで、間接的な外部資源待ちの影響を除去することができる。
【０２５１】
これによって、間接的な外部資源待ちの時間が、その階層上での処理時間として誤って算入されることを防ぐことができ、その影響で多重度とスループットの関係が不正確になることを防止することができる。特に、システム全体の処理性能が飽和しかかった状態では、このような間接的な外部資源待ち（ボトルネック階層の処理待ち）時間が急激に大きくなり、本来の処理時間よりも遥かに大きくなることは珍しくない。この間接的な外部資源待ち時間は、スループットは小さくする方向に働くのに対し、多重度に関してはその値を急激に高めるように働く。そのため、間接的な外部資源待ちの時間の影響が残存していると、スループットと多重度との関係が不正確となる。
【０２５２】
図３４は、間接的な外部資源待ち時間を除外しない場合の各集計区間のスループットと多重度との一例を示す散布図である。なお図３４の例は、間接的な外部資源待ち時間が発生したＡｐｐサーバ３００の階層のスループットと多重度とを計算したものである。図３４の例では、高い多重度の集計区間が多数存在することが分かる。
【０２５３】
図３４のスループットと多重度との計算の元となった時系列データを用い、間接的な外部資源待ち時間を除外してスループットと多重度とを再計算すると、図３５のようになる。
【０２５４】
図３５は、間接的な外部資源待ち時間を除外した場合の各集計区間のスループットと多重度との一例を示す散布図である。図３５の例では、図３４と比較して、多重度が非常に低くなっていることが分かる。このように、間接的な外部資源待ち時間を除外することで、各集計区間の多重度は少なくなる。
【０２５５】
第３の実施の形態のように、間接的な外部資源待ちの時間の影響を抑止すれば、間接的な外部資源待ち時間が存在する状況においても、その待ち時間によりスループットや多重度の正確性が低下することを抑止できる。すなわち、性能分析の正確性を向上させることができる。
【０２５６】
〔第４の実施の形態〕
次に第４の実施の形態について説明する。第４の実施の形態は、ジョブの処理数に変えて、出力メッセージ数を用いてスループットを計算するものである。なお、第４の実施の形態を実現するシステム構成は第２の実施の形態と同様である。そこで、図６に示した第２の実施の形態の各要素を用いて第４の実施の形態の機能を説明する。
【０２５７】
Ａｐｐサーバ３００などのサーバでは、Ｊａｖａ（登録商標） ＶＭ（virtual machine）がＦｕｌｌガーベージコレクション（以下「Ｆｕｌｌ−ＧＣ」と呼ぶ）を起こすことがある。ガーベージコレクションは、プログラムが動的に確保したヒープ（動的に確保可能なメモリ領域）上のメモリ領域のうち、不要になった領域を自動的に解放する処理である。Ｆｕｌｌ−ＧＣの場合、Ｆｕｌｌ−ＧＣ以外の全ての処理が、瞬間的に停止する。ジョブの実行が開始されてから終了するまでの間に、Ｆｕｌｌ−ＧＣによりジョブが停止する期間が含まれていると、ジョブの挙動を正確に検出することができないことがある。なぜならば、Ａｐｐサーバ３００上でＦｕｌｌ−ＧＣのためにジョブが瞬間停止させられると、その時間はＡｐｐサーバ３００外からの外部観測では、あたかもそのＡｐｐサーバ３００上での処理が継続しているかのように観測されてしまう。その結果、第２の実施の形態の方法では、実際にはジョブの停止期間であるにも拘わらず、その停止期間を実行期間と判断して、スループットや多重度が計算される。
【０２５８】
図３６は、Ｆｕｌｌ−ＧＣによる停止期間が発生した場合の一連の業務処理を示す図である。図３６の例では、Ｗｅｂサーバ２００のジョブ９１からのリクエストメッセージに応じてＡｐｐサーバ３００でジョブ９２が実行されている。Ａｐｐサーバ３００のジョブ９２は、ＤＢサーバ４００に対してリクエストメッセージを４回送信している。ＤＢサーバ４００では、Ａｐｐサーバ３００からのリクエストメッセージに応じて、４つのジョブ９３〜９６が実行されている。Ｗｅｂサーバ２００が実行したジョブ９１には、２つの実行期間９１ａ，９１ｂが含まれる。Ａｐｐサーバ３００が実行したジョブ９２には、５つの実行期間９２ａ，９２ｂ，９２ｃ，９２ｄ，９２ｅが含まれる。
【０２５９】
ここで、Ａｐｐサーバ３００では、実行期間９２ｃにおいて、Ｆｕｌｌ−ＧＣが発生したものとする。Ｆｕｌｌ−ＧＣが行われると、ジョブ９２の処理は停止するため、実行期間９２ｃは、実際にＡｐｐサーバ３００がジョブ９２の処理に費やした時間よりも長い処理時間となる。
【０２６０】
図３６に示した様な挙動は、多階層システム全体として考えると、Ｆｕｌｌ−ＧＣが発生した一瞬だけ、Ａｐｐサーバ３００の階層がボトルネックになっていると見做すことができる。第４の実施の形態では、そのような瞬間的なボトルネック発生を検出可能とする。そのために第４の実施の形態では、スループットを、その階層が出力するメッセージ数によって換算する。この出力メッセージには、下位の階層に送るリクエストも上位の階層へ返すレスポンスも含まれる。この出力メッセージ数を、ジョブ種間の差異を考慮して、各ジョブ種の低負荷時の処理時間に比例し、各ジョブ種のジョブ１つ当たりの平均出力メッセージ数に反比例するように正規化する。
【０２６１】
スループットの計算方法を置き換えたことで、１ジョブ当たりの正規化スループット値も、第２の実施の形態と異なる値となる。
図３７は、第４の実施の形態における正規化スループット値記憶部のデータ構造の一例を示す図である。正規化スループット値記憶部１４３には、正規化スループット値テーブル１４３ｂが格納されている。正規化スループット値テーブル１４３ｂには、ジョブ種、低負荷時の平均処理時間、平均出力メッセージ数、および正規化されたスループット値の欄が設けられている。
【０２６２】
ジョブ種の欄には、Ｗｅｂ三階層システムのいずれかのサーバで実行されるジョブのジョブ種名が設定される。
低負荷時の平均処理時間の欄には、対応するジョブ種のジョブを、サーバが低負荷時に実行した場合の平均処理時間が設定される。図３７の例では、低負荷時の平均処理時間の欄に、「ｍｓ」単位の数値が設定されている。低負荷時の平均処理時間は、例えば、システムの管理者が、予めＷｅｂ三階層システムの負荷が少ない状態で計測し、正規化スループット値テーブル１４３ｂに設定する。
【０２６３】
平均出力メッセージ数の欄には、対応するジョブ種のジョブが出力するメッセージ数の平均値である。このメッセージ数には、リクエストメッセージとレスポンスメッセージとの両方がカウントされる。
【０２６４】
正規化されたスループット値の欄には、各ジョブ種の１メッセージ当たりの処理時間を正規化したスループット値が設定される。例えば階層ごとに、代表ジョブ種が１つずつ選択される。図３７の例では、Ｗｅｂサーバ２００で実行されるジョブ種に関しては、ジョブ種名「Ｗ１」のジョブ種が、代表ジョブ種である。Ａｐｐサーバ３００で実行されるジョブ種に関しては、ジョブ種名「Ａ１」のジョブ種が、代表ジョブ種である。ＤＢサーバ４００で実行されるジョブ種に関しては、ジョブ種名「Ｄ１」のジョブ種が、代表ジョブ種である。各階層の代表ジョブ種に関しては、１メッセージ当たりの正規化されたスループット値は、「１．００」を平均出力メッセージ数で除算した値である。例えばＷｅｂサーバ２００の代表ジョブ種であるジョブ種「Ｗ１」は、平均出力メッセージ数が「２」であるため、正規化されたスループット値は、「０．５」（＝１／２）となる。
【０２６５】
代表ジョブ種以外のジョブ種に関しては、低負荷時における代表ジョブ種との平均処理時間の比率を、さらに各ジョブ種の平均出力メッセージ数で割った値が、各ジョブ種のジョブが発行するメッセージ１回あたりの正規化されたスループット値となる。例えばＷｅｂサーバ２００の階層のジョブ種「Ｗ２」は、低負荷時の平均処理時間が、代表ジョブ種（ジョブ種名「Ｗ１」）の平均処理時間の０．６０４倍（１３．４ｍｓ／２２．２ｍｓ）である。この比率「０．６０４」を、ジョブ種「Ｗ２」の平均出力メッセージ数「２．００」で除算した値「０．３０２」が、ジョブ種名「Ｗ２」のジョブ種の１メッセージ当たりの正規化されたスループット値となる。
【０２６６】
第４の実施の形態では、第２の実施の形態のスループット計算処理（図２１のステップＳ１３２）に代えて、図３７に示したジョブ種ごとの１メッセージ当たりの正規化されたスループット値を用いて、集計区間ごとのスループットが計算される。
【０２６７】
図３６に示した業務処理に基づいてスループットを計算すると以下のようになる。
Ｗｅｂサーバ２００の階層の場合は、「集計区間１」のスループットはジョブ種「Ｗ１」のジョブ９１が発行したメッセージ１回分の値「０．５００」である。「集計区間２」のスループットは「０」である。「集計区間３」のスループットは、ジョブ種「Ｗ１」のジョブ９１が発行したメッセージ１回分の値「０．５００」である。
【０２６８】
Ａｐｐサーバ３００の階層の場合は、「集計区間１」のスループットは、ジョブ種「Ａ１」が発行したメッセージ２回分の値「０．４１２」（＝０．２０６×２）である。「集計区間２」のスループットは、発行したメッセージが一つもないので「０」となる。「集計区間３」のスループットは、ジョブ種「Ａ１」のジョブ９２が発行したメッセージ３回分の値「０．６１８」（＝０．２０６×３）である。この３回の内の２回は下位のＤＢサーバ４００に対して送信したリクエストメッセージで、残りの１回は上位のＷｅｂサーバ２００に返信したレスポンスメッセージである。
【０２６９】
ＤＢサーバ４００の階層の「集計区間１」のスループットは、ジョブ種「Ｄ１」のジョブ９３が発行したメッセージ１回分の値「１．００」である。「集計区間２」のスループットは、ジョブ種「Ｄ２」のジョブ９４が発行したメッセージ１回分の値「３．７２」である。「集計区間３」のスループットは、ジョブ種「Ｄ３」の２つのジョブ９５，９６が発行したメッセージ２回分の値「１．５９」（＝０．７９６×２）である。
【０２７０】
なお、複数の業務処理が並列実行されている場合は、第２の実施の形態と同様に、階層ごとに、上記のようにして計算されたスループットの集計区間ごとの総和が計算される。そして、計算された総和が、各集計区間のスループットになる。
【０２７１】
このようにスループットを計算することによって、「集計区間２」におけるジョブ９２の実行期間９２ｃのように、実質的な処理とは無関係に時間が長くなっている区間にスループット値が割り当てられることを抑止できる。すなわち、瞬間的な挙動停止があると、停止期間はメッセージ出力が行われないため、スループット値の換算も「０」となる。これは、ジョブの処理がサーバで実際に実行されている時間のみを、正しくスループットとして換算できることを意味する。
【０２７２】
その結果として、Ｆｕｌｌ−ＧＣの発生などにより瞬間的にボトルネックとなっている集計区間を、正確に判別できるようになる。以下、図３８と図３９とを参照し、１ジョブ当たりの正規化スループット値に基づいてスループットを計算した場合と、１メッセージ当たりの正規化スループット値に基づいてスループットを計算した場合との違いを説明する。
【０２７３】
図３８は、１ジョブ当たりの正規化スループット値に基づいてスループットを計算した場合の散布図である。図３８の例は、Ａｐｐサーバ３００においてＦｕｌｌ−ＧＣが発生した期間を分析対象期間として、第２の実施の形態の手法でスループットを計算したものである。図３８のような多重度とスループットとの関係では、Ｆｕｌｌ−ＧＣによる瞬間的なボトルネックの発生が認識できない。
【０２７４】
図３９は、１メッセージ当たりの正規化スループット値に基づいてスループットを計算した場合の散布図である。図３９の例は、図３８のスループット計算時と同じ時系列データを用いて、第４の実施の形態の手法でスループットを計算したものである。
【０２７５】
このように第４の実施の形態でスループットを計算すると、瞬間的な挙動停止が直接的にスループットに反映される。そのためＦｕｌｌ−ＧＣが発生してスループットが完全に０になっていたり大きく落ち込んでいたりする集計区間が多数あることがグラフ上で明確に表されている。図３９では、楕円９９内の集計区間が、Ｆｕｌｌ−ＧＣなどによって引き起こされた異常な瞬間スループット低下が発生した集計区間である。
【０２７６】
このような瞬間スループット低下が発生した集計区間は、例えば分析部１４５が、多重度が飽和多重度を超えていながら、スループットが所定値以下の集計区間を集計区間情報記憶部１４２から検索することで、検出することができる。また分析部１４５が、図３９に示したような散布図をモニタ１１に表示し、管理者に瞬間スループット低下の発生を認識させることもできる。
【０２７７】
なお図３９に示した例では全体的にスループットのバラつきが大きくなっているが、これは、Ｆｕｌｌ−ＧＣ以外にもマイナーなガーベージコレクションが頻繁に発生しており、それがスループットを瞬間的に細かく上下させているためであると考える。
【０２７８】
また、例えば、ジョブ種が一種類の場合などには、スループットの正規化を行わなくてもよい。その場合、例えば、集計区間内に出力したメッセージ数を、スループットとする。また、ジョブ全体で出力されるメッセージ数のうち、集計区間内に出力したメッセージ数を、スループットとすることもできる。
【０２７９】
〔第５の実施の形態〕
次に第５の実施の形態について説明する。第５の実施の形態は、データのばらつきの影響を抑止した手法で、飽和多重度を求めるものである。なお、第５の実施の形態を実現するシステム構成は第２の実施の形態と同様である。そこで、図６に示した第２の実施の形態の各要素を用いて第５の実施の形態の機能を説明する。
【０２８０】
図２７に示した第２の実施の形態の飽和多重度算出手法では、データに細かなバラつきがある場合にそれに影響されて、傾きが早い時点で一時的に閾値を下回り、飽和多重度を小さな値に誤判定してしまう可能性がある。そこで第５の実施の形態では、飽和多重度をより正確に求めることができる手法で、飽和多重度を算出する。
【０２８１】
第５の実施の形態で採用した手法は、統計的な信頼区間を用いる。信頼区間とは、ある数がどのような数値の範囲にあるかを確率的に示すものである。多階層システムの性能分析においては、ある階層のサーバにおける多重度の値が低い時は、多重度とスループットは正比例に近い関係で、両者の傾きの値の分散は小さい。他方、その階層のサーバの処理能力が限界（ボトルネック）に近づいた時点で、両者の関係が急激に崩れ、分散が大きくなる。このように分散が大きくなると、傾きの値の統計的信頼区間が広がるという特徴がある。第５の実施の形態は、信頼区間のこのような特徴を利用することによって、データの細かなバラつきに影響されずに、飽和多重度を求めることを可能とする。
【０２８２】
図４０は、第５の実施の形態における飽和多重度算出処理の一例を示すフローチャートである。以下、図４０に示す処理をステップ番号に沿って説明する。なお図４０におけるステップＳ２０１〜ステップＳ２０５の処理は、それぞれ図２７に示した第２の実施の形態におけるステップＳ１４１〜ステップＳ１４５の処理と同じである。そこで、ステップＳ２０６以降の処理について説明する。なお、ステップＳ２０２の処理では、多重度の最小値「０」と最大値「５０」との間が、０．５刻みで１００分割されているものとする。
【０２８３】
［ステップＳ２０６］飽和多重度決定部１４４は、傾きの分布の統計的な信頼区間を計算する。例えば飽和多重度決定部１４４は、隣接する多重度区間の間で、両者の平均多重度と平均スループットの変化量から、変化量の傾きδiを、図２７のステップＳ１４５と同様の式（１）で求める。
【０２８４】
さらに飽和多重度決定部１４４は、分割した多重度区間の小さな方から順にｎk（ｎkは、１＜ｎk≦１００の範囲の整数）個の区間について、先に求めた傾きを使って、その統計上の信頼区間を以下の式で計算する。
【０２８５】
【数２】
【０２８６】
ここで、１．９６は９５％信頼区間の定数である。
［ステップＳ２０７］飽和多重度決定部１４４は、信頼区間の下限が所定の閾値より低いか否かを判断する。信頼区間の下限に関する閾値としては、例えば平均多重度が最も小さな多重度区間の傾きδ1に、１未満の所定の係数を掛けた値（例えば０．２δ1）とする。飽和多重度決定部１４４は、信頼区間の下限が閾値より低ければ、処理をステップＳ２１０に進める。また飽和多重度決定部１４４は、信頼区間の下限が閾値以上であれば、処理をステップＳ２０８に進める。
【０２８７】
［ステップＳ２０８］飽和多重度決定部１４４は、未処理の多重度区間があるか否かを判断する。飽和多重度決定部１４４は、未処理の多重度区間があれば、処理をステップＳ２０３に進める。また飽和多重度決定部１４４は、未処理の多重度区間がなければ、処理をステップＳ２０９に進める。
【０２８８】
［ステップＳ２０９］飽和多重度決定部１４４は、全ての多重度区間において、信頼区間の下限が閾値以上だった場合、飽和多重度をステップＳ２０１で求められた多重度の最大値に設定し、飽和多重度算出処理を終了する。
【０２８９】
［ステップＳ２１０］飽和多重度決定部１４４は、現在選択している多重度区間の多重度の区間開始値を飽和多重度に決定する。
このような処理により、式（２）で求めた信頼区間の下限が、予め定めておいた閾値を最初に下回るｎkが求められ、そのときの多重度区間の区間開始値が飽和多重度となる。例えば、多重度「０」から多重度「５０」の間を０．５刻みで１００分割した場合において、１＜ｎk≦９の範囲まで信頼区間の下限が閾値を下回らず、ｎk＝１０のときに初めて信頼区間の下限が閾値より低くなったものとする。この場合、１０番目の多重度区間の多重度の範囲「４．５〜５．０」の区間開始値「４．５」（＝０．５×９）が、飽和多重度に決定される。
【０２９０】
このように、第５の実施の形態では、分割した多重度区間の小さな方から順に、先に求めた傾きを加えていきながら、その統計上の信頼区間が計算され、その信頼区間の下限が、予め定めておいた閾値を下回った時点で、そのときの多重度が飽和多重度とされる。これにより、傾きの局所的なバラつきに影響されずに、多重度とスループットの関係が変化する飽和多重度を機械的に求めることが可能となる。
【０２９１】
例えば、第２の実施の形態における飽和多重度算出処理（図２７参照）では、傾きをそのまま多重度が小さい方から比較していき、傾きが変化する多重度を求めている。この場合、同種ジョブ間でも個々のジョブ間でのハードウェア資源消費量のバラつきが存在するので、求めた傾きが上下に振れてしまって、傾きが変化する多重度の位置を誤検出してしまう可能性がある。他方、図４０に示した第５の実施の形態の飽和多重度算出処理では、傾きの値の統計上の信頼区間を算出していき、その下限が閾値を超えるかどうかという判定基準によって飽和多重度を決定する。その結果、局所的な傾きのバラつきに影響されることなく、多重度とスループットの関係が変化する飽和多重度を求めることができる。
【０２９２】
〔第６の実施の形態〕
次に第６の実施の形態について説明する。第６の実施の形態は、各階層の残存処理能力を算出するものである。残存処理能力を算出することで、例えば各階層の最大処理能力の見積もり（キャパシティプランニング）が可能となる。なお、第６の実施の形態を実現するシステム構成は第２の実施の形態と同様である。そこで、図６に示した第２の実施の形態の各要素を用いて第６の実施の形態の機能を説明する。
【０２９３】
例えば図２８に示した第２の実施の形態のボトルネック判定処理では、多重度が飽和多重度以下の集計区間（未飽和区間）の割合が算出されている。未飽和区間は、処理能力の余力が残っている集計区間である。第６の実施の形態では、さらにその階層の処理能力の余力（限界処理能力に対する残存処理能力の割合）を求める。
【０２９４】
第６の実施の形態における集計区間情報記憶部１４２は、各集計区間が未飽和区間に該当するか否かのフラグを記憶することができる。
図４１は、第６の実施の形態の集計区間情報記憶部のデータ構造の一例を示す図である。集計区間情報記憶部１４２には、階層ごとの集計区間管理テーブル１４２ｄ，１４２ｅ，１４２ｆが格納されている。例えば集計区間管理テーブル１４２ｄは、ＤＢサーバ４００の階層に対応する。
【０２９５】
集計区間管理テーブル１４２ｄには、集計区間、期間、スループット、多重度、および未飽和区間フラグの欄が設けられている。集計区間の欄には、集計区間の名称が設定される。期間の欄には、集計区間の期間が設定される。スループットの欄には、集計区間のスループットが設定される。多重度の欄には、集計区間の多重度が設定される。未飽和区間フラグの欄には、集計区間が未飽和区間に該当するか否かを示すフラグ（未飽和区間フラグ）が設定される。例えば、集計区間が未飽和区間であれば、未飽和区間フラグの値に「１」が設定される。また集計区間が未飽和区間でなければ、未飽和区間フラグの値に「０」が設定される。なお未飽和区間フラグの初期値は、未飽和区間ではないことを示す値「０」であるものとする。
【０２９６】
このような集計区間管理テーブル１４２ｄ，１４２ｅ，１４２ｆを用いて、分析部１４５は、各階層のサーバの余力を算出する。分析部１４５は、例えば図１６に示した第２の実施の形態のボトルネック判定処理（ステップＳ１２４）に代えて、余力計算処理を実行する。なお、分析部１４５は、図１６に示した第２の実施の形態のボトルネック判定処理（ステップＳ１２４）と余力計算処理との両方を実行することもできる。
【０２９７】
図４２は、余力計算処理の手順の一例を示すフローチャートである。以下、図４２に示す処理をステップ番号に沿って説明する。
［ステップＳ３０１］分析部１４５は、処理対象となっている階層の集計区間を１つ選択する。例えば分析部１４５は、集計区間情報記憶部１４２に格納されている集計区間管理テーブル１４２ｄ，１４２ｅ，１４２ｆのうち、現在処理対象となっている階層に対応する集計区間管理テーブルの上位の集計区間から順に選択する。
【０２９８】
［ステップＳ３０２］分析部１４５は、選択した集計区間の多重度が飽和多重度以下か否かを判断する。例えば分析部１４５は、集計区間管理テーブル内の選択した集計区間のエントリにおける多重度と、飽和多重度決定部１４４で決定された多重度とを比較して、選択した集計区間の多重度が飽和多重度以下か否かを判断する。分析部１４５は、選択した集計区間の多重度が飽和多重度以下であれば、処理をステップＳ３０３に進める。また分析部１４５は、選択した集計区間の多重度が飽和多重度より大きければ、処理をステップＳ３０４に進める。
【０２９９】
［ステップＳ３０３］分析部１４５は、選択した集計区間の未飽和フラグを、未飽和区間に設定する。例えば分析部１４５は、処理対象の階層の集計区間管理テーブル内の選択した集計区間のエントリにおける未飽和フラグに「１」を設定する。
【０３００】
［ステップＳ３０４］分析部１４５は、未処理の集計区間があるか否かを判断する。分析部１４５は、未処理の集計区間があれば処理をステップＳ３０１に進める。また分析部１４５は、未処理の集計区間がなければ処理をステップＳ３０５に進める。
【０３０１】
［ステップＳ３０５］分析部１４５は、最大スループットを決定する。最大スループットは、例えば、飽和多重度から開始される多重度区間内に含まれる集計区間のスループットの最大値である。
【０３０２】
［ステップＳ３０６］分析部１４５は、以下の式（３）により余力を算出する。
【０３０３】
【数３】
【０３０４】
式（３）において、ｎ（０以上の整数）は、多重度が飽和多重度を下回っている集計区間（未飽和区間）の数である。ｔｐmaxは、飽和多重度のときに記録した最大スループットである。ｔｐkは、未飽和区間と判定された集計区間を並べたときのｋ番目（ｋは１以上ｎ以下の整数）の集計区間におけるスループットである。ＴＷnumallは、分析対象期間に含まれる集計区間の総数である。
【０３０５】
式（３）は、未飽和区間のスループットと最大スループットとの差分が、最大スループットに占める割合の平均値に、全ての集計区間に対する未飽和区間の区間数の割合を掛け合わせたものである。この計算の結果、処理対象となっている階層の残存処理能力が算出される。
【０３０６】
図４３は、余力計算処理を説明する図である。図４３には、説明をわかりやすくするため、集計区間の総数が１１の場合の例を示している。図４３の例では、飽和多重度以下の多重度を持つ集計区間（未飽和区間）の数は５であり、最大スループットは２８００である。よって、上記の式（３）は次のようになる。
双方向矢印で示された差分の総和／（２８００×５）×５／１１
ここで重要なのは、余力の計算において、飽和多重度よりも多重度が高い集計区間は、スループットが最大スループットより少なくても、残存処理能力に加えないことである。換言すると、飽和多重度を境界として、その前後で領域を分けて、飽和多重度以下の場合のみ、最大スループットとの差分を残存処理能力として計算している。例えば図４３の多重度１０以上の各集計区間のスループットは、最大スループットより少ない。しかしこの集計区間は、高多重度による過負荷のためにスループットが低下しているものと考えられる。過負荷によるスループットの低下が生じている集計区間には残存処理能力はないため、残存処理能力としては加えられていない。
【０３０７】
なお、全ての集計区間について、最大スループットと各集計区間のスループットの差分を求めて、その平均値を計算する方法を取ると、飽和多重度を過ぎて過負荷のオーバヘッドによるスループット低下が起きている場合まで、残存処理能力に加算されてしまう。第６の実施の形態では、このような過負荷のオーバヘッドによりスループットが低下している集計区間の残存処理能力を「０」にすることで、余力計算の正確性を向上させている。
【０３０８】
しかも、第６の実施の形態によって、処理性能が完全には飽和していない半飽和状態の階層においても、あとどれだけの処理能力を残しているかが見積もれるようになる。これによって、システム全体の処理能力が完全飽和する前に対策を打つことが可能になる。また、飽和状態の階層をスケールアウト（マシン台数の増加）して性能強化した時に、２番目に弱い階層が、あとどれだけ負荷量を増加した時に次にボトルネックとなるかを見積もることも可能となる。
【０３０９】
〔第７の実施の形態〕
次に第７の実施の形態について説明する。第７の実施の形態は、集計区間の長さの最適値を自動的に求めるものである。なお、第７の実施の形態を実現するシステム構成は第２の実施の形態と同様である。そこで、図６に示した第２の実施の形態の各要素を用いて第７の実施の形態の機能を説明する。
【０３１０】
第２の実施の形態では「異種ジョブ間でのハードウェア資源消費量の差異」は正規化しているが、「同種ジョブでも、各ジョブ間でのハードウェア資源消費量の差異」によって発生する揺らぎは、平均化されることを期待している。平均化のためには、集計区間に含まれるジョブの数は多い方が良いので、集計区間は長い方が有利になる。その一方で、集計区間が長くなると、その中での多重度推移が大きくなり、多重度とスループットの関係を正確に測れなくなる。そこで第７の実施の形態では、同一種ジョブ間でのハードウェア資源消費量の差異が許容できる範囲に収まるように、以下の方法で適切な長さの集計区間を決定する。
【０３１１】
第７の実施の形態では、多重度が低い区間では、多重度とスループットが正比例に近い関係を示すことを利用する。ただし、集計区間を短く設定しすぎた場合は、同種ジョブ内でのハードウェア資源消費量の差異によって発生する揺らぎが平均化されず、多重度とスループットの関係を乱すことになる。そのことを利用して、以下の手順で、個々のジョブ間の差異が平均化されるのに十分な集計区間の長さを求める。なお集計区間長の決定処理は、例えば図１６に示した第２の実施の形態における階層別性能分析処理における、ステップＳ１２１の前に行われる。
【０３１２】
図４４は、集計区間長決定処理の手順を示すフローチャートである。以下、図４４に示す処理をステップ番号に沿って説明する。
［ステップＳ４０１］集計部１４１は、集計区間長の初期値を設定する。設定する初期値は、想定される集計区間長よりも非常に小さな値とする。例えば仮集計区間長として１０ｍｓを設定する。
【０３１３】
［ステップＳ４０２］集計部１４１は、分析対象期間を仮集計区間長で分割する。これにより、複数の集計区間が生成される。
［ステップＳ４０３］集計部１４１は、ステップＳ４０４〜ステップＳ４０７の処理が未処理の集計区間のうちの１つを選択する。
【０３１４】
［ステップＳ４０４］集計部１４１は、選択した集計区間の多重度を計算する。
［ステップＳ４０５］集計部１４１は、選択した集計区間の多重度が閾値より低いか否かを判断する。閾値としては、例えば０．５や１．０といった値が予め集計部１４１に設定されている。集計部１４１は、多重度が閾値より低ければ、処理をステップＳ４０６に進める。また集計部１４１は、多重度が閾値以上であれば、処理をステップＳ４０３に進める。
【０３１５】
［ステップＳ４０６］集計部１４１は、選択した集計区間のスループットを計算する。
［ステップＳ４０７］集計部１４１は、多重度が閾値より低いとｉ番目（ｉは、１以上の整数）に判断された集計区間について、「スループット÷多重度」の逆正接となる角度θiを、以下の式で求める。
θi=ｔａｎ-1（ｔｐi／ｌｄi）
［ステップＳ４０８］集計部１４１は、未処理の集計区間があるか否かを判断する。集計部１４１は、未処理の集計区間がある場合、処理をステップＳ４０３に進める。また集計部１４１は、全ての集計区間に対してステップＳ４０４〜ステップＳ４０７の処理が終了していれば、処理をステップＳ４０９に進める。
【０３１６】
［ステップＳ４０９］集計部１４１は、多重度が閾値より低い集計区間が十分にあるか否かを判断する。例えば集計部１４１は、集計区間の総数に対する、多重度が閾値より低い集計区間の割合が、予め設定された所定値以上であれば、多重度が閾値より低い集計区間が十分にあると判断する。集計部１４１は、多重度が閾値より低い集計区間が十分にあれば、処理をステップＳ４１１に進める。また集計部１４１は、多重度が閾値より低い集計区間が十分にはなければ、処理をステップＳ４１０に進める。
【０３１７】
［ステップＳ４１０］集計部１４１は、多重度が閾値より低い集計区間が十分にない場合、集計区間長を決定するには負荷が過大であり、集計区間長を決定できないと判断し、集計区間長決定処理を終了する。
【０３１８】
なお集計区間長が決定できなかった場合、集計部１４１は、以後の処理（図１６のステップＳ１２１）では、例えば予め設定されていた値（例えば１００ｍｓ）を集計区間長とする。また集計区間長が決定できなかった場合、集計部１４１は、以後の処理において、同一階層の他の解析対象区間に対する集計区間長決定処理で求められた集計区間長を使用することもできる。
【０３１９】
［ステップＳ４１１］集計部１４１は、変動係数ＣＶを算出する。変動係数ＣＶは、相対的なばらつきを表す数値である。変動係数ＣＶは、ステップＳ４０７で得られた角度θiの標準偏差を、平均値で割ることによって得られる。式で表すと以下の式となる。
【０３２０】
【数４】
【０３２１】
ここで、ｍはステップＳ４０６に処理が進んだ集計区間の数である。
［ステップＳ４１２］集計部１４１は、変動係数が所定の閾値より大きいか否かを判断する。所定の閾値としては、例えば０．１が設定される。集計部１４１は、変動係数が所定の閾値より大きければ、処理をステップＳ４１３に進める。また集計部１４１は、変動係数が所定の閾値以下であれば、処理をステップＳ４１４に進める。
【０３２２】
［ステップＳ４１３］集計部１４１は、仮集計区間長を一定割合長くする。例えば集計部１４１は、現在の仮集計区間長に１０ｍｓを加算した値を、新たな仮集計区間長とする。その後、集計部１４１は、処理をステップＳ４０２に進め、新たな仮集計区間長の場合の変動係数を計算する。
【０３２３】
［ステップＳ４１４］集計部１４１は、変動係数が閾値以下になった場合、現在の仮集計区間長を、集計区間長に決定する。
このようにして、最適な集計区間長を決定することができる。この手法は、多重度が低い時（例えば常に１以下）には、多重度（ジョブ量）の増加に伴ってスループットは単調に増加するという考えに基づいている。多重度が低い時に限って、その両者の関係を測定し、それが一定の分布の範囲に収まっていれば、集計区間長は短すぎず、同一種ジョブ間でのハードウェア資源消費量の差異は平均化されていると判断する。逆に、多重度とスループットの関係の分散が大きい時には、同一種ジョブ間でのハードウェア資源消費量の差異の影響が出ていると判断し、集計区間長を大きくする。
【０３２４】
第７の実施の形態によって、収集されたデータから集計区間の長さを自動的に決定できるようになり、集計区間を事前に調整する手間が省ける。また、不適切な集計区間の設定によって、誤った性能分析結果を得ることも避けられる。
【０３２５】
〔第８の実施の形態〕
次に第８の実施の形態について説明する。第８の実施の形態は、最適化のための低負荷時の平均処理時間を、分析対象期間に取得された時系列データの中から取得するものである。なお、第８の実施の形態を実現するシステム構成は第２の実施の形態と同様である。そこで、図６に示した第２の実施の形態の各要素を用いて第８の実施の形態の機能を説明する。
【０３２６】
第２の実施の形態におけるスループットの正規化では、低負荷時に予め採取したデータから算出した平均処理時間を使用している（図２３参照）。第８の実施の形態は、この平均処理時間を、性能分析に使用するのと同一の時系列データから採取する。
【０３２７】
図４５は、低負荷時の平均処理時間算出処理の一例を示すフローチャートである。この処理は、例えば、図９に示した第２の実施の形態のステップＳ１１３の処理の後に実行される。以下、図４５に示す処理をステップ番号に沿って説明する。
【０３２８】
［ステップＳ５０１］集計部１４１は、分析対象期間を集計区間長で、複数の集計区間に分割する。
［ステップＳ５０２］集計部１４１は、ステップＳ５０３〜Ｓ５０５の処理が未処理の集計区間を１つ選択する。
【０３２９】
［ステップＳ５０３］集計部１４１は、選択した集計区間の多重度を計算する。例えば集計部１４１は、処理中の階層のサーバで選択した集計区間内に存在しているジョブの、集計区間内での処理時間の合計を求める。そして集計部１４１は、求めた合計を集計区間長で除算し、除算結果を集計区間の多重度とする。
【０３３０】
［ステップＳ５０４］集計部１４１は、選択した集計区間の多重度が、所定の閾値より低いか否かを判断する。所定の閾値としては、例えば０．５や１．０という値が予め設定される。集計部１４１は、多重度が閾値より低い場合、処理をステップＳ５０５に進める。また集計部１４１は、多重度が閾値以上の場合、処理をステップＳ５０６に進める。
【０３３１】
［ステップＳ５０５］集計部１４１は、選択した集計区間を、低負荷区間のリストに登録する。低負荷区間のリストは、例えばＲＡＭ１０３内に保持される。
［ステップＳ５０６］集計部１４１は、ステップＳ５０３〜Ｓ５０５の処理が未処理の集計区間があるか否かを判断する。集計部１４１は、未処理の集計区間があれば、処理をステップＳ５０２に進める。また集計部１４１は、未処理の集計区間がなければ、処理をステップＳ５０７に進める。
【０３３２】
［ステップＳ５０７］集計部１４１は、低負荷区間のリストに含まれる集計区間内で実行されたジョブを用いて、ジョブ種ごとの平均処理時間を計算する。集計部１４１は、計算したジョブ種ごとの平均処理時間を、正規化スループット値記憶部１４３に格納する。
【０３３３】
［ステップＳ５０８］集計部１４１は、ジョブ種ごとの平均処理時間を用いて、各ジョブ種の１ジョブ当たりの正規化されたスループット値を計算する。１ジョブ当たりの正規化されたスループット値の計算手法は、第２の実施の形態で説明した通りである。集計部１４１は、計算したジョブごとの正規化されたスループット値を、正規化スループット値記憶部１４３に格納する。
【０３３４】
なお第４の実施の形態のように、出力されるメッセージ数でスループットを計算する場合もある。この場合、ステップＳ５０８の処理では、集計部１４１は、１ジョブ当たりの正規化されたスループット値の計算に代えて、各ジョブ種の１メッセージ当たりの正規化されたスループット値を計算する。１メッセージ当たりの正規化されたスループット値の計算手法は、第４の実施の形態で説明した通りである。
【０３３５】
このようにして、分析対象期間に採取された時系列データから、ジョブ種ごとの平均処理時間を算出することができる。
図４６は、多重度が閾値以下の集計区間の抽出例を示す図である。図４６の例では、５秒分の時系列データの５０の集計区間（集計区間長は０．１秒）の中で、多重度が１．０以下の集計区間が２３個含まれている。そして、多重度が１．０以下の２３個の集計区間に含まれているジョブだけから、ジョブ種ごとの平均処理時間が計算される。多重度が低いこれらの区間は、ジョブ同士の衝突が少なく、理想的な処理時間に近い値が収集できる。
【０３３６】
ここで、多重度の閾値を０．５に設定すると、得られる集計区間の数は１４に下がる。この閾値は低く設定した方が、ジョブ同士の衝突が少なく、算出される平均処理時間の精度は高くなる。他方、閾値は低く設定しすぎると、得られるデータ量が少なくなり、平均処理時間を計算できないジョブ種が生じる可能性がある。
【０３３７】
第８の実施の形態の手法は、一般的に多重度は増減が激しいものなので、ある程度の長さの時系列データを収集すれば、その中には多重度の低い部分も含まれていることが多いという考えに基づいている。また、多重度が低い部分は、ジョブ同士の衝突が起きる確率が低いので、理想に近い平均処理時間が得られるという考えにも基づいている。
【０３３８】
このように分析対象期間の時系列データからジョブ種ごとの平均処理時間を算出することによって、低負荷時のデータを別途収集する必要がなくなるので、管理者の手間が省ける。しかも、同一の時系列データから全ての情報を取得し、事前に取得する情報を必要としないので、負荷の特性（例えばジョブの平均処理時間など）が動的に変化した場合にも、適切な平均処理時間に基づく分析ができる。すなわち、正規化用の平均応答時間を測定した時の負荷と実運用時の負荷との負荷傾向の違いによって引き起こされる性能分析の不正確さを避けることができる。
【０３３９】
〔第９の実施の形態〕
次に第９の実施の形態について説明する。第９の実施の形態は、瞬間スループット低下を検出するものである。なお、第９の実施の形態を実現するシステム構成は第２の実施の形態と同様である。そこで、図６に示した第２の実施の形態の各要素を用いて第９の実施の形態の機能を説明する。
【０３４０】
Ａｐｐサーバ３００上でＪａｖａ（登録商標）ＶＭがＦｕｌｌ−ＧＣを起こした場合には、非常に短い時間の間、Ｊａｖａ（登録商標）ＶＭの動作が止まり、Ａｐｐサーバ３００の階層のスループットが一瞬だけ急激に低下することがある。このような現象が発生していることは、以下の手順で検出することが可能である。なお以下の瞬間スループット低下検出処理は、例えば図１６に示した第２の実施の形態のボトルネック判定処理（ステップＳ１２４）に代えて、分析部１４５により実行される。なお、分析部１４５は、図１６に示した第２の実施の形態のボトルネック判定処理（ステップＳ１２４）と瞬間スループット低下検出処理との両方を実行することもできる。
【０３４１】
図４７は、瞬間スループット低下検出処理の手順を示すフローチャートである。また以下、図４７に示す処理をステップ番号に沿って説明する。
［ステップＳ６０１］分析部１４５は、集計区間を１つ選択する。例えば分析部１４５は、処理対象となっている階層に対応する集計区間管理テーブル（図２２参照）の上位から順に、集計区間を選択する。
【０３４２】
［ステップＳ６０２］分析部１４５は、集計区間の多重度の最小値と最大値とを求める。
［ステップＳ６０３］分析部１４５は、ステップＳ６０２の処理が未処理の集計区間があるか否かを判断する。分析部１４５は、未処理の集計区間があれば、処理をステップＳ６０１に進める。また分析部１４５は、未処理に集計区間がなければ、処理をステップＳ６０４に進める。
【０３４３】
［ステップＳ６０４］分析部１４５は、多重度の最小値と最大値との間を等間隔に分割する。例えば分析部１４５は、多重度の最小値と最大値の間を、一定数（例えば１００）もしくは一定間隔ごと（例えば多重度０．１ごと）に分割する。例えば図２６に示す散布図に示されるような多重度が得られた場合、０と５０の間を０．５刻みで１００分割する（説明を簡便にするために５０を超えている多重度は無視している）。分割によって、複数の多重度区間が生成される。
【０３４４】
［ステップＳ６０５］分析部１４５は、分割によって生成された多重度区間のうち、ステップＳ６０６〜Ｓ６０７の処理が未処理の多重度区間を１つ選択する。
［ステップＳ６０６］分析部１４５は、スループットの統計上の信頼区間を算出する。例えば分析部１４５は、選択した多重度区間の範囲に属する多重度を持つ全ての集計区間から、スループットの平均値と標準偏差を計算し、以下の式（５）の信頼区間を得る。ここでは、例として信頼度を９５％として信頼区間を求める。
【０３４５】
【数５】
【０３４６】
式（５）中で、１．９６は９５％信頼区間の定数である。
［ステップＳ６０７］分析部１４５は、スループットが信頼区間の下限未満の集計区間を計数する。
【０３４７】
［ステップＳ６０８］分析部１４５は、ステップＳ６０６〜Ｓ６０７の処理が未処理の多重度区間があるか否かを判断する。分析部１４５は、未処理の多重度区間があれば、処理をステップＳ６０５に進める。また分析部１４５は、未処理の多重度区間がなければ、処理をステップＳ６０９に進める。
【０３４８】
［ステップＳ６０９］分析部１４５は、集計区間全体に対する、ステップＳ６０７で計数されたスループットが信頼区間の下限未満であった集計区間の割合を算出する。例えば分析部１４５は、９５％信頼区間を求めた場合、スループットの９５％信頼区間を下回るスループットを持っていた集計区間の割合を求める。
【０３４９】
［ステップＳ６１０］分析部１４５は、ステップＳ６０９で算出した割合が、閾値を超えているか否かを判断する。このときの閾値は、集計区間のスループットが信頼区間の下限を下回る統計的な確率よりも大きな値が、予め設定される。例えば９５％信頼区間の場合は、下限を下回る統計的確率が２．５％あるので、それよりも大きな値（例えば５％）が、閾値に設定される。分析部１４５は、割合が閾値を超えている場合、処理をステップＳ６１１に進める。また分析部１４５は、割合が閾値を超えていない場合、処理をステップＳ６１２に進める。
【０３５０】
［ステップＳ６１１］分析部１４５は、異常な瞬間スループットの低下が発生していると判断する。分析部１４５は、例えば判断結果をモニタ１１に表示する。その後、分析部１４５は、瞬間スループット低下検出処理を終了する。
【０３５１】
［ステップＳ６１２］分析部１４５は、異常な瞬間スループットの低下が発生していないと判断する。分析部１４５は、例えば判断結果をモニタ１１に表示する。その後、分析部１４５は、瞬間スループット低下検出処理を終了する。
【０３５２】
このようにして、信頼区間を下回るスループットを持つ集計区間の、全体に占める割合が、予め決めた閾値を超えた場合は、その階層において異常な瞬間スループット低下が発生していると判断される。例えばＡｐｐサーバ３００上のＪａｖａ（登録商標）ＶＭがＦｕｌｌ−ＧＣを起こした場合などのように、多重度に関係なく瞬間的なスループット低下を起こした場合に、演算処理によって、異常な瞬間スループット低下の発生を検出することが可能となる。
【０３５３】
図４８は、第９の実施の形態により異常な瞬間スループット低下が検出される散布図の一例である。図４８に示すように、Ｊａｖａ（登録商標）ＶＭのＦｕｌｌ−ＧＣなどによって引き起こされた異常な瞬間スループット低下の発生が、容易に検出できる。
【０３５４】
なお、第９の実施の形態は、第４の実施の形態と組み合わせることで、効果が顕著となる。例えば、図３８、図３９で示したように、第４の実施の形態を用いると瞬間的なスループット低下が顕著に表れる。このように顕在化させた瞬間スループットの低下を、第９の実施の形態の手法によって、機械的処理で検出可能となる。
【０３５５】
〔その他の実施形態〕
第２の実施の形態では、ネットワークからキャプチャしたＩＰパケットに基づいてメッセージを再現しているが、この手法はプロトコルメッセージを再現する手法の１つに過ぎず、他の手法でメッセージを再現することも可能である。例えば、多階層システムに含まれる各サーバで、実行したジョブのログを記録しておき、各サーバに記録されたログに基づいてメッセージを再現することも可能である。
【０３５６】
ただし、ＩＰパケットをキャプチャしてメッセージを再現すれば、コンピュータ間の時計誤差の問題の発生が抑止されるという利点がある。すなわち、多階層システムにおいて、各サーバの時刻を正確に一致させるのは難しく、若干の誤差が生じてしまうことが多い。しかし、メッセージフローを再現するには、異なるサーバから送信されたメッセージ間の前後関係を正確に判別できることが重要である。複数のサーバの時刻間にずれがあると、各サーバでデータを採取した時刻にずれが生じ、メッセージフローの再現性が低下する。各階層のサーバでログを記録する手法の場合、異なるサーバのログを比較する際に、各ログの時刻が不正確であることで、ログ間の前後関係の正確な判定が困難となる。他方、ＩＰパケットを１つの装置でキャプチャすれば、パケットが転送された時刻の前後関係を正確に判断できる。その結果、メッセージを正確に再現することが可能となる。
【０３５７】
また、ＩＰパケットをキャプチャしてメッセージを再現する手法には、多階層システムに含まれるサーバにおいてデータを保存したり、保存したデータを分析装置に転送したりする処理が不要である利点もある。例えば多階層システムに含まれる各サーバで取得したログからメッセージを再現する手法では、各サーバがログを記憶し、さらに記憶したログを分析装置に転送することとなる。ＩＰパケットをキャプチャしてメッセージを再現する手法であれば、各サーバでログを記憶せずにすみ、ネットワーク上に新たなパケット転送を生じさせることもない。
【０３５８】
なお、上記の各実施の形態に示した処理機能は、コンピュータによって実現することができる。その場合、情報処理装置１または分析サーバ１００が有する機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記憶装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記憶装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ／ＲＷなどがある。光磁気記録媒体には、ＭＯなどがある。
【０３５９】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【０３６０】
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。
【０３６１】
また、上記の処理機能の少なくとも一部を、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）などの電子回路で実現することもできる。
【０３６２】
以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。ただし、スループットを算出する具体的な手法については、第２の実施の形態と第４の実施の形態とのいずれか一方の手法を採用することができる。また、飽和多重度の決定手法については、第２の実施の形態と第５の実施の形態とのいずれかの手法を採用することができる。
【０３６３】
以上の実施の形態に開示された技術には、以下の付記に示す技術が含まれる。
（付記１） コンピュータに、
分析対象装置で分析対象期間内に実行された処理の実行期間を示す情報を記憶手段から取得し、該取得した情報に基づいて、前記分析対象期間を細分化して得られる集計区間ごとに、集計区間内で実行された処理それぞれの実行に費やされた時間を合計した合計処理時間と、集計区間内で実行された処理それぞれの進行量を合計した合計進行量とを計算し、
集計区間ごとの合計処理時間と合計進行量とに基づいて、合計処理時間の増加量に対する合計進行量の増加量が所定値以下となる合計処理時間の閾値を決定し、
合計処理時間が前記閾値以上の集計区間を検出する、
処理を実行させるプログラム。
【０３６４】
（付記２） 集計区間で実行された処理の進行量は、該処理を依頼した処理要求に応じて実行される処理全体のうちの、該集計区間で実行された割合であることを特徴とする付記１記載のプログラム。
【０３６５】
（付記３） 集計区間で実行された処理の進行量は、該処理を依頼した処理要求に応じて実行される処理全体のうちの、該集計区間で実行された割合に、各処理種別に属する処理の低負荷時の処理時間に基づく重み付けを行った値であることを特徴とする付記１記載のプログラム。
【０３６６】
（付記４） 集計区間の総数に対する、前記閾値以上の合計処理時間の集計区間の割合が所定数以上の場合、前記分析対象期間において前記分析対象装置の処理が処理能力の限界に達していると判断することを特徴とする付記１乃至３のいずれかに記載のプログラム。
【０３６７】
（付記５） 他の装置への処理要求の送信を伴う処理については、処理の最初の実行期間を除外して、合計処理時間と合計進行量とを計算することを特徴とする付記１乃至４のいずれかに記載のプログラム。
【０３６８】
（付記６） 集計区間で実行された処理の進行量は、該集計区間に出力されたメッセージ数に応じた値であることを特徴とする付記１記載のプログラム。
（付記７） 集計区間で実行された処理の進行量は、該処理の全体で出力されるメッセージ数のうち、該集計区間に出力されたメッセージ数の割合に、各処理種別に属する処理の低負荷時の処理時間に基づく重み付けを行った値であることを特徴とする付記６記載のプログラム。
【０３６９】
（付記８） 集計区間それぞれの合計処理時間の最小値から最大値までの範囲を細分化して得られる細分化区間ごとに、細分化区間内の合計処理時間を有する集計区間の合計処理時間を平均した平均処理時間と、細分化区間内の合計処理時間を有する集計区間の合計進行量を平均した平均処理進行量とを計算し、隣接する細分化区間における平均処理時間の増加量に対する平均処理進行量の変化量を示す傾きを計算し、隣接する細分化区間の傾きに基づいて、前記閾値を決定することを特徴とする付記１乃至７のいずれかに記載のプログラム。
【０３７０】
（付記９） 集計区間それぞれの合計処理時間の最小値から最大値までの範囲を細分化して得られる細分化区間ごとに、細分化区間内の合計処理時間を有する集計区間から合計処理時間と合計進行量それぞれの平均値を計算し、範囲に含む合計処理時間の短い細分化区間から順に、合計処理時間と合計進行量それぞれの平均値から計算される傾きを一つずつ加えていきながら、傾きの統計上の信頼区間を求めていき、該信頼区間の下限が所定値を下回った細分化区間の合計処理時間を、前記閾値とすることを特徴とする付記１乃至７のいずれかに記載のプログラム。
【０３７１】
（付記１０） 前記閾値未満の合計処理時間の集計区間それぞれの合計進行量と最大合計処理進行量との差分の総和を、前記分析対象装置の余力と判断することを特徴とする付記１乃至９のいずれかに記載のプログラム。
【０３７２】
（付記１１） 分析対象期間を集計区間に分割する際には、合計処理時間が所定値より低い集計区間それぞれにおける合計処理時間と合計進行量との関係を示す数値のばらつきが所定値より低くなる範囲内の最も短い時間を、集計区間の長さとすることを特徴とする付記１乃至１０のいずれかに記載のプログラム。
【０３７３】
（付記１２） 合計処理時間が所定値以下の集計区間を抽出し、抽出した集計区間内で実行された処理の、処理種別ごとの平均処理時間を計算し、処理種別の平均処理時間に応じた値を、各処理種別に属する処理の重みとすることを特徴とする付記３または７のいずれかに記載のプログラム。
【０３７４】
（付記１３） 集計区間それぞれの合計処理時間の最小値から最大値までの範囲を細分化して得られる細分化区間ごとに、細分化区間内の合計処理時間を有する集計区間から合計進行量の分布の統計上の信頼区間を求め、信頼区間の下限値以下の合計進行量を有する集計区間の、集計区間全体に対する割合を求め、該割合が一定の閾値を超えている場合に、前記分析対象装置において前記分析対象期間内で異常な瞬間性能低下が発生していると判断することを特徴とする付記１乃至１２のいずれかに記載のプログラム。
【０３７５】
（付記１４） コンピュータが、
分析対象装置で分析対象期間内に実行された処理の実行期間を示す情報を記憶手段から取得し、該取得した情報に基づいて、前記分析対象期間を細分化して得られる集計区間ごとに、集計区間内で実行された処理それぞれの実行に費やされた時間を合計した合計処理時間と、集計区間内で実行された処理それぞれの進行量を合計した合計進行量とを計算し、
集計区間ごとの合計処理時間と合計進行量とに基づいて、合計処理時間の増加量に対する合計進行量の増加量が所定値以下となる合計処理時間の閾値を決定し、
合計処理時間が前記閾値以上の集計区間を検出する、
処理を実行する分析方法。
【０３７６】
（付記１５） 分析対象装置で分析対象期間内に実行された処理の実行期間を示す情報を記憶手段から取得し、該取得した情報に基づいて、前記分析対象期間を細分化して得られる集計区間ごとに、集計区間内で実行された処理それぞれの実行に費やされた時間を合計した合計処理時間と、集計区間内で実行された処理それぞれの進行量を合計した合計進行量とを計算する計算手段と、
集計区間ごとの合計処理時間と合計進行量とに基づいて、合計処理時間の増加量に対する合計進行量の増加量が所定値以下となる合計処理時間の閾値を決定する決定手段と、
合計処理時間が前記閾値以上の集計区間を検出する検出手段と、
を有する情報処理装置。
【符号の説明】
【０３７７】
１ 情報処理装置
１ａ 監視手段
１ｂ 記憶手段
１ｃ 計算手段
１ｄ 決定手段
１ｅ 検出手段
２ ネットワーク
３ 端末装置
４ Ｗｅｂサーバ
５ Ａｐｐサーバ
６ ＤＢサーバ
【特許請求の範囲】
【請求項１】
コンピュータに、
分析対象装置で分析対象期間内に実行された処理の実行期間を示す情報を記憶手段から取得し、該取得した情報に基づいて、前記分析対象期間を細分化して得られる集計区間ごとに、集計区間内で実行された処理それぞれの実行に費やされた時間を合計した合計処理時間と、集計区間内で実行された処理それぞれの進行量を合計した合計進行量とを計算し、
集計区間ごとの合計処理時間と合計進行量とに基づいて、合計処理時間の増加量に対する合計進行量の増加量が所定値以下となる合計処理時間の閾値を決定し、
合計処理時間が前記閾値以上の集計区間を検出する、
処理を実行させるプログラム。
【請求項２】
集計区間で実行された処理の進行量は、該処理を依頼した処理要求に応じて実行される処理全体のうちの、該集計区間で実行された割合に、各処理種別に属する処理の低負荷時の処理時間に基づく重み付けを行った値であることを特徴とする請求項１記載のプログラム。
【請求項３】
集計区間の総数に対する、前記閾値以上の合計処理時間の集計区間の割合が所定数以上の場合、前記分析対象期間において前記分析対象装置の処理が処理能力の限界に達していると判断することを特徴とする請求項１乃至２のいずれかに記載のプログラム。
【請求項４】
他の装置への処理要求の送信を伴う処理については、処理の最初の実行期間を除外して、合計処理時間と合計進行量とを計算することを特徴とする請求項１乃至３のいずれかに記載のプログラム。
【請求項５】
集計区間で実行された処理の進行量は、該集計区間に出力されたメッセージ数に応じた値であることを特徴とする請求項１記載のプログラム。
【請求項６】
集計区間それぞれの合計処理時間の最小値から最大値までの範囲を細分化して得られる細分化区間ごとに、細分化区間内の合計処理時間を有する集計区間から合計処理時間と合計進行量それぞれの平均値を計算し、範囲に含む合計処理時間の短い細分化区間から順に、合計処理時間と合計進行量それぞれの平均値から計算される傾きを一つずつ加えていきながら、傾きの統計上の信頼区間を求めていき、該信頼区間の下限が所定値を下回った細分化区間の合計処理時間を、前記閾値とすることを特徴とする請求項１乃至５のいずれかに記載のプログラム。
【請求項７】
前記閾値未満の合計処理時間の集計区間それぞれの合計進行量と最大合計処理進行量との差分の総和を、前記分析対象装置の余力と判断することを特徴とする請求項１乃至６のいずれかに記載のプログラム。
【請求項８】
分析対象期間を集計区間に分割する際には、合計処理時間が所定値より低い集計区間それぞれにおける合計処理時間と合計進行量との関係を示す数値のばらつきが所定値より低くなる範囲内の最も短い時間を、集計区間の長さとすることを特徴とする請求項１乃至７のいずれかに記載のプログラム。
【請求項９】
合計処理時間が所定値以下の集計区間を抽出し、抽出した集計区間内で実行された処理の、処理種別ごとの平均処理時間を計算し、処理種別の平均処理時間に応じた値を、各処理種別に属する処理の重みとすることを特徴とする請求項２記載のプログラム。
【請求項１０】
集計区間それぞれの合計処理時間の最小値から最大値までの範囲を細分化して得られる細分化区間ごとに、細分化区間内の合計処理時間を有する集計区間から合計進行量の分布の統計上の信頼区間を求め、信頼区間の下限値以下の合計進行量を有する集計区間の、集計区間全体に対する割合を求め、該割合が一定の閾値を超えている場合に、前記分析対象装置において前記分析対象期間内で異常な瞬間性能低下が発生していると判断することを特徴とする請求項１乃至９のいずれかに記載のプログラム。
【請求項１１】
コンピュータが、
分析対象装置で分析対象期間内に実行された処理の実行期間を示す情報を記憶手段から取得し、該取得した情報に基づいて、前記分析対象期間を細分化して得られる集計区間ごとに、集計区間内で実行された処理それぞれの実行に費やされた時間を合計した合計処理時間と、集計区間内で実行された処理それぞれの進行量を合計した合計進行量とを計算し、
集計区間ごとの合計処理時間と合計進行量とに基づいて、合計処理時間の増加量に対する合計進行量の増加量が所定値以下となる合計処理時間の閾値を決定し、
合計処理時間が前記閾値以上の集計区間を検出する、
処理を実行する分析方法。
【請求項１２】
分析対象装置で分析対象期間内に実行された処理の実行期間を示す情報を記憶手段から取得し、該取得した情報に基づいて、前記分析対象期間を細分化して得られる集計区間ごとに、集計区間内で実行された処理それぞれの実行に費やされた時間を合計した合計処理時間と、集計区間内で実行された処理それぞれの進行量を合計した合計進行量とを計算する計算手段と、
集計区間ごとの合計処理時間と合計進行量とに基づいて、合計処理時間の増加量に対する合計進行量の増加量が所定値以下となる合計処理時間の閾値を決定する決定手段と、
合計処理時間が前記閾値以上の集計区間を検出する検出手段と、
を有する情報処理装置。
【請求項１】
コンピュータに、
分析対象装置で分析対象期間内に実行された処理の実行期間を示す情報を記憶手段から取得し、該取得した情報に基づいて、前記分析対象期間を細分化して得られる集計区間ごとに、集計区間内で実行された処理それぞれの実行に費やされた時間を合計した合計処理時間と、集計区間内で実行された処理それぞれの進行量を合計した合計進行量とを計算し、
集計区間ごとの合計処理時間と合計進行量とに基づいて、合計処理時間の増加量に対する合計進行量の増加量が所定値以下となる合計処理時間の閾値を決定し、
合計処理時間が前記閾値以上の集計区間を検出する、
処理を実行させるプログラム。
【請求項２】
集計区間で実行された処理の進行量は、該処理を依頼した処理要求に応じて実行される処理全体のうちの、該集計区間で実行された割合に、各処理種別に属する処理の低負荷時の処理時間に基づく重み付けを行った値であることを特徴とする請求項１記載のプログラム。
【請求項３】
集計区間の総数に対する、前記閾値以上の合計処理時間の集計区間の割合が所定数以上の場合、前記分析対象期間において前記分析対象装置の処理が処理能力の限界に達していると判断することを特徴とする請求項１乃至２のいずれかに記載のプログラム。
【請求項４】
他の装置への処理要求の送信を伴う処理については、処理の最初の実行期間を除外して、合計処理時間と合計進行量とを計算することを特徴とする請求項１乃至３のいずれかに記載のプログラム。
【請求項５】
集計区間で実行された処理の進行量は、該集計区間に出力されたメッセージ数に応じた値であることを特徴とする請求項１記載のプログラム。
【請求項６】
集計区間それぞれの合計処理時間の最小値から最大値までの範囲を細分化して得られる細分化区間ごとに、細分化区間内の合計処理時間を有する集計区間から合計処理時間と合計進行量それぞれの平均値を計算し、範囲に含む合計処理時間の短い細分化区間から順に、合計処理時間と合計進行量それぞれの平均値から計算される傾きを一つずつ加えていきながら、傾きの統計上の信頼区間を求めていき、該信頼区間の下限が所定値を下回った細分化区間の合計処理時間を、前記閾値とすることを特徴とする請求項１乃至５のいずれかに記載のプログラム。
【請求項７】
前記閾値未満の合計処理時間の集計区間それぞれの合計進行量と最大合計処理進行量との差分の総和を、前記分析対象装置の余力と判断することを特徴とする請求項１乃至６のいずれかに記載のプログラム。
【請求項８】
分析対象期間を集計区間に分割する際には、合計処理時間が所定値より低い集計区間それぞれにおける合計処理時間と合計進行量との関係を示す数値のばらつきが所定値より低くなる範囲内の最も短い時間を、集計区間の長さとすることを特徴とする請求項１乃至７のいずれかに記載のプログラム。
【請求項９】
合計処理時間が所定値以下の集計区間を抽出し、抽出した集計区間内で実行された処理の、処理種別ごとの平均処理時間を計算し、処理種別の平均処理時間に応じた値を、各処理種別に属する処理の重みとすることを特徴とする請求項２記載のプログラム。
【請求項１０】
集計区間それぞれの合計処理時間の最小値から最大値までの範囲を細分化して得られる細分化区間ごとに、細分化区間内の合計処理時間を有する集計区間から合計進行量の分布の統計上の信頼区間を求め、信頼区間の下限値以下の合計進行量を有する集計区間の、集計区間全体に対する割合を求め、該割合が一定の閾値を超えている場合に、前記分析対象装置において前記分析対象期間内で異常な瞬間性能低下が発生していると判断することを特徴とする請求項１乃至９のいずれかに記載のプログラム。
【請求項１１】
コンピュータが、
分析対象装置で分析対象期間内に実行された処理の実行期間を示す情報を記憶手段から取得し、該取得した情報に基づいて、前記分析対象期間を細分化して得られる集計区間ごとに、集計区間内で実行された処理それぞれの実行に費やされた時間を合計した合計処理時間と、集計区間内で実行された処理それぞれの進行量を合計した合計進行量とを計算し、
集計区間ごとの合計処理時間と合計進行量とに基づいて、合計処理時間の増加量に対する合計進行量の増加量が所定値以下となる合計処理時間の閾値を決定し、
合計処理時間が前記閾値以上の集計区間を検出する、
処理を実行する分析方法。
【請求項１２】
分析対象装置で分析対象期間内に実行された処理の実行期間を示す情報を記憶手段から取得し、該取得した情報に基づいて、前記分析対象期間を細分化して得られる集計区間ごとに、集計区間内で実行された処理それぞれの実行に費やされた時間を合計した合計処理時間と、集計区間内で実行された処理それぞれの進行量を合計した合計進行量とを計算する計算手段と、
集計区間ごとの合計処理時間と合計進行量とに基づいて、合計処理時間の増加量に対する合計進行量の増加量が所定値以下となる合計処理時間の閾値を決定する決定手段と、
合計処理時間が前記閾値以上の集計区間を検出する検出手段と、
を有する情報処理装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図４３】
【図４４】
【図４５】
【図４６】
【図４７】
【図４８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図４３】
【図４４】
【図４５】
【図４６】
【図４７】
【図４８】
【公開番号】特開２０１３−９７７８３（Ｐ２０１３−９７７８３Ａ）
【公開日】平成２５年５月２０日（２０１３．５．２０）
【国際特許分類】
【出願番号】特願２０１２−２６２９３（Ｐ２０１２−２６２９３）
【出願日】平成２４年２月９日（２０１２．２．９）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【出願人】（５０７０７１０７３）ジョージア・テック・リサーチ・コーポレーション (4)
【Ｆターム（参考）】
【公開日】平成２５年５月２０日（２０１３．５．２０）
【国際特許分類】
【出願日】平成２４年２月９日（２０１２．２．９）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【出願人】（５０７０７１０７３）ジョージア・テック・リサーチ・コーポレーション (4)
【Ｆターム（参考）】
[ Back to top ]