JP5282908B2 - 階層型負荷推定システム、方法およびプログラム - Google Patents

Description

本発明は、システムにおける負荷を推定するための技術に関する。特に、本発明は、多層システムにおける階層型負荷を推定するための技術に関する。

システムの構築は、設計フェーズ、開発フェーズ、運用フェーズの三つのフェーズに分けられる。一般に、設計フェーズでは機能が、開発フェーズでは実装が、運用フェーズでは性能が主要な問題となる。これらのフェーズは、新規システムを構築するときだけでなく、既存システムを変更するときにも現れる。

運用フェーズにおいてシステムが十分な性能を発揮するためには、支障なく機能を提供できるだけの十分な計算機資源が必要である。必要な計算機資源の量は、機能を提供する際に発生する負荷の量に依存する。少ない負荷を発生させる機能は少ない計算機資源で提供でき、多くの負荷を発生させる機能は多くの計算機資源を必要とする。従って、システム性能を評価するためには、システム負荷を測定することが望ましい。

運用フェーズにおいてシステム負荷を測定するための技術として、次のものが知られている。例えば、文献“ｇｐｒｏｆ： Ａ Ｃａｌｌ Ｇｒａｐｈ Ｅｘｅｃｕｔｉｏｎ Ｐｒｏｆｉｌｅｒ， ｂｙ Ｓ． Ｇｒａｈａｍ， Ｐ． Ｋｅｓｓｌｅｒ ａｎｄ Ｍ． Ｍｃｋｕｓｉｃｋ， Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ １９８２ ＳＩＧＰＬＡＮ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｃｏｍｐｉｌｅｒ Ｃｏｎｓｔｒｕｃｔｉｏｎ， Ｖｏｌ． １７， Ｎｏ． ６， ｐｐ． １２０−１２６， １９８２．”に開示されているプロファイリング技術を用いれば、プログラム中の個々の関数の呼出回数をカウントすることができる。また、特開２００５―１９０２７７号公報には、サーバープログラム間の通信を観測することで得られるＩＰアドレスとポート番号から、サーバープログラムの呼出頻度をカウントする方法が記載されている。

運用フェーズにおいてシステム性能の不足が発覚したとき、十分な性能を達成するために設計等を見直さなければならない場合がある。しかしながらこの場合、多大な手戻りの工数が発生し、システム構築コストが増大する。逆に言えば、もし上流フェーズの段階でシステム性能やシステム負荷を推定することができれば、手戻り工数を抑制し、コスト増大を抑制することができる。特に、設計フェーズの段階でシステム負荷を推定することは、システム構築コストの削減に有効である。

しかしながら、設計フェーズにおいて従来使用できた技術は、主にシステムの機能設計に関する技術であった。例えば、文献“ＡｌｌＦｕｓｉｏｎ（登録商標） ＥＲｗｉｎ（登録商標） Ｄａｔａ Ｍｏｄｅｌｅｒ ｒ７．”には、データベースの機能設計ツールとしての「ＥＲｗｉｎ（登録商標）」が紹介されている。このツールは、論理設計の物理設計への変換、個別処理の最適化、既存のデータベースのリバースエンジニアリング等の機能を提供している。また、特開平８―２０２５４１号公報には、ＤＦＤ（Data Flow Diagram）の変更とＥＲ（Entity Relationship）の変更を相互に反映させる方法が記載されている。しかし、これらのツールや方法では、設計フェーズにおいてシステム負荷を推定することはできない。

近年、階層構造を有する「多層システム」が増加している。多層システムでは、処理内容の頻繁な変更に対応できるように、また、性能を容易に向上させられるように、サービス要求は複数のサーバー層でパイプライン的に処理される。典型的な多層システムとしては、ウェブ層で表示処理を、アプリケーション層で演算処理を、データベース層でデータ処理を行う三層システムが知られている。このような多層システムの性能は、複数のサーバー層のうちボトルネック層の性能によって主に決定される。例えば上記三層システムの場合、一般的にはデータベース層がボトルネックとなり、そのデータベース層の性能が三層システムの性能を決定する。従って、三層システムの性能を定量的に推定するためには、ボトルネック層となりがちなデータベース層にかかる負荷を定量的に推定することが好ましい。

データベース層には、階層的な負荷（以下、「階層型負荷」と参照される）がかかる。多層システムでは、上位層の処理が下位層の処理を呼び出す。つまり、サービス要求によって呼び出される処理が他の処理を呼び出し、呼び出された処理が更に他の処理を呼び出し、というように処理が階層的に呼び出される。そのような処理は、以下「階層処理」と参照される。階層型負荷とは、このように階層的に呼び出される階層処理によって生じる負荷である。データベース層は、通常は多層システムの最下位層である。従って、データベース層には階層型負荷がかかる。

また、データベース層への処理要求のほとんどは、「ＤＭＬ（Data Manipulation Language）文」で発行される。ＤＭＬ文は、データベースに対する問い合わせに使用されるＳＱＬ（Structured Query Language）文の一部である。ＳＱＬ文は大きくわけて、ＤＭＬ文、ＤＤＬ（Data Definition Language）文、ＤＣＬ（Data Control Language）文の三種類に分類されるが、ほとんどの負荷はＤＭＬ文の処理によって生じる。ＤＭＬ文としては、データ抽出を指示する“ｓｅｌｅｃｔ文”、データ更新を指示する“ｕｐｄａｔｅ文”、データ挿入を指示する“ｉｎｓｅｒｔ文”、データ削除を指示する“ｄｅｌｅｔｅ文”などが挙げられる。これらＤＭＬ文には、データが操作されるテーブル、つまり、アクセス対象のデータセットが明記される。尚、アクセスするデータ量が同じであっても、ＤＭＬ文の種類に依って処理内容と処理量は異なる。例えば、ｓｅｌｅｃｔ文ではデータ読み出し処理だけが発生するが、ｕｐｄａｔｅ文ではデータ書き込みだけでなく、データロックやログの書き込み等の処理が発生する。

本発明の１つの目的は、多層システムにおける階層型負荷を設計フェーズにおいて定量的に推定することができる技術を提供することにある。

本発明の第１の観点において、階層型負荷推定システムが提供される。その階層型負荷推定システムは、記憶装置と、呼出回数算出モジュールと、発行回数算出モジュールとを備える。記憶装置には、多層システムにおいて階層的に呼び出される階層処理の設計を示す階層呼出情報と、階層処理のうちデータベース操作処理によって発行されるデータベース操作文を規定する発行情報とが格納される。呼出回数算出モジュールは、階層呼出情報を参照して、データベース操作処理の呼出回数を算出する。発行回数算出モジュールは、算出された呼出回数と発行情報を参照して、データベース操作処理によって発行されるデータベース操作文の発行回数を算出する。

本発明の第２の観点において、階層型負荷推定方法が提供される。その階層型負荷推定方法は、多層システムにおいて階層的に呼び出される階層処理の設計を示す階層呼出情報を記憶装置から読み出すことと、階層処理のうちデータベース操作処理によって発行されるデータベース操作文を規定する発行情報を記憶装置から読み出すことと、階層呼出情報を参照して、データベース操作処理の呼出回数を算出することと、算出された呼出回数と発行情報を参照して、データベース操作処理によって発行されるデータベース操作文の発行回数を算出することと、を含む。

本発明の第３の観点において、階層型負荷推定プログラムが提供される。その階層型負荷推定プログラムは、多層システムにおいて階層的に呼び出される階層処理の設計を示す階層呼出情報を記憶装置から読み出すことと、階層処理のうちデータベース操作処理によって発行されるデータベース操作文を規定する発行情報を記憶装置から読み出すことと、階層呼出情報を参照して、データベース操作処理の呼出回数を算出することと、算出された呼出回数と発行情報を参照して、データベース操作処理によって発行されるデータベース操作文の発行回数を算出することと、をコンピュータに実行させる。

本発明によって算出されたデータベース操作文の発行回数から、データベース層にかかる階層型負荷を見積もることができる。つまり、多層システムにおける階層型負荷を定量的に推定することができる。その階層型負荷の推定において、実際にシステムを構築することは不要である。たとえ設計フェーズの段階であっても、階層型負荷を定量的に推定することが可能となる。これにより、運用フェーズから設計フェーズへの戻りが防止され、システム構築コストが削減される。

上記及び他の目的、長所、特徴は、次の図面と共に説明される本発明の実施の形態により明らかになるであろう。

図１は、多層システムにおける階層処理及び本発明の実施の形態において用いられる情報を説明するための概念図である。 図２は、本発明の実施の形態に係る階層型負荷推定システムの構成例を示すブロック図である。 図３は、外部呼出回数情報の一例を示す概念図である。 図４Ａは、プロシージャ呼出情報の一例を示す概念図である。 図４Ｂは、プロシージャ呼出情報の他の例を示す概念図である。 図５は、ＤＭＬ発行情報の一例を示す概念図である。 図６は、ＤＭＬ負荷情報の一例を示す概念図である。 図７は、本発明の実施の形態に係る階層型負荷システムによる処理フローを示すブロック図である。 図８は、本発明の実施の形態に係る階層型負荷システムによる処理フローを示すフローチャートである。 図９は、ステップＳ１００を示すフローチャートである。 図１０は、ステップＳ１４０の一例を示すフローチャートである。 図１１は、ステップＳ２００を示すフローチャートである。 図１２は、第１及び第２の処理例における外部呼出回数情報を示す概念図である。 図１３は、第１及び第２の処理例におけるプロシージャ呼出情報を示す概念図である。 図１４は、第１の処理例におけるＤＭＬ発行情報を示す概念図である。 図１５は、第１の処理例におけるＤＭＬ負荷情報を示す概念図である。 図１６は、第１の処理例における最下位呼出回数情報を示す概念図である。 図１７は、第１の処理例における発行回数情報を示す概念図である。 図１８は、第１の処理例における推定負荷情報を示す概念図である。 図１９は、第２の処理例におけるＤＭＬ発行情報を示す概念図である。 図２０は、第２の処理例におけるＤＭＬ負荷情報を示す概念図である。 図２１は、第２の処理例における発行回数情報を示す概念図である。 図２２は、第２の処理例における推定負荷情報を示す概念図である。

添付図面を参照して、本発明の実施の形態を説明する。

１．階層型負荷
本発明の実施の形態では、階層型負荷を推定するための技術が提供される。階層型負荷とは、複数の処理層を経て呼び出される処理によって生じる負荷である。例えば、処理ａ_１〜ａ_ｐのそれぞれは処理ｂ_１〜ｂ_ｑのいずれかを呼び出し、処理ｂ_１〜ｂ_ｑのそれぞれは処理ｃ_１〜ｃ_ｒのいずれかを呼び出すとする。このとき、処理ｃ_１〜ｃ_ｒによって生じる負荷は階層型負荷である。なぜなら、処理ｃ_１〜ｃ_ｒは、処理ａ_１〜ａ_ｐからなる処理層と処理ｂ_１〜ｂ_ｑからなる処理層を経て、つまり複数の処理層を経て呼び出される処理だからである。

多層システムでは、上位層の処理が下位層の処理を呼び出すため、階層型負荷が発生する。図１は、多層システムにおいて階層的に呼び出される階層処理を説明するための概念図である。ユーザーが直接呼び出す処理、または、システムの最上位で呼び出される処理は、以下「サービス」と参照される。それ以外の処理は、以下「プロシージャ」と参照される。階層処理において、サービスはプロシージャを呼び出す。また、階層処理において、プロシージャが他のプロシージャを呼び出すことが許される。このとき、呼び出す側（上位層側）のプロシージャは「上位プロシージャ」と参照され、呼び出される側（下位層側）のプロシージャは「下位プロシージャ」と参照される。

図１に示されるように、サービス（ＳＡ，ＳＢ，ＳＣ・・・）の各々は、プロシージャ（Ｐ１Ａ，Ｐ１Ｂ，Ｐ１Ｃ・・・）のうち少なくとも１つを呼び出す。このとき、サービス（ＳＡ，ＳＢ，ＳＣ・・・）は最上位プロシージャに相当し、プロシージャ（Ｐ１Ａ，Ｐ１Ｂ，Ｐ１Ｃ・・・）は下位プロシージャに相当する。更に、プロシージャ（Ｐ１Ａ，Ｐ１Ｂ，Ｐ１Ｃ・・・）は、プロシージャ（Ｐ２Ａ，Ｐ２Ｂ，Ｐ２Ｃ・・・）のうち少なくとも１つを呼び出してもよい。このとき、プロシージャ（Ｐ１Ａ，Ｐ１Ｂ，Ｐ１Ｃ・・・）が上位プロシージャに相当し、プロシージャ（Ｐ２Ａ，Ｐ２Ｂ，Ｐ２Ｃ・・・）が下位プロシージャに相当する。同様にして、プロシージャ（ＰｎＡ，ＰｎＢ，ＰｎＣ・・・）まで呼び出され得る。ここで、ｎは１以上の整数である。階層処理における最下位のプロシージャ（ＰｎＡ，ＰｎＢ，ＰｎＣ・・・）は、以下「最下位プロシージャ」と参照される。

また、階層処理のうちある階層の処理（プロシージャ）は、データベース層を操作するためのデータベース操作文を発行する。例えば、データベース操作文は、ＤＭＬ文である。データベース層に対してＤＭＬ文等のデータベース操作文を発行する処理は、データベース操作処理と参照される。本実施の形態において、データベース操作処理は、最下位プロシージャ（ＰｎＡ，ＰｎＢ，ＰｎＣ・・・）であるとする。

階層処理の最下位プロシージャ（ＰｎＡ，ＰｎＢ，ＰｎＣ・・・）は、それぞれ所定のＤＭＬ文を発行する。このＤＭＬ文は、多層システムのうち最下位層である「データベース層」への処理要求として発行される。最下位プロシージャは複数の処理層を経て呼び出されるため、その最下位プロシージャによって発行されるＤＭＬ文の負荷は、階層型負荷である。すなわち、データベース層には、階層型負荷であるＤＭＬ文の負荷がかかる。

多層システムにおいて、データベース層はボトルネック層となりがちであり、データベース層にかかる階層型負荷を見積もることが重要である。本発明の実施の形態によれば、設計フェーズにおいても、データベース層にかかる階層型負荷を定量的に推定することができる技術が提供される。そのためのシステムが、次に説明される「階層型負荷推定システム」である。

２．階層型負荷推定システム
図２は、本実施の形態に係る階層型負荷推定システム１の構成例を示すブロック図である。階層型負荷推定システム１は、記憶装置２、処理装置３、入力装置４、出力装置５を備えるコンピュータシステムである。記憶装置２は、ＲＡＭ（Random Access Memory）やＨＤＤ（Hard Disk Drive）等である。処理装置３は、ＣＰＵ（Central Processing Unit）を有し、プログラムを実行することによって様々な機能を提供する。入力装置４は、キーボード、マウス、メディアドライブ、入力インターフェース等である。出力装置５は、ディスプレイ、メディアドライブ、出力インターフェース等である。

記憶装置２には、階層呼出情報１０、ＤＭＬ発行情報２０、ＤＭＬ負荷情報３０、推定負荷情報ＲＥＳなどが格納される。階層呼出情報１０は、外部呼出回数情報１１とプロシージャ呼出情報１２とを含んでいる。これら階層呼出情報１０、ＤＭＬ発行情報２０、ＤＭＬ負荷情報３０は、階層型負荷の算出に用いられるデータであり、推定負荷情報ＲＥＳは、その算出結果を示す。つまり、階層型負荷推定システム１は、階層呼出情報１０、ＤＭＬ発行情報２０、ＤＭＬ負荷情報３０を入力とし、推定負荷情報ＲＥＳを出力とする。

階層呼出情報１０は、既出の図１で示されるような階層処理の設計を示す。より詳細には、階層呼出情報１０は、外部呼出回数情報１１とプロシージャ呼出情報１２とを含んでいる。

外部呼出回数情報１１は、外部から要求されるサービスに関連する情報であり、サービスの想定される呼出回数を示す。図３は、外部呼出回数情報１１の一例を示している。図３に示されるように、外部呼出回数情報１１は、複数のサービス（ＳＡ，ＳＢ，ＳＣ・・・）のそれぞれに関して、サービス名と想定される呼出回数との対応関係を示している。

一方、プロシージャ呼出情報１２は、階層処理における上位プロシージャと下位プロシージャとの間の呼び出し関係を規定する情報である。既出の図１に示されるように、階層処理の設計に応じて、プロシージャ呼出情報１２は、ｎ種類のプロシージャ呼出情報１２−１〜１２−ｎを含み得る（ｎは１以上の整数）。プロシージャ呼出情報１２−１は、サービス（ＳＡ，ＳＢ，ＳＣ・・・）と下位プロシージャ（Ｐ１Ａ，Ｐ１Ｂ，Ｐ１Ｃ・・・）との間の呼び出し関係を規定する。プロシージャ呼出情報１２−２は、上位プロシージャ（Ｐ１Ａ，Ｐ１Ｂ，Ｐ１Ｃ・・・）と下位プロシージャ（Ｐ２Ａ，Ｐ２Ｂ，Ｐ２Ｃ・・・）との間の呼び出し関係を規定する。プロシージャ呼出情報１２−ｎは、上位プロシージャと最下位プロシージャ（ＰｎＡ，ＰｎＢ，ＰｎＣ・・・）との間の呼び出し関係を規定する。

図４Ａは、プロシージャ呼出情報１２の一例を示している。例えばプロシージャ呼出情報１２−１は、「サービスＳＡがプロシージャＰ１Ｂを呼び出すこと」、「サービスＳＣがプロシージャＰ１Ａ及びＰ１Ｃを呼び出すこと」などを示している。プロシージャ呼出情報１２−２は、「プロシージャＰ１ＡがプロシージャＰ２Ａ及びＰ２Ｂを呼び出すこと」などを示している。

図４Ｂは、プロシージャ呼出情報１２の他の例を示している。プロシージャ呼出情報１２は、上位プロシージャが下位プロシージャを呼び出す回数を示していてもよい。例えば図４Ｂにおいて、プロシージャ呼出情報１２−２は、「プロシージャＰ１Ａが、プロシージャＰ２Ａを２回呼び出し、プロシージャＰ２Ｂを１回呼び出すこと」などを示している。

再度図１を参照して、ＤＭＬ発行情報２０は、最下位プロシージャ（ＰｎＡ，ＰｎＢ，ＰｎＣ・・・）によって発行されるＤＭＬ文を規定する情報である。例えば、ＤＭＬ発行情報２０は、各エンティティに対して発行されるＤＭＬ文の発行回数を、最下位プロシージャ（ＰｎＡ，ＰｎＢ，ＰｎＣ・・・）毎に示す。ここで、エンティティとは、データベース中のアクセス対象のテーブル（データセット）を意味する。

また、本実施の形態において、ＤＭＬ文は、様々なパラメータに基づいて分類されてもよい。その様々なパラメータとしては、ＤＭＬ文の種類、ＣＰＵ使用時間、エンティティ、データアクセス量、実行計画等が挙げられる。ＤＭＬ文が分類される場合、ＤＭＬ発行情報２０は、発行されるＤＭＬ文の分類を、最下位プロシージャ（ＰｎＡ，ＰｎＢ，ＰｎＣ・・・）毎に示す。例えば、ＤＭＬ発行情報２０は、各エンティティに対して発行されるＤＭＬ文の「種類」を、最下位プロシージャ毎に示す。ＤＭＬ文の種類としては、データ抽出を指示する“ｓｅｌｅｃｔ文”、データ更新を指示する“ｕｐｄａｔｅ文”、データ挿入を指示する“ｉｎｓｅｒｔ文”、データ削除を指示する“ｄｅｌｅｔｅ文”などが挙げられる。

図５は、ＤＭＬ発行情報２０の一例を示している。図５で示される例では、ＤＭＬ文は、種類とエンティティに基づいて分類されている。尚、“Ｃ”は“ｉｎｓｅｒｔ”を、“Ｒ”は“ｓｅｌｅｃｔ”を、“Ｕ”は“ｕｐｄａｔｅ”を、“Ｄ”は“ｄｅｌｅｔｅ”をそれぞれ表し、このような図は一般にＣＲＵＤ図と呼ばれている。このＤＭＬ発行情報２０は、最下位プロシージャ（ＰｎＡ，ＰｎＢ，ＰｎＣ・・・）の各々が、どのエンティティに対してどのような種類のＤＭＬ文を発行するかを示している。例えば、最下位プロシージャＰｎＢは、エンティティＥ１に対してｓｅｌｅｃｔ文を発行し、エンティティＥ３に対してｓｅｌｅｃｔ文及びｕｐｄａｔｅ文を発行する。このようなＤＭＬ発行情報２０に対して、更に各分類のＤＭＬ文の発行回数が付与されていてもよい。

ＤＭＬ負荷情報３０は、ＤＭＬ文あたりの負荷を示す情報である。負荷としては、ＣＰＵ使用時間、ＣＰＵ使用時間を正規化することにより得られるＣＰＵ使用率、ロック競合、容量（テーブル等が使用する記憶領域の大きさ）などが挙げられる。ＤＭＬ文が分類される場合、ＤＭＬ負荷情報３０は、ＤＭＬ文あたりの負荷を、ＤＭＬ文の分類毎に示す。例えば、ＤＭＬ負荷情報３０は、各エンティティに対して発行されるＤＭＬ文あたりの負荷を、ＤＭＬ文の種類毎に示す。

図６は、ＤＭＬ負荷情報３０の一例を示している。図６では、各エンティティ（Ｅ１、Ｅ２、Ｅ３）に対して発行されるＤＭＬ文あたりの負荷が、ＤＭＬ文の種類（ｓｅｌｅｃｔ、ｕｐｄａｔｅ、ｉｎｓｅｒｔ、ｄｅｌｅｔｅ）毎に示されている。負荷は、ＣＰＵ使用率である。例えば、エンティティＥ１に対して発行されるｓｅｌｅｃｔ文のＣＰＵ使用率は１０であり、ｕｐｄａｔｅ文のＣＰＵ使用率は１０３である。同じエンティティに対するＤＭＬ文であっても、ＤＭＬ文の種類に依存して負荷が異なることに留意されたい。

以上に説明された外部呼出回数情報１１、プロシージャ呼出情報１２、ＤＭＬ発行情報２０、及びＤＭＬ負荷情報３０は、設計フェーズにおいて得ることができる設計情報であることに留意されたい。

再度図２を参照して、記憶装置２には更に、階層型負荷推定プログラムＰＲＯＧが格納される。階層型負荷推定プログラムＰＲＯＧは、階層型負荷推定システム１に階層型負荷の算出処理を実行させるコンピュータプログラムである。典型的には、階層型負荷推定プログラムＰＲＯＧは、コンピュータ読み取り可能な記録媒体に記録され、その記録媒体から記憶装置２に読み込まれる。

処理装置３は、階層型負荷推定プログラムＰＲＯＧを実行することにより、階層型負荷の算出処理を行う。具体的には、処理装置３は、呼出回数算出モジュール１００、発行回数算出モジュール２００、及び負荷算出モジュール３００を有している。これら呼出回数算出モジュール１００、発行回数算出モジュール２００、及び負荷算出モジュール３００は、処理装置３が階層型負荷推定プログラムＰＲＯＧを実行することにより実現され、それぞれが所定のデータ処理機能を提供する。以下、呼出回数算出モジュール１００、発行回数算出モジュール２００、及び負荷算出モジュール３００によるデータ処理を詳細に説明する。

３．処理フロー
図７及び図８のそれぞれは、階層型負荷システム１による処理フローを示すブロック図及びフローチャートである。

ステップＳ１００：
呼出回数算出モジュール１００は、記憶装置２から階層呼出情報１０（外部呼出回数情報１１及びプロシージャ呼出情報１２）を読み出す。そして、呼出回数算出モジュール１００は、階層呼出情報１０を参照して、最下位プロシージャ（ＰｎＡ，ＰｎＢ，ＰｎＣ・・・）の呼出回数を算出する。上述の通り、外部呼出回数情報１１は、最上位のサービス（ＳＡ，ＳＢ，ＳＣ・・・）のそれぞれの呼出回数を示しており、プロシージャ呼出情報１２は、上位プロシージャと下位プロシージャとの間の呼び出し関係を規定している。従って、呼出回数算出モジュール１００は、外部呼出回数情報１１及びプロシージャ呼出情報１２を用いることによって、各層のプロシージャの呼出回数を上位層から下位層に向けて順番に算出することができる。結果として、最下位プロシージャ（ＰｎＡ，ＰｎＢ，ＰｎＣ・・・）の呼出回数が算出される。算出された呼出回数は、最下位呼出回数情報１５として記憶装置２に格納される。

ステップＳ２００：
発行回数算出モジュール２００は、記憶装置２から最下位呼出回数情報１５とＤＭＬ発行情報２０を読み出す。上述の通り、最下位プロシージャ（ＰｎＡ，ＰｎＢ，ＰｎＣ・・・）に関して、最下位呼出回数情報１５は呼出回数を示し、ＤＭＬ発行情報２０は発行されるＤＭＬ文を示している。従って、発行回数算出モジュール２００は、最下位呼出回数情報１５とＤＭＬ発行情報２０を参照することにより、最下位プロシージャによって発行されるＤＭＬ文の発行回数を算出することができる。つまり、発行回数算出モジュール２００は、階層処理において発行されるＤＭＬ文の発行回数を算出する。ＤＭＬ文が上述のように分類される場合、ＤＭＬ文の発行回数は分類毎に算出されてもよい。算出されたＤＭＬ文の発行回数は、発行回数情報２５として記憶装置２に格納される。

ステップＳ３００：
負荷算出モジュール３００は、記憶装置２から発行回数情報２５とＤＭＬ負荷情報３０を読み出す。上述の通り、発行回数情報２５はＤＭＬ文の発行回数を示し、ＤＭＬ負荷情報３０はＤＭＬ文あたりの負荷を示している。従って、負荷算出モジュール３００は、発行回数情報２５とＤＭＬ負荷情報３０を参照することにより、最下位プロシージャによって発行されるＤＭＬ文の負荷を算出することができる。つまり、負荷算出モジュール３００は、階層処理において発行されるＤＭＬ文の負荷を算出する。ＤＭＬ文が上述のように分類される場合、ＤＭＬ文の負荷は分類毎に算出されてもよい。算出されたＤＭＬ文の負荷は、推定負荷情報ＲＥＳとして記憶装置２に格納される。算出されたＤＭＬ文の負荷は、多層システムのデータベース層にかかる負荷の推定値（推定負荷）を表している。つまり、推定負荷情報ＲＥＳは、データベース層にかかる階層型負荷の推定値を示している。システム構築者は、推定負荷情報ＲＥＳを参照することによって、十分なシステム性能を達成するために必要な計算機資源を見積もることができる。

以下、ステップＳ１００とステップＳ２００を、更に詳しく説明する。

３−１．ステップＳ１００
ステップＳ１００において、呼出回数算出モジュール１００は、階層呼出情報１０から最下位呼出回数情報１５を作成する。図９は、ステップＳ１００を示すフローチャートである。

まず、ループ処理に用いられるカウンタｉが１に設定される（ステップＳ１１０）。このループ処理は、プロシージャ呼出情報１２−１〜１２−ｎの数だけ実施される。つまり、カウンタｉは初期値１から最終値ｎまで１ずつ変化する。

各ループ処理において、記憶装置２からプロシージャ呼出情報１２−ｉが読み込まれる（ステップＳ１２０）。また、上位呼出回数情報が読み込まれる（ステップＳ１３０）。ここで、「上位呼出回数情報」とは、プロシージャ呼出情報１２−ｉ中の上位プロシージャのそれぞれの呼出回数を示す情報である。次に、その上位プロシージャの呼出回数とプロシージャ呼出情報１２−ｉに基づいて、プロシージャ呼出情報１２−ｉ中の下位プロシージャのそれぞれの呼出回数が算出される（ステップＳ１４０）。下位プロシージャのそれぞれの呼出回数を示す情報が、「下位呼出回数情報」である。カウンタｉが最終値ｎに満たない場合（ステップＳ１６０；Ｎｏ）、カウンタｉに１が加算され（ステップＳ１７０）、次のループ処理が実施される。

具体的には、最初カウンタｉは１であるため、プロシージャ呼出情報１２−１が参照される。このとき、上位プロシージャはサービス（ＳＡ，ＳＢ，ＳＣ・・・）であり、上位呼出回数情報は外部呼出回数情報１１（図３参照）である。従って、記憶装置２から外部呼出回数情報１１が読み出される。外部呼出回数情報１１は、サービス（ＳＡ，ＳＢ，ＳＣ・・・）のそれぞれの呼出回数を示しており、プロシージャ呼出情報１２−１はそれらサービスとプロシージャ（Ｐ１Ａ，Ｐ１Ｂ，Ｐ１Ｃ・・・）との間の呼び出し関係を規定している。従って、外部呼出回数情報１１とプロシージャ呼出情報１２−１から、下位プロシージャ（Ｐ１Ａ，Ｐ１Ｂ，Ｐ１Ｃ・・・）のそれぞれの呼出回数を示す下位呼出回数情報を作成することができる。

次に、カウンタｉは２となり、プロシージャ呼出情報１２−２が参照される。このとき、上位プロシージャはプロシージャ（Ｐ１Ａ，Ｐ１Ｂ，Ｐ１Ｃ・・・）である。従って、前回のループ処理で作成された下位呼出回数情報が、今回のループ処理における上位呼出回数情報として利用される。そして、プロシージャ呼出情報１２−２と上位呼出回数情報に基づいて、下位プロシージャ（Ｐ２Ａ，Ｐ２Ｂ，Ｐ２Ｃ・・・）のそれぞれの呼出回数が算出される。

カウンタｉが最終値ｎに達するまで、同様のループ処理が繰り返される。最終的には、最下位プロシージャ（ＰｎＡ，ＰｎＢ，ＰｎＣ・・・）のそれぞれの呼出回数が算出される。カウンタｉが最終値ｎの場合（ステップＳ１６０；Ｙｅｓ）、ループ処理は終了する。最終的に得られた最下位プロシージャの呼出回数を示す情報が、最下位呼出回数情報１５である（ステップＳ１８０）。このように、本実施の形態によれば、各層のプロシージャの呼出回数が、上位層から下位層に向けて順番に算出される。結果として、最下位プロシージャの呼出回数が算出され、最下位呼出回数情報１５が作成される。

上記ステップＳ１４０において下位プロシージャの呼出回数を算出する方法としては、様々な方法が考えられる。図１０は、その一例を示すフローチャートである。まず、下位エントリが作成される（ステップＳ１４１）。下位エントリとは、下位プロシージャの識別子と呼出回数のフィールドからなるテーブルである。下位エントリの各フィールド値を算出することがステップＳ１４０の目的である。各フィールドの初期値は全て０に設定される。

次に、上位プロシージャのリストを示す上位リストが作成される（ステップＳ１４２）。続いて、上位リストから任意の１つの上位プロシージャが選択される（ステップＳ１４３）。次に、選択上位プロシージャによって呼び出される下位プロシージャのそれぞれの呼出回数が算出される（ステップＳ１５０）。算出された下位プロシージャの呼出回数は、下位エントリ中の対応するフィールド値に加算される。その後、選択上位プロシージャが上位リストから削除される（ステップＳ１４４）。上位リストに他の上位プロシージャが残っていれば（ステップＳ１４５；Ｙｅｓ）、処理はステップＳ１４３に戻る。上位プロシージャが残っていなければ（ステップＳ１４５；Ｎｏ）、ステップＳ１４０は終了する。

ステップＳ１５０は、次の通りである。まず、選択上位プロシージャによって呼び出される下位プロシージャのリストを示す下位リストが作成される（ステップＳ１５１）。続いて、下位リストから任意の１つの下位プロシージャが選択される（ステップＳ１５２）。次に、選択下位プロシージャの呼出回数が算出される。このとき、選択上位プロシージャの総呼出回数は上位呼出回数情報によって与えられている。よって、プロシージャ呼出情報１２−ｉが上位プロシージャによって呼び出される下位プロシージャの種類を示している場合（図４Ａ参照）、選択上位プロシージャの総呼出回数が選択下位プロシージャの呼出回数となる。また、プロシージャ呼出情報１２−ｉが１回の選択上位プロシージャによって呼び出される選択下位プロシージャの回数を示している場合（図４Ｂ参照）、その回数に選択上位プロシージャの総呼出回数を掛けることによって、選択下位プロシージャの呼出回数が算出される。算出された選択下位プロシージャの呼出回数は、下位エントリ中の対応するフィールド値に加算され、下位エントリが更新される（ステップＳ１５３）。その後、選択下位プロシージャが下位リストから削除される（ステップＳ１５４）。下位リストに他の下位プロシージャが残っていれば（ステップＳ１５５；Ｙｅｓ）、処理はステップＳ１５２に戻る。下位プロシージャが残っていなければ（ステップＳ１５５；Ｎｏ）、ステップＳ１５０は終了する。

３−２．ステップＳ２００
ステップＳ２００において、発行回数算出モジュール２００は、最下位呼出回数情報１５及びＤＭＬ発行情報２０から発行回数情報２５を算出する。図１１は、ステップＳ２００を示すフローチャートである。まず、最下位呼出回数情報１５が記憶装置２から読み込まれる（ステップＳ２１０）。また、ＤＭＬ発行情報２０が記憶装置２から読み込まれる（ステップＳ２２０）。

次に、エンティティエントリが作成される（ステップＳ２３０）。エンティティエントリとは、ＤＭＬ発行情報２０で示されるエンティティの識別子とＤＭＬ文の発行回数のフィールドからなるテーブルである。上述のようにＤＭＬ文が分類される場合、発行回数のフィールドは、ＤＭＬ文の分類毎に設けられる。このエンティティエントリの各フィールド値を算出することがステップＳ２００の目的である。各フィールドの初期値は全て０に設定される。

次に、最下位リストが作成される（ステップＳ２４０）。最下位リストは、最下位呼出回数情報１５で示される最下位プロシージャ（ＰｎＡ，ＰｎＢ，ＰｎＣ・・・）のリストである。続いて、最下位リストから任意の１つの最下位プロシージャが選択される（ステップＳ２５０）。

次に、選択された最下位プロシージャによって発行されるＤＭＬ文の発行回数が算出される。上述の通り、最下位呼出回数情報１５は、各最下位プロシージャの総呼出回数を示しており、ＤＭＬ発行情報２０は、各最下位プロシージャによって発行されるＤＭＬ文を規定している。ＤＭＬ発行情報２０が、１回の最下位プロシージャによるＤＭＬ文の発行回数を示している場合を考える。この場合、その発行回数に選択最下位プロシージャの総呼出回数を掛けることによって、選択最下位プロシージャによるＤＭＬ文の発行回数の合計が算出される。ＤＭＬ文が分類されている場合には、その分類毎に、ＤＭＬ文の発行回数が同様に算出される。このようにして算出されたＤＭＬ文の発行回数は、エンティティエントリ中の対応するフィールド値に加算され、エンティティエントリが更新される（ステップＳ２６０）。

その後、選択最下位プロシージャが最下位リストから削除される（ステップＳ２７０）。最下位リストに他の最下位プロシージャが残っていれば（ステップＳ２８０；Ｙｅｓ）、処理はステップＳ２５０に戻る。最下位プロシージャが残っていなければ（ステップＳ２８０；Ｎｏ）、ＤＭＬ文の発行回数の算出処理は終了する。最終的なエンティティエントリが、発行回数情報２５に相当する。つまり、階層処理において発行されるＤＭＬ文の発行回数を示す発行回数情報２５が決定される（ステップＳ２９０）。

４．処理例
次に、本実施の形態に係る階層型負荷推定システム１による具体的な処理例を説明する。

４−１．第１の処理例
図１２は、第１の処理例における外部呼出回数情報１１を示している。外部呼出回数情報１１は、３種類のサービスＳＡ、ＳＢ、ＳＣのそれぞれの呼出回数を示している。ここで、各呼出回数は、１秒あたりに想定されるサービス要求回数である。尚、単位時間は、１秒に限られず、任意の値に設定され得る。

図１３は、第１の処理例におけるプロシージャ呼出情報１２を示している。簡単のため、パラメータｎは１であるとする。つまり、最下位プロシージャは、サービスＳＡ〜ＳＣによって呼び出されるプロシージャＰ１Ａ〜Ｐ１Ｄであるとする。パラメータｎが２以上であっても、同様の議論が適用される。図１３に示されるように、プロシージャ呼出情報１２−１は、サービスＳＡ〜ＳＣとプロシージャＰ１Ａ〜Ｐ１Ｄとの間の呼び出し関係を示している。具体的には、サービスＳＡはプロシージャＰ１Ａ、Ｐ１Ｂを呼び出し、サービスＳＢはプロシージャＰ１Ｂ、Ｐ１Ｃを呼び出し、サービスＳＣはプロシージャＰ１Ｃ、Ｐ１Ｄを呼び出す。

図１４は、第１の処理例におけるＤＭＬ発行情報２０を示している。第１の処理例では、簡単のため、データベース層が１つのエンティティとして扱われる。図１４に示されるように、ＤＭＬ発行情報２０は、そのエンティティに対するＤＭＬ文の発行回数を、最下位プロシージャＰ１Ａ〜Ｐ１Ｄ毎に示している。具体的には、最下位プロシージャＰ１Ａ〜Ｐ１Ｄの各々は、１回の呼び出しあたり２つのＤＭＬ文を発行する。

図１５は、第１の処理例におけるＤＭＬ負荷情報３０を示している。ＤＭＬ負荷情報３０は、ＤＭＬ発行情報２０の形式に適合するように作成されている。つまり、データベース層が１つのエンティティとして扱われる。図１５に示されるように、ＤＭＬ負荷情報３０は、そのエンティティに対する１つのＤＭＬ文あたりの負荷を示している。ここで、負荷は、平均実行時間である。図１５で示される例では、全てのＤＭＬ文の平均実行時間は６ｍｓである。

ステップＳ１００において、図１２で示された外部呼出情報１１と図１３で示されたプロシージャ呼出情報１２に基づいて、最下位プロシージャＰ１Ａ〜Ｐ１Ｄのそれぞれの呼出回数が算出される。ステップＳ１４０（図１０参照）で使用される下位エントリ、上位リスト、及び下位リストは、プロシージャ呼出情報１２から容易に作成される。すなわち、下位エントリは、最下位プロシージャＰ１Ａ〜Ｐ１Ｄのそれぞれの呼出回数のフィールドを有する。上位リストは、サービスＳＡ、ＳＢ、ＳＣを含む。サービスＳＡに対応する下位リストは、最下位プロシージャＰ１Ａ、Ｐ１Ｂを含む。サービスＳＢに対応する下位リストは、最下位プロシージャＰ１Ｂ、Ｐ１Ｃを含む。サービスＳＣに対応する下位リストは、最下位プロシージャＰ１Ｃ、Ｐ１Ｄを含む。ステップＳ１００の結果、図１６に示される最下位呼出回数情報１５が得られる。最下位プロシージャＰ１Ａ、Ｐ１Ｂ、Ｐ１Ｃ、Ｐ１Ｄのそれぞれの呼出回数は、それぞれ、３、１３、３５、２５である。

ステップＳ２００において、図１６で示された最下位呼出回数情報１５と図１４で示されたＤＭＬ発行情報２０に基づいて、ＤＭＬ文の発行回数の合計が算出される。エンティティエントリは、ＤＭＬ発行情報２０から容易に作成される。第１の例では、データベース層が１つのエンティティとして扱われるため、エンティティエントリに含まれるエンティティの識別子も１つだけである。ステップＳ２００の結果、図１７に示される発行回数情報２５が得られる。最下位プロシージャＰ１Ａ〜Ｐ１Ｄの各々は、１回の呼び出しあたり２つのＤＭＬ文を発行するため、ＤＭＬ文の発行回数の合計は１５２回である。

ステップＳ３００において、図１７で示された発行回数情報２５と図１５で示されたＤＭＬ負荷情報３０に基づいて、ＤＭＬ文の負荷が算出される。ＤＭＬ文の発行回数は合計１５２回であり、ＤＭＬ文あたりの平均実行時間は６ｍｓであるため、ＤＭＬ文の総実行時間は９１２ｍｓ（＝１５２×６ｍｓ）と算出される。ここで、これらＤＭＬ文の発行は、１秒あたりに想定されるサービス要求（図１２参照）の結果であることに留意されたい。つまり、１秒あたり９１２ｍｓの期間が、サービス要求の結果としてのＤＭＬ文の実行に費やされる。言い換えれば、ＣＰＵ使用率は９１．２％である。このＣＰＵ使用率＝９１．２％が、本例によって推定される負荷である。図１８は、本例において作成される推定負荷情報ＲＥＳを示している。

尚、ＤＭＬ文の発行回数（＝１５２回）も負荷に関連するパラメータである。よって、推定負荷情報ＲＥＳには、ステップＳ３００で算出される負荷だけでなく、ステップＳ２００で算出されるＤＭＬ文の発行回数が含まれていてもよい。あるいは、推定負荷情報ＲＥＳとして、ステップＳ２００で算出されるＤＭＬ文の発行回数だけが与えられてもよい。

推定されたＣＰＵ使用率（９１．２％）を利用して、システム構築者は、十分なシステム性能を達成するために必要な計算機資源を、設計フェーズにおいても見積もることができる。例えば、ＣＰＵ使用率が９２％以下であれば運用上問題ない場合、ＣＰＵは１つで十分であることが推定される。ＣＰＵ使用率を５０％以下に保つ必要がある場合、システム構築者は、ＣＰＵ数を２つに増やすことを検討することができる。あるいは、システム構築者は、ＤＭＬ文とデータ構造の最適化をより高いレベルで実現する必要があることを推定できる。あるいは、システム構築者は、提供するサービスの量を抑制することを検討することができる。

また、複数種類の外部呼出回数情報１１に対して、つまり、異なるサービス提供シナリオに対して、それぞれ負荷を推定することもできる。この場合、一部または全てのサービス提供シナリオを採用するのに十分な計算機資源の量を推定することができる。または、想定される計算機資源の範囲内で適用可能なサービス提供シナリオとそれ以外を選別することができる。このように、本実施の形態は、設計フェーズにおけるサービス提供シナリオの策定を支援することができる。

本実施の形態に係る負荷推定は、新規にシステムを構築する場合だけでなく、既存システムが変更される場合にも実施され得る。例えば、既存システムのＤＭＬ発行情報２０とプロシージャ呼出情報１２に変更が反映された後、負荷が推定される。また、サービス提供シナリオが変更される場合、外部呼出回数情報１１に変更が反映された後、負荷が推定される。また、システムを構成するハードウェアが変更される場合（例えば、ＣＰＵが置き換えられる場合）、ＤＭＬ負荷情報３０にハードウェアスペックの変更が反映された後、負荷が推定される。

４−２．第２の処理例
第２の処理例において、外部呼出回数情報１１とプロシージャ呼出情報１２は第１の処理例と同じである。従って、ステップＳ１００の結果は第１の処理例と同じであり、最下位呼出回数情報１５は、既出の図１６で示されたようになる。

図１９は、第２の処理例におけるＤＭＬ発行情報２０を示している。第２の処理例では、ＤＭＬ文は分類され、ＤＭＬ発行情報２０は、発行されるＤＭＬ文の分類を最下位プロシージャＰ１Ａ〜Ｐ１Ｄ毎に示している。より詳細には、ＤＭＬ文は、「ＤＭＬ文の種類」と「エンティティ」に基づいて分類される。ここでは、４つのエンティティＥ１〜Ｅ４と、４つの種類“Ｃ（ｉｎｓｅｒｔ）”、“Ｒ（ｓｅｌｅｃｔ）”、“Ｕ（ｕｐｄａｔｅ）”、“Ｄ（ｄｅｌｅｔｅ）”が考慮される。最下位プロシージャＰ１Ａ〜Ｐ１Ｄの各々は、エンティティＥ１〜Ｅ４の少なくともいずれかに対して、いずれかの種類のＤＭＬ文を発行する。図１９に示されるように、ＤＭＬ発行情報２０は、最下位プロシージャＰ１Ａ〜Ｐ１Ｄのそれぞれによって発行されるＤＭＬ文のエンティティと種類を示している。例えば、１回の最下位プロシージャＰ１Ａは、エンティティＥ１に対してｓｅｌｅｃｔ文を発行し、また、エンティティＥ４に対してｄｅｌｅｔｅ文を発行する。

図２０は、第２の処理例におけるＤＭＬ負荷情報３０を示している。ＤＭＬ負荷情報３０は、ＤＭＬ発行情報２０の形式に適合するように作成されている。つまり、ＤＭＬ負荷情報３０は、ＤＭＬ文あたりの負荷を、ＤＭＬ文の分類毎に示している。第１の処理例と同様に、負荷は平均実行時間である。例えば、エンティティＥ１に対するｓｅｌｅｃｔ文の平均実行時間は２ｍｓであり、エンティティＥ３に対するｕｐｄａｔｅ文の平均実行時間は１４ｍｓである。尚、空白のフィールドが残されているのは、発行されないＤＭＬ文の実行時間は不要であるためである。

ステップＳ２００において、図１６で示された最下位呼出回数情報１５と図１９で示されたＤＭＬ発行情報２０に基づいて、ＤＭＬ文の発行回数が算出される。このとき、ＤＭＬ文の発行回数は、上記ＤＭＬ文の分類毎に算出される。従って、エンティティエントリ（発行回数情報２５）は、ＤＭＬ文の発行回数を分類毎に示すテーブルとなる。そのようなテーブル形式は、ＤＭＬ負荷情報３０において負荷（実行時間）が発行回数で置き換えられたものと同じである。ステップＳ２００の結果、図２１に示される発行回数情報２５が得られる。例えば、エンティティＥ１に対してｓｅｌｅｃｔ文が合計２８回発行され、エンティティＥ３に対してｕｐｄａｔｅ文が合計３５回発行される。

ステップＳ３００において、図２１で示された発行回数情報２５と図２０で示されたＤＭＬ負荷情報３０に基づいて、ＤＭＬ文の負荷が算出される。このとき、ＤＭＬ文の負荷は、上記ＤＭＬ文の分類毎に算出される。ステップＳ３００の結果、図２２に示される推定負荷情報ＲＥＳが得られる。図２２に示される推定負荷情報ＲＥＳは、１秒あたりのＤＭＬ文の実行時間［ｍｓ］、すなわち、１秒あたりのＣＰＵ使用時間［ｍｓ］を、ＤＭＬ文の分類毎に示している。尚、１秒あたりのＣＰＵ使用時間［ｍｓ］を１０で割れば、ＣＰＵ使用率［％］が得られる。また、図２２で示される推定負荷情報ＲＥＳには、「ｔｏｔａｌ行」と「ｔｏｔａｌ列」が付加されている。ｔｏｔａｌ行には種類毎のＣＰＵ使用時間の部分和が示されている。一方、ｔｏｔａｌ列にはエンティティ毎のＣＰＵ使用時間の部分和が示されている。ｔｏｔａｌ行とｔｏｔａｌ列の双方に属するフィールドには、全ＤＭＬ文のＣＰＵ使用時間の総和（８５１ｍｓ）が示されている。

推定負荷情報ＲＥＳには、ステップＳ２００で算出されたＤＭＬ文の分類毎の発行回数が含まれていてもよい。第２の処理例で作成された推定負荷情報ＲＥＳは、第１の処理例と同様に利用できる。更に、ＤＭＬ文の負荷や発行回数が分類毎に算出されているため、次のような利用方法も可能である。

分類毎に算出された負荷は、設計段階において特に注意を払うべきＤＭＬ文の特定に有効である。例えば、図２２で示された推定負荷情報ＲＥＳから、エンティティＥ３に対するｕｐｄａｔｅ文の負荷（４９０ｍｓ）が総負荷（８５１ｍｓ）の半分以上を占めていることがわかる。そのため、システム構築者は、性能を向上させるためにはエンティティＥ３に対するｕｐｄａｔｅ文を最適化することが効率的であると判断することができる。

また、エンティティ毎の負荷の部分和は、設計段階において特に注意を払うべきエンティティの特定に有効である。例えば、図２２で示された推定負荷情報ＲＥＳから、エンティティＥ３に関する負荷（５６０ｍｓ）が総負荷（８５１ｍｓ）の半分以上を占めていることが分かる。そのため、システム構築者は、性能を向上させるためにはエンティティＥ３の設計を最適化することが効率的であると判断することができる。一方、エンティティＥ２に関する負荷の総負荷への寄与は小さいため、システム構築者は、エンティティＥ２の設計を最適化することによるメリットは小さいと判断できる。

また、ＤＭＬ文の種類及びエンティティ毎に算出された発行回数を分析することにより、ロック競合の可能性を定量的に推定できる。基本的に、異なるエンティティにアクセスするＤＭＬ文は、同じデータにアクセスすることはない。一方で、同一のエンティティにアクセスするＤＭＬ文は同じデータにアクセスするため、その場合、ロック競合が発生する可能性がある。ロック競合はＤＭＬ文のＣＰＵ使用時間を増加させるとともに遅延を増大させるため、設計フェーズの段階から考慮すべき問題である。例えば既出の図２１で示される例の場合、エンティティＥ１、Ｅ２に対しては、ｓｅｌｅｃｔ文によるデータ読み出しのみが発生する。従って、それらエンティティＥ１、Ｅ２に関するロック競合が起きる可能性は極めて低いと考えられる。一方、エンティティＥ４に対しては、ｉｎｓｅｒｔ文とｄｅｌｅｔｅ文によるデータ書き込みも発生するため、ロック競合が起きる可能性がある。更に、エンティティＥ３に関しては、多数のｕｐｄａｔｅ文によるデータ書き込みと多数のｓｅｌｅｃｔ文によるデータ読み出しが発生するため、ロック競合が起きる可能性はエンティティＥ４よりも更に高くなると考えられる。このように、設計フェーズからロック競合の可能性を定量的に評価することにより、エンティティの分割等の対応を検討することが可能となる。

また、算出された発行回数をＤＭＬ文の種類別に分析することは、設計フェーズにおけるデータベースの容量設計に有効である。例えば図２１で示される発行回数情報２５から、エンティティＥ４に対しては１秒間に、ｉｎｓｅｒｔ文が１３回、ｄｅｌｅｔｅ文が３回発行されることが分かる。ｉｎｓｅｒｔ文が１行挿入を実施し、ｄｅｌｅｔｅ文が１行削除を実施するとすれば、エンティティＥ４の全行数は１秒毎に１０行ずつ増えると推定される。１行が６４バイトの場合、エンティティＥ４が必要とする記憶容量は、１秒毎に６４０バイト、１日に５Ｍバイト以上増えると推定される。このような定量的な推定は、データベースの容量設計に際して有効である。

また、ＤＭＬ文が分類される場合、複数の異なる外部呼出回数情報１１に対する負荷推定の精度を高めることができる。分類別にＤＭＬ文の実行時間が異なる場合、ＤＭＬ文の比率が異なればＤＭＬ文の平均実行時間も異なる。比率別に平均実行時間を求めるのは一般に困難なので、異なるＤＭＬ文の比率、つまり異なる外部呼出回数情報１１に対する負荷推定精度は低くなってしまう。よって、分類別の平均実行時間を使えば、負荷推定精度を高めることができる。

５．効果
本発明の実施の形態によれば、少なくとも次の効果が得られる。つまり、想定されるサービス要求に対して、階層処理において発行されるＤＭＬ文の数が定量的に算出される。ＤＭＬ文の発行回数はデータベース層にかかる負荷に関連しているため、算出されたＤＭＬ文の発行回数に基づいて、データベース層にかかる負荷を見積もることができる。つまり、多層システムにおける階層型負荷を定量的に推定することができる。

その階層型負荷の推定において、実際にシステムを構築することは不要である。たとえ設計フェーズの段階であっても、階層型負荷を定量的に推定することが可能となる。システム構築者は、推定された階層型負荷を参照することによって、十分なシステム性能を達成するために必要な計算機資源を見積もることができる。つまり、設計フェーズにおいて、想定されるサービス要求に対する階層型負荷を定量的に推定し、必要な計算機資源を見積もることができる。その結果、運用フェーズから設計フェーズへの戻りが防止され、システム構築コストが削減される。

以上、本発明の実施の形態が添付の図面を参照することにより説明された。但し、本発明は、上述の実施の形態に限定されず、要旨を逸脱しない範囲で当業者により適宜変更され得る。

本出願は、２００７年１０月３日に出願された日本国特許出願２００７−２５９９４７を基礎とする優先権を主張し、その開示の全てをここに取り込む。

Claims (8)

1. 多層システムにおいて階層的に呼び出される階層処理の設計を示す階層呼出情報と、前記階層処理のうちデータベース操作処理によって発行されるデータベース操作文を規定する発行情報と、データベース操作文あたりの負荷を示す負荷情報とが格納される記憶装置と、
   前記階層呼出情報を参照して、前記データベース操作処理の呼出回数を算出する呼出回数算出モジュールと、
   前記算出された呼出回数と前記発行情報を参照して、前記データベース操作処理によって発行されるデータベース操作文の発行回数を算出する発行回数算出モジュールと、
   前記算出された発行回数と前記負荷情報を参照して、前記データベース操作処理によって発行されるデータベース操作文の負荷を算出する負荷算出モジュールと
   を備える
   階層型負荷推定システム。
2. 請求項１に記載の階層型負荷推定システムであって、
   前記発行情報は、データベース操作文の発行回数を前記データベース操作処理毎に示し、
   前記発行回数算出モジュールは、前記データベース操作処理によって発行されるデータベース操作文の発行回数の合計を算出し、
   前記負荷算出モジュールは、前記データベース操作処理によって発行されるデータベース操作文の負荷の合計を算出する
   階層型負荷推定システム。
3. 請求項１に記載の階層型負荷推定システムであって、
   前記発行情報は、データベース操作文の分類を前記データベース操作処理毎に示し、
   前記発行回数算出モジュールは、前記発行回数を前記分類毎に算出し、
   前記負荷情報は、データベース操作文あたりの負荷を前記分類毎に示し、
   前記負荷算出モジュールは、前記負荷を前記分類毎に算出する
   階層型負荷推定システム。
4. 請求項１に記載の階層型負荷推定システムであって、
   前記発行情報は、データベース操作文の分類を前記データベース操作処理及びエンティティ毎に示し、
   前記発行回数算出モジュールは、前記発行回数を前記分類及び前記エンティティ毎に算出し、
   前記負荷情報は、データベース操作文あたりの負荷を前記分類及び前記エンティティ毎に示し、
   前記負荷算出モジュールは、前記負荷を前記分類及び前記エンティティ毎に算出する
   階層型負荷推定システム。
5. 請求項２乃至４のいずれか一項に記載の階層型負荷推定システムであって、
   前記多層システムは、データベース層を含み、前記負荷算出モジュールは、前記負荷を前記データベース層にかかる負荷として算出する
   階層型負荷推定システム。
6. 請求項１乃至５のいずれか一項に記載の階層型負荷推定システムであって、
   前記階層呼出情報は、
   前記階層処理のうち外部から要求される最上位処理の呼出回数を示す第１情報と、
   前記階層処理における上位処理と下位処理との間の呼び出し関係を規定する第２情報と
   を含み、
   前記呼出回数算出モジュールは、前記第１情報と前記第２情報を用い、各層の処理の呼出回数を上位層から下位層に向けて順番に算出することによって、前記データベース操作処理の呼出回数を算出する
   階層型負荷推定システム。
7. コンピュータが実行する階層型負荷推定方法であって、
   多層システムにおいて階層的に呼び出される階層処理の設計を示す階層呼出情報を記憶装置から読み出すことと、
   前記階層処理のうちデータベース操作処理によって発行されるデータベース操作文を規定する発行情報を前記記憶装置から読み出すことと、
   データベース操作文あたりの負荷を示す負荷情報を前記記憶装置から読み出すことと、
   前記階層呼出情報を参照して、前記データベース操作処理の呼出回数を算出することと、
   前記算出された呼出回数と前記発行情報を参照して、前記データベース操作処理によって発行されるデータベース操作文の発行回数を算出することと、
   前記算出された発行回数と前記負荷情報を参照して、前記データベース操作処理によって発行されるデータベース操作文の負荷を算出することと
   を含む
   階層型負荷推定方法。
8. コンピュータ読み取り可能な記録媒体に記録された階層型負荷推定プログラムであって、
   多層システムにおいて階層的に呼び出される階層処理の設計を示す階層呼出情報を記憶装置から読み出すことと、
   前記階層処理のうちデータベース操作処理によって発行されるデータベース操作文を規定する発行情報を前記記憶装置から読み出すことと、
   データベース操作文あたりの負荷を示す負荷情報を前記記憶装置から読み出すことと、
   前記階層呼出情報を参照して、前記データベース操作処理の呼出回数を算出することと、
   前記算出された呼出回数と前記発行情報を参照して、前記データベース操作処理によって発行されるデータベース操作文の発行回数を算出することと、
   前記算出された発行回数と前記負荷情報を参照して、前記データベース操作処理によって発行されるデータベース操作文の負荷を算出することと
   をコンピュータに実行させる
   階層型負荷推定プログラム。

Images