JP5865820B2 - 情報処理装置、プログラム、およびジョブ制御方法 - Google Patents

Description

本発明は、サーバのジョブの実行を制御する情報処理装置、プログラム、およびジョブ制御方法に関する。

複数のコンピュータが階層的に処理を分担するコンピュータシステム（以下、「多階層システム」と呼ぶ）がある。多階層システムとして、例えばシステム利用のためのインタフェースを提供するＷｅｂサーバ、システム上の処理を実行するＡｐｐ（Application）サーバおよびデータを管理するＤＢ（Database）サーバを有する３階層システムが知られている。各サーバは、ユーザからの処理要求に対して連携して処理を実行し、その処理要求に応答する。このように、各サーバに処理を分担させることで、システムの信頼性や応答性を向上できる。

また多階層システムに属する各サーバの処理効率を向上させることでも、システムの応答性を向上させることができる。例えば、限られたデータベース資源の中で、より多くのユーザからの利用を効率的に行うことを可能とするデータベースサーバシステムが考えられている。

特開２００１−２２９０５８号公報

多階層システムでは、負荷が増大すると、システム内の特定の階層のサーバの処理能力が限界（飽和状態）に近づく。サーバの処理能力が限界に近づいたかどうかは、例えば、そのサーバで実行されている処理の応答時間を観測することで判断できる。サーバで実行された処理の単位時間当たりの平均応答時間が極端に長期化している期間は、そのサーバの処理能力の限界に達したものと推定できる。以下、処理の平均応答時間を計算する時間間隔の長さを、時間粒度と呼ぶこととする。処理の平均応答時間を計算する時間間隔が短いほど、時間粒度が細かいと称する。

なお、粗い時間粒度で平均応答時間を計算すると処理の限界に達していない場合でも、より細かな時間粒度で平均応答時間を計算すると、部分的に処理能力の限界に達していることがある。例えば、１秒ごとの平均値で観測するとＣＰＵ（Central Processing Unit）使用率が８０％の場合でも、０．１秒ごとの平均値で観測してみると１００％に達している区間が存在するということがある。

しかし、粗い時間粒度では観測できないが、細かい時間粒度では観測できるような飽和状態が、多階層システムの下位の方の階層のサーバで発生すると、その影響で、システム全体の単位時間当たりの平均応答時間が激しく乱高下することが判明した。平均応答時間が激しく乱高下すると、応答時間が長期化した処理の処理要求を行ったエンドユーザは、システムの処理の遅延を体感することとなる。一部のユーザであっても、処理の遅延を体感させてしまうことは、よいことではない。

１つの側面では、本発明は応答時間の乱高下を抑止させる情報処理装置、プログラム、およびジョブ制御方法を提供することを目的とする。

１つの案では、計数手段と抑止手段とを有する情報処理装置が提供される。計数手段は、サーバ４に実行させるジョブが複数のグループに分類され、属するジョブによるサーバへの負荷が軽いほど上位となるように、グループが順位付けされており、サーバ４で実行中のジョブのうち、上位から所定数のグループに属するジョブの数を計数する。抑止手段は、計数したジョブの数が予め定められた閾値以上であり、上位から所定数のグループに属する処理待ちのジョブがある場合、上位から所定数のグループ以外のグループに属するジョブの処理要求を抑止対象として、該抑止対象の処理要求のサーバへの送信を抑止する。

１態様によれば、応答時間の乱高下を抑止させることができる。

第１の実施の形態に係る装置の機能構成例を示す図である。 応答時間が乱高下する原因の一例を示すシーケンス図である。 ジョブの優先度制御を行わない場合の平均応答時間の変化の一例を示す図である。 第１の参考技術を示す図である。 第２の参考技術を示す図である。 第３の参考技術を示す図である。 第２の実施の形態のシステムの全体構成を示す図である。 第２の実施の形態に用いるＡｐｐサーバのハードウェアの一構成例を示す図である。 Ａｐｐサーバの機能の一例を示すブロック図である。 パラメータ記憶部のデータ構造の一例を示す図である。 コネクションの割り当て状況の一例を示す図である。 第２の実施の形態に係るＡｐｐサーバの処理の概要を示す図である。 ジョブの優先度制御の一例を示す図である。 ジョブの実行順の違いによる平均応答時間の変化の一例を示す図である。 状態設定処理の手順の一例を示すフローチャートである。 重いジョブ数制御処理の手順の一例を示すフローチャートの前半である。 重いジョブ数制御処理の手順の一例を示すフローチャートの後半である。 軽いジョブ数制御処理の手順の一例を示すフローチャートの前半である。 軽いジョブ数制御処理の手順の一例を示すフローチャートの後半である。 ジョブの優先度制御を行った場合の応答時間の変化の一例を示す図である。 第３の実施の形態のシステムの全体構成の一例を示す図である。 第３の実施の形態におけるＡｐｐサーバの機能の一例を示す図である。 第３の実施の形態のパラメータ記憶部のデータ構造の一例を示す図である。 第３の実施の形態における重いジョブ数制御処理の手順の一例を示すフローチャートの後半である。 優先度制御ＯＮ／ＯＦＦ切り替え処理の手順の一例を示すフローチャートである。 第４の実施の形態におけるＡｐｐサーバの機能の一例を示す図である。 第４の実施の形態のパラメータ記憶部のデータ構造の一例を示す図である。 第４の実施の形態のジョブ数制御処理の手順の一例を示すフローチャートの前半である。 第４の実施の形態のジョブ数制御処理の手順の一例を示すフローチャートの後半である。

以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第１の実施の形態〕
まず、第１の実施の形態について説明する。第１の実施の形態は、あるサーバが、細かい時間粒度で観測可能な飽和状態となっても、その影響で、システム全体の単位時間当たりの平均応答時間が乱高下することを抑止するものである。

図１は、第１の実施の形態に係る装置の機能構成例を示す図である。情報処理装置１は、多階層システムの一部を構成している。図１の例では、情報処理装置１は、サーバ２の下位の階層であり、サーバ４の上位の階層である。すなわち情報処理装置１は、サーバ２からのジョブの処理要求をコネクション３を介して受信し、受信した処理要求に応じてジョブを実行する。また情報処理装置１は、ジョブの実行の過程で、コネクション５を介して、サーバ４に対してジョブの処理要求を送信する。

情報処理装置１は、複数の実行手段１ａ−１，１ａ−２，１ａ−３，１ａ−４、決定手段１ｂ、重いジョブの待ち行列１ｃ、軽いジョブの待ち行列１ｄ、算出手段１ｅ、計数手段１ｆ、および抑止手段１ｇを有する。

実行手段１ａ−１，１ａ−２，１ａ−３，１ａ−４は、サーバ２からのジョブの処理要求に応じて、処理要求で示されるジョブを実行する。実行手段１ａ−１，１ａ−２，１ａ−３，１ａ−４は、ジョブの実行過程において、サーバ４で実行させるジョブを生成し、そのジョブの処理要求を出力する。

なお実行手段１ａ−１，１ａ−２，１ａ−３，１ａ−４が生成するジョブは、複数のグループに分類されている。図１の例では実行手段１ａ−１，１ａ−２が生成するジョブで１つのグループが形成され、実行手段１ａ−３，１ａ−４が生成するジョブで他の１つのグループが形成されている。各グループは、属するジョブによるサーバ４への負荷が軽いほど上位となるように、グループが順位付けされている。実行手段１ａ−３，１ａ−４が生成するジョブが属するグループの方が上位であるものとする。なお、ジョブがサーバ４に与える負荷は、例えばそのジョブをサーバ４が実行したときの処理時間で判断できる。

実行手段１ａ−１，１ａ−２，１ａ−３，１ａ−４は、サーバ４に実行させるジョブを生成すると、そのジョブが属するグループに対応する待ち行列に、そのジョブの処理要求を登録（キューイング）する。例えば実行手段１ａ−１，１ａ−２は、重いジョブの待ち行列１ｃに、ジョブの処理要求を登録する。また実行手段１ａ−３，１ａ−４は、軽いジョブの待ち行列１ｄに、ジョブの処理要求を登録する。

決定手段１ｂは、ジョブを種別に応じて複数のグループに分類する。例えば実行手段１ａ−１，１ａ−２，１ａ−３，１ａ−４は、それぞれ異なる種別のジョブを生成するものとする。このとき決定手段１ｂは、実行手段１ａ−１，１ａ−２，１ａ−３，１ａ−４それぞれが生成するジョブの種別ごとに、どのグループに属するかを決定する。例えば決定手段１ｂは、ジョブの種別ごとに、サーバ４に実行させたときの平均処理時間を計算し、平均処理時間が短い種別のジョブほど上位のグループとなるように、ジョブが属するグループを決定する。

また決定手段１ｂは、ジョブをサーバ４に実行させたときの、ジョブの種別ごとの平均処理時間と発生比率とに基づいて、ジョブが属するグループを決定することもできる。ジョブの種別の発生比率とは、全体のジョブに対する、その種別のジョブが占める割合である。例えば決定手段１ｂは、ジョブの種別ごとに、平均処理時間と発生比率とを計算する。次に決定手段１ｂは、種別ごとにジョブを複数のグループに振り分ける組み合わせパターンを複数生成する。さらに決定手段１ｂは、組み合わせパターンごとに、上位から所定数のグループ以外のグループに属するジョブの処理要求の抑止によるジョブの処理時間の短縮率を計算する。そして決定手段１ｂは、最も短縮率が大きくなる組み合わせパターンに従って、各種別のジョブが属するグループを決定する。決定手段１ｂは、種別ごとに、その種別のジョブが属するグループを決定すると、決定した結果を実行手段１ａ−１，１ａ−２，１ａ−３，１ａ−４に通知する。各実行手段１ａ−１，１ａ−２，１ａ−３，１ａ−４は、決定手段１ｂからの通知により、ジョブの処理要求を登録する待ち行列を認識できる。

重いジョブの待ち行列１ｃは、サーバ４に実行させるジョブのうち、重いジョブのグループに属するジョブの処理要求を格納する待ち行列である。
軽いジョブの待ち行列１ｄは、サーバ４に実行させるジョブのうち、軽いジョブのグループに属するジョブの処理要求を格納する待ち行列である。

算出手段１ｅは、抑止手段１ｇが重いジョブの処理要求のサーバ４への送信をするか否かの判断に使用する閾値を計算する。例えば算出手段１ｅは、複数のグループそれぞれについて、グループに属するジョブをサーバ４に実行させたときの平均処理時間と、サーバ４に実行させたジョブのうちそのグループに属するジョブが占める割合を示す発生比率とを計算する。そして算出手段１ｅは、複数のグループそれぞれについての平均処理時間と発生比率とに基づいて閾値Ｔ（Ｔは、０より大きい実数）を算出する。例えば算出手段１ｅは、グループごとに平均処理時間と発生比率とを乗算し、上位から所定数のグループそれぞれの乗算結果の合計を、複数のグループすべての乗算結果の合計で除算する。そして算出手段１ｅは、除算結果に、サーバ４に同時に実行させることを許容するジョブ数の最大値を乗算し、最大値の乗算結果を閾値Ｔとする。算出手段１ｅは、算出された閾値を、抑止手段１ｇに通知する。

計数手段１ｆは、サーバ４で実行中のジョブのうち、上位から所定数のグループに属するジョブの数ａ（ａは、１以上の整数）を計数する。例えば計数手段１ｆは、軽いジョブの処理要求をサーバ４に送信するのに使用されているコネクション５の数を、上位から所定数のグループに属するジョブの数ａとする。

抑止手段１ｇは、計数したジョブの数ａが予め定められた閾値Ｔ以上であり、かつ上位から所定数のグループに属する処理待ちのジョブがあるという条件が満たされるかどうかを判断する。そして抑止手段１ｇは、条件が満たされた場合、上位から所定数のグループ以外のグループに属するジョブの処理要求を抑止対象として、抑止対象の処理要求のサーバ４への送信を抑止する。なお、上位から所定数のグループに属する処理待ちのジョブがあるかどうかは、例えば軽いジョブの待ち行列１ｄに、少なくとも１つのジョブの処理要求が登録されているかどうかで判断できる。また抑止手段１ｇは、抑止対象の処理要求を送信する実行手段へのコネクションの割り当てを停止することで、停止対象の処理要求のサーバ４への送信を抑止することができる。

このような情報処理装置１によれば、サーバ２からのジョブの処理要求が入力されると、実行手段１ａ−１，１ａ−２，１ａ−３，１ａ−４によってジョブが実行される。なお実行手段１ａ−１，１ａ−２，１ａ−３，１ａ−４には、決定手段１ｂから、サーバ４に実行させるジョブの属するグループが指定されている。実行手段１ａ−１，１ａ−２，１ａ−３，１ａ−４は、ジョブの実行過程で、サーバ４に実行させるジョブを生成すると、そのジョブが属するグループに応じた待ち行列に、そのジョブの処理要求を登録する。

軽いジョブの待ち行列１ｄに登録されたジョブの処理要求は、コネクション５を介して順次サーバ４に送信される。そして軽いジョブはサーバ４で実行される。このとき、計数手段１ｆにより、サーバ４で実行されているジョブのうちの、軽いジョブの数が計数される。

抑止手段１ｇには、算出手段１ｅによって算出された閾値Ｔが予め通知されている。そして重いジョブの待ち行列１ｃにジョブの処理要求が登録されると、抑止手段１ｇが、サーバ４で実行中の軽いジョブの数ａが、閾値Ｔより少ないかどうかを判断する。軽いジョブの数ａが閾値Ｔより少なければ、重いジョブの待ち行列１ｃからジョブの処理要求が取り出され、コネクション５を介してサーバ４に送信される。他方、軽いジョブの数ａが閾値Ｔ以上の場合、重いジョブの待ち行列１ｃに登録されたジョブの処理要求のサーバ４への送信は抑止される。

このようにして、サーバ４に与える負荷の大きいジョブの待ち時間に、負荷の小さいジョブが巻き込まれることを最少化し、多階層システム全体の平均応答時間の乱高下を抑止することができる。

すなわち第１の実施の形態では、ジョブ実行の優先度制御を、サーバ４で実行中の上位のグループに属するジョブの数に基づいて行っている。これは、サーバ４において飽和しつつある資源の状態を、同時実行ジョブ数の増減から判断していることになる。こうすることによって、サーバ４の処理能力が飽和しつつあることを、完全に飽和しきる前の適切なタイミングで判断できる。そしてサーバ４の資源が飽和しつつある場合、軽いジョブの待ち行列１ｄに、閾値Ｔより多くの待機ジョブが発生する前に、処理負荷の重いジョブの処理要求の送信を抑止することが可能となる。処理負荷の重いジョブの処理要求の送信が抑止されれば、軽いジョブの処理要求が優先的にサーバ４に送信される。これにより、軽いジョブが重いジョブの処理待ちに巻き込まれ、軽いジョブの処理時間が長期化することが抑止される。また軽いジョブは短時間で処理が完了するため、コネクションの占有時間も短くて済む。そして多数のジョブが短時間で終了すれば、平均応答時間が長くならずに済み、サーバ４の処理能力が飽和しそうであっても、その影響が、情報処理装置１やその上位のサーバ２で増幅されることがなくなる。その結果、多階層システム全体において、応答時間の乱高下の発生が抑止される。

なお、図１に示した実行手段１ａ−１，１ａ−２，１ａ−３，１ａ−４、決定手段１ｂ、算出手段１ｅ、計数手段１ｆ、および抑止手段１ｇは、例えば情報処理装置１が有するプロセッサにより実現することができる。また、重いジョブの待ち行列１ｃ、軽いジョブの待ち行列１ｄは、例えば情報処理装置１が有するＲＡＭ（Random Access Memory）により実現することができる。

また、図１に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。
〔第２の実施の形態〕
次に第２の実施の形態について説明する。第２の実施の形態は、Ｗｅｂ３階層システムにおいて、実行するジョブの優先度制御を行うことで、各階層のサーバでの応答時間の変動を抑制するものである。なお以降の説明では、サーバにジョブの処理要求を送信することを、ジョブを投入すると呼ぶ。

ここで、Ｗｅｂ３階層システムにおいて、細かい時間粒度で観測できる飽和状態が多階層コンピュータシステムの下の方の階層で発生したときに、最終的にシステム全体の応答時間が激しく乱高下するメカニズムについて説明する。応答時間が乱高下する現象が発生するメカニズムは、下記の通りである。

ステップ１．システムの各階層への入力ジョブ数は、特別に制御されている場合を除いては、細かな時間粒度で観測すると変動している。これは自然なことである。
ステップ２．システムの負荷の増大につれて、入力ジョブが、多階層コンピュータシステム内の１つ以上の階層の処理能力を飽和させ始める。この段階では、細かな時間粒度で平均応答時間を測定した場合に、一部の時間帯で処理能力の飽和が観測できる程度である。

ステップ３．多階層システム内のある階層の処理能力が一時的にでも飽和すると、その瞬間、その階層を利用するすべてのジョブが、その階層の処理能力に余裕ができるのを待たされる。

ステップ４．多階層システム内には軽い（処理時間が短い）ジョブもあれば重い（処理時間が長い）ジョブもあり、前ステップにおける飽和した階層の処理能力の空き待ちにおいて、軽いジョブが重いジョブの処理完了を待つことが発生する。そのため、軽いジョブであっても重いジョブと同等に応答時間が増大する。結果として、そこの階層における全ジョブ平均の応答時間が急激に上昇する。

ステップ５．平均応答時間の上昇は、同時処理されるジョブ数の増加を招き、上位階層において、ソフトウェア上の有限な資源（プロセス／スレッドやコネクション等）を消費し尽くし、その結果として、ステップ３〜５が再帰的に繰り返される。

ステップ６．変動する入力ジョブ量がピークを過ぎて減少すると、飽和していた階層に処理能力の余力が生まれ、上記の応答時間の増加が解消し、応答時間が減少して元のレベルに戻る。

平均値で測定すると各階層が処理能力に余力を残している段階で、このような応答時間の急激な増加や乱高下が発生すると、その応答時間の増加はエンドユーザへ約束した応答時間（ＳＬＡ（Service Level Agreement）など）の達成を阻害する。また、原因不明の性能劣化と認識され、調査コストが増大することにもなる。

本現象の発生メカニズムを掘り下げて分析すると、以下のような原因が存在することが分かる。
第１の原因：１つの多階層コンピュータシステム内には様々な種類のジョブが混在し、それらがシステム内の各種資源を消費する量は各々異なる。ある資源の観点でみると、軽い（資源消費時間が短い）ジョブと重い（資源消費時間が長い）ジョブとが存在する。そのため、ある資源が飽和した際には、軽いジョブが重いジョブの処理待ちに巻き込まれて、平均応答時間が一気に増大する。

第２の原因：第１の原因によって増加した平均応答時間が、同時処理されるジョブ数の増加を招き、上位の階層において、ソフトウェア上の有限な資源を消費し尽くして、応答時間の増加をさらに拡大させる。

これらの原因について、図２を参照して説明する。
図２は、応答時間が乱高下する原因の一例を示すシーケンス図である。Ｗｅｂサーバ９１０には複数のスレッド９１１，９１２が生成されている。スレッド９１１，９１２は、ユーザが使用する端末装置から入力された処理要求に応じて生成されている。スレッド９１１，９１２は、それぞれ処理要求に応じたジョブ９１３，９１４を実行する。スレッド９１１，９１２は、ジョブ９１３，９１４の実行過程において、Ａｐｐサーバ９２０との連携動作を行う処理があると、Ａｐｐサーバ９２０に依頼するジョブを生成し、そのジョブをＡｐｐサーバ９２０に投入する。

Ａｐｐサーバ９２０は、Ｗｅｂサーバ９１０からのジョブ投入に応じ、スレッド９２１，９２２を生成する。スレッド９２１は、スレッド９１１から投入されたジョブ９２３を実行する。スレッド９２２は、スレッド９１２から投入されたジョブ９２４を実行する。スレッド９２１は、ジョブ９２３の実行過程で、ＤＢサーバ９３０に対するジョブの投入を３回行う。スレッド９２１が投入するジョブ１つ当たりのＤＢサーバ９３０での処理時間は短いが、３個のジョブ９３３〜９３５からなる一連のジョブの最初のジョブ９３３の投入から、最後のジョブ９３５の完了までの処理時間は長い。そのため、一連のジョブは重いジョブとして扱われる。また、スレッド９２２がＤＢサーバ９３０に投入するジョブ９３６は、ＤＢサーバ９３０の処理能力が飽和していなければ、短時間で実行可能な軽いジョブであるものとする。

スレッド９２１，９２２は、ジョブ９２３，９２４の実行過程において、ＤＢサーバ９３０との連携動作を行う処理があると、割り当てられたコネクションを用いて、ＤＢサーバ９３０へジョブの処理要求を送信する。ＤＢサーバ９３０では、スレッド９３１が、スレッド９２１から投入されたジョブ９３３〜９３５を実行する。またスレッド９３２が、スレッド９２２から投入されたジョブ９３６を実行する。このとき、図２の例では、ＤＢサーバ９３０の処理能力が飽和状態にある。そのため、軽いジョブであるジョブ９３６の応答時間が長期化している。これは第１の原因に示したように、軽いジョブが重いジョブの処理に巻き込まれ、ＤＢサーバ９３０内でジョブ９３６の処理待ちが発生したためである。

ＤＢサーバ９３０のスレッド９３１，９３２は、ジョブの実行が完了すると、Ａｐｐサーバ９２０に完了応答を返す。Ａｐｐサーバ９２０のスレッド９２１は、ジョブ９３３の完了応答を受信すると、次のジョブ９３４をＤＢサーバ９３０に投入する。

さらにスレッド９２１，９２２は、ジョブ９３３〜９３５，９３６の完了応答を受信し、それぞれが実行するジョブ９２３，９２４が完了すると、Ｗｅｂサーバ９１０にジョブ完了の応答を送信する。Ｗｅｂサーバ９１０のスレッド９１１，９１２は、Ａｐｐサーバ９２０のスレッド９２１，９２２からのジョブ完了の応答を受信後、それぞれが実行するジョブ９１３，９１４が完了すると、処理要求を送信した端末装置に、ジョブ完了の応答を送信する。

このように、重いジョブ９３３〜９３５の影響で軽いジョブ９３６の応答時間が長期化したことで、Ａｐｐサーバ９２０においてジョブ９３６を投入したスレッド９２２の応答時間も長期化する。さらに、Ｗｅｂサーバ９１０においてジョブ９２４を投入したスレッド９１２の応答時間も長期化する。このように、ジョブ９３６の長期化の提供が、上位層のサーバに伝搬している。各サーバにおける応答時間が長期化すると、コネクションが専有される時間も長期化し、コネクションプール内のコネクションの枯渇を誘発する場合がある。すると、コネクションの割り当て待ちのスレッドが発生し、さらに応答時間の長期化が促進される。その結果、端末装置から観測した場合、処理要求に対する平均応答時間が乱高下する。

図３は、ジョブの優先度制御を行わない場合の平均応答時間の変化の一例を示す図である。図３のグラフは、横軸に時間進行を示し、縦軸に応答時間を示している。応答時間は、細かい時間粒度（例えば０．１秒）ごとの平均応答時間である。図３に示した例では、粗い時間粒度（例えば１秒）でサーバごとの平均応答時間を計測しても、各サーバの処理能力は飽和していない。それにも拘わらず、細かい時間粒度で観測すると、図３に示すように、応答時間が乱高下する。

この問題の解決に関連する技術としては、以下の３つの参考技術が考えられるが、それぞれに問題を抱えている。
図４は、第１の参考技術を示す図である。第１の参考技術は、ジョブの種別（ジョブ種）ごとの他のサーバに投入するジョブの比率が最適となるように、パラメータで静的に設定するものである。

処理能力が飽和しそうな階層のサーバにジョブを投入する階層のサーバにおいて、アプリケーション９２５ａ，９２５ｂ，９２５ｃ，９２５ｄそれぞれが個別のジョブ種のジョブを投入するものとする。アプリケーション９２５ａ，９２５ｂ，９２５ｃ，９２５ｄには、コネクションプール９２６ａ，９２６ｂ，９２６ｃ，９２６ｄが対応付けられている。アプリケーション９２５ａ，９２５ｂ，９２５ｃ，９２５ｄは、対応するコネクションプールからコネクションの割り当てを受け、割り当てられたコネクションを用いてジョブを投入する。第１の参考技術では、アプリケーション９２５ａ，９２５ｂ，９２５ｃ，９２５ｄそれぞれがＤＢサーバ９３０に送り込むジョブ数の割合を、パラメータで静的に最適値に設定しておく。コネクションプール９２６ａ，９２６ｂ，９２６ｃ，９２６ｄそれぞれには、対応するアプリケーションが送り込むジョブ数の割合に応じた数のコネクションが用意される。

この第１の参考技術は、以下の２つの問題を有している。
第１の問題は、ジョブ種別間の投入されるジョブ数の割合が完全に一定となるように特別な制御がなされていない限り、静的に定めた固定のジョブ投入割合が適切に機能しないことである。特別な制御がなされていない一般的な状況下では、ジョブ種別間の投入されるジョブ数の割合は細かな時間間隔で動的に変動する。このような状況下では、第１の参考技術では、処理能力に余力があるときには十分な量のジョブを下位の階層へ送り込めずに、そのことによって性能低下が発生することがある。

例えば、図４の例では、アプリケーション９２５ａ，９２５ｂ，９２５ｃ，９２５ｄそれぞれが投入するジョブ数の割合が、［４：３：１：２］に設定されているものとする。このとき、アプリケーション９２５ｂの投入するジョブが想定よりも多いと、図４に示すように、ＤＢサーバ９３０に処理能力の余力があるにも拘わらず、アプリケーション９２５ｂが投入するジョブだけが、長い待ち行列９２７ｂで投入を待たされる。

第２の問題は、ジョブ投入割合を静的に定めたのでは、上記第１の原因も第２の原因も解決できないことである。処理能力が飽和しそうな階層に対して送り込むジョブの割合を固定すると、その階層の処理能力が飽和した瞬間に、送り手側にジョブが滞留して待ち行列に並ぶことになる。その送り手側の待ち行列の中で、重いジョブが終了しても、また重いジョブが投入される。そして、軽いジョブは、重いジョブの影響で応答時間が長期化する。

図５は、第２の参考技術を示す図である。第２の参考技術は、上位階層からのジョブの送付量を資源の飽和状況に応じて動的に制御するものである。
飽和しつつある階層の処理能力の飽和状況に応じて、その階層にジョブを送り込んでいる前の階層（上位階層）において、ジョブの送付量・送付割合を動的に変更することが可能である。例えば図５に示すように、ＤＢサーバ９３０内のエージェント９３７が、処理能力の飽和状況をＡｐｐサーバ９２０に通知する。Ａｐｐサーバ９２０では、通知された処理能力の飽和状況に応じて、アプリケーション９２５ａ，９２５ｂ，９２５ｃ，９２５ｄごとの投入するジョブ数の割合を動的に変更する。投入するジョブ数の割合を動的に応じて、例えばコネクションプール９２６ａ，９２６ｂ，９２６ｃ，９２６ｄが割り当てるコネクション数も変動する。これにより、状況に応じて投入するジョブ数の割合を最適化でき、上記第１の原因や第２の原因の問題点を解決できる可能性がある。

しかし、多階層システムでは、処理能力が飽和しつつある階層と、そこに対してジョブを送り込む階層とが異なる。このような状況下では、ジョブを送り込む階層において、処理能力が飽和しつつある階層の飽和状況を取得するのにコンピュータ間通信を必要とする。第２の参考技術では、飽和状況を取得する際の通信時間の分のタイムラグがあることによって、飽和状況を取得した後に動的制御を実施したとしても、極めて短時間に発生する飽和状態に対処するには、制御のタイミングが間に合わない。そのため、ＤＢサーバ９３０において短時間だけ発生した飽和状態の影響で、Ａｐｐサーバ９２０の各アプリケーション９２５ａ，９２５ｂ，９２５ｃ，９２５ｄそれぞれから投入するジョブの待ち行列９２７ａ，９２７ｂ，９２７ｃ，９２７ｄが長くなる。

図６は、第３の参考技術を示す図である。第３の参考技術は、待ち行列の長さに応じて、ジョブ投入の優先度を動的に制御するものである。
第３の参考技術では、ＤＢサーバ９３０に対してジョブを送り込んでいるＡｐｐサーバ９２０において、優先度制御部９２８が、ジョブの待ち行列９２７ａ，９２７ｂ，９２７ｃ，９２７ｄの長さから、ＤＢサーバ９３０の処理能力の飽和状態を推測する。そして優先度制御部９２８は、ＤＢサーバ９３０の飽和状態に応じて、各アプリケーション９２５ａ，９２５ｂ，９２５ｃ，９２５ｄのジョブの送付量・送付割合を動的に変更する。第３の参考技術は、第２の参考技術で問題となった、階層が異なるために処理能力が飽和しつつある階層の情報収集にタイムラグが発生して、適切なタイミングで動的制御を掛けられないという問題の解決を試みている。そして、処理能力の飽和状況に応じて、異なるジョブ投入割合を設定できるので、最適化できる可能性がある。しかし、第３の参考技術にも以下の問題が残っている。

待ち行列が発生した段階で既に処理能力は完全に飽和しきっており、その段階で動的制御を開始したとしても、現在の飽和状態が解消されるまでの間は、次のジョブの実行が待たされることになる。もし、その瞬間に実行中のジョブが重いジョブばかりならば、重いジョブの処理が完了するまで、軽いジョブの投入が待たされることになり、上記の第１の原因が発生してしまう。

これから詳細に説明する第２の実施の形態では、上位の階層のサーバにおいて、その階層からジョブを投入する下位の階層のサーバで短時間に発生する飽和状態になりつつあることを迅速に検出し、ジョブの優先度制御を行う。これにより、軽いジョブが重いジョブの処理待ちに巻き込まれて平均応答時間が長期化するのを抑止し、上位の階層のサーバで資源が無駄に消費されることを抑止する。すなわち、ジョブを送り込む階層において、送り込み先の階層の処理能力が飽和しつつあるかどうかを、処理能力が飽和しきって長い待ち行列が発生する前の段階において検出し、その段階において、軽いジョブと重いジョブの処理優先度の動的制御を開始する。それによって、処理能力が飽和した際に発生する、軽いジョブが重いジョブの処理待ちに巻き込まれるという現象を極力避けて、システム全体としての応答時間が必要以上に増加することを抑制する。上記第１の原因の発生が抑止されれば、第１の原因から連鎖的に発生する第２の原因も抑止される。

以下、第２の実施の形態について詳細に説明する。
図７は、第２の実施の形態のシステムの全体構成を示す図である。このシステムは、分析サーバ４００、Ｗｅｂサーバ２００、Ａｐｐサーバ１００、およびＤＢサーバ３００を有する。Ｗｅｂサーバ２００と、Ａｐｐサーバ１００とは、スイッチ装置３１を介して相互に接続されている。Ａｐｐサーバ１００とＤＢサーバ３００とは、スイッチ装置３２を介して相互に接続されている。

スイッチ装置３１，３２は、ポートミラーリング機能を有している。スイッチ装置３１，３２それぞれのポートミラーリング用のポートには、スイッチ装置３４が接続されている。スイッチ装置３１は、ポートミラーリングにより、Ｗｅｂサーバ２００とＡｐｐサーバ１００との間で送受信されるパケットをコピーし、スイッチ装置３４に送信する。スイッチ装置３２は、ポートミラーリングにより、Ａｐｐサーバ１００とＤＢサーバ３００との間で送受信されるパケットをコピーし、スイッチ装置３４に送信する。

ネットワークタップ３３のモニタ用ポートには、スイッチ装置３４が接続されている。ネットワークタップ３３は、Ｗｅｂサーバ２００とネットワーク１０との間で通信されるパケットをコピーし、スイッチ装置３４に送信する。

スイッチ装置３４には、分析サーバ４００が接続されている。スイッチ装置３４は、他のスイッチ装置３１，３２や、ネットワークタップ３３から送られたパケットを、分析サーバ４００に転送する。

端末装置２９ａ，２９ｂ，・・・は、ネットワーク１０を介してＷｅｂサーバ２００にアクセス可能である。端末装置２９ａ，２９ｂ，・・・のユーザは、Ｗｅｂサーバ２００が提供するＧＵＩ（Graphical User Interface）を端末装置２９ａ，２９ｂ，・・・から操作してシステムを利用できる。

分析サーバ４００は、Ｗｅｂサーバ２００、Ａｐｐサーバ１００およびＤＢサーバ３００の稼働状況を管理する。分析サーバ４００は、稼働状況を管理するための情報を、スイッチ装置３４を介して取得することができる。すなわち、分析サーバ４００は、スイッチ装置３４から送信される通信パケットを受信して、記憶する（パケットキャプチャ）。分析サーバ４００は、キャプチャしたパケットを解析し、処理能力が飽和状態となったサーバを検出する。分析サーバ４００は、最上位の階層のサーバ（Ｗｅｂ３階層システムではＷｅｂサーバ２００）以外のサーバにおいて処理能力が飽和状態となったことを検出すると、そのサーバの上位のサーバに、ジョブ実行優先度制御を有効（ＯＮ）に変更する指示を送信する。

Ｗｅｂサーバ２００は、Ｗｅｂブラウザを実行する端末装置２９ａ，２９ｂ，・・・から出力された処理要求（メッセージ）を受け付ける。ここで、Ｗｅｂサーバ２００と端末装置２９ａ，２９ｂ，・・・とのメッセージ交換は、例えばＨＴＴＰ（HyperText Transfer Protocol）によって行われる。

Ｗｅｂサーバ２００は、端末装置２９ａ，２９ｂ，・・・から受信した処理要求に基づいて、静的コンテンツに関しては自装置でＨＴＴＰレスポンスを生成し、端末装置２９ａ，２９ｂ，・・・に送信する。なお、動的コンテンツに関しては、Ａｐｐサーバ１００に依頼すべき処理（ジョブ）の処理要求（メッセージ）を生成して、Ａｐｐサーバ１００に送信する。ここで、Ｗｅｂサーバ２００とＡｐｐサーバ１００とのメッセージ交換は、例えばＩＩＯＰ（Internet Inter-ORB（Object Request Broker） Protocol）によって行われる。Ｗｅｂサーバ２００は、処理要求に対する応答をＡｐｐサーバ１００から受信すると、その応答内容に基づいて端末装置２９ａ，２９ｂ，・・・への応答メッセージを生成する。そしてＷｅｂサーバ２００は、生成した応答メッセージを端末装置２９ａ，２９ｂ，・・・に送信する。

Ａｐｐサーバ１００は、Ｗｅｂサーバ２００から受信した処理要求に基づいてＤＢサーバ３００に依頼すべき処理（ジョブ）のクエリを生成し、ＤＢサーバ３００に送信する。ここで、Ａｐｐサーバ１００が生成するクエリは、例えばＳＱＬ（Structured Query Language）文によって表記され、ＤＢサーバ３００に固有のプロトコルでＤＢサーバ３００へと送信される。Ａｐｐサーバ１００は、ＤＢサーバ３００から応答を受信すると、その応答内容に基づいてＷｅｂサーバ２００への応答メッセージを生成する。そしてＡｐｐサーバ１００は、生成した応答メッセージをＷｅｂサーバ２００に送信する。

ＤＢサーバ３００は、Ａｐｐサーバ１００から受信したクエリに含まれるＳＱＬ文を実行してＤＢの参照や更新等の処理を実行する。ＤＢサーバ３００は、その処理結果に基づいてＤＢレスポンスを生成する。そしてＤＢサーバ３００は、生成した応答メッセージを、Ａｐｐサーバ１００に送信する。

なお、以下の説明では、各サーバという場合、Ｗｅｂサーバ２００、Ａｐｐサーバ１００およびＤＢサーバ３００を示すものとする。さらに、Ｗｅｂサーバ２００は、Ａｐｐサーバ１００およびＤＢサーバ３００よりも上位層のサーバであるものとする。また、Ａｐｐサーバ１００は、ＤＢサーバ３００よりも上位層のサーバであるものとする。

図８は、第２の実施の形態に用いるＡｐｐサーバのハードウェアの一構成例を示す図である。Ａｐｐサーバ１００は、プロセッサ１０１によって装置全体が制御されている。プロセッサ１０１には、バス１０９を介してＲＡＭ１０２と複数の周辺機器が接続されている。なおプロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ、ＭＰＵ（Micro Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、またはＰＬＤ（Programmable Logic Device）である。またプロセッサ１０１は、ＣＰＵ、ＭＰＵ、ＤＳＰ、ＡＳＩＣ、ＰＬＤのうちの２以上の要素の組み合わせであってもよい。

ＲＡＭ１０２は、Ａｐｐサーバ１００の主記憶装置として使用される。ＲＡＭ１０２には、プロセッサ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、プロセッサ１０１による処理に必要な各種データが格納される。

バス１０９に接続されている周辺機器としては、ＨＤＤ（Hard Disk Drive）１０３、グラフィック処理装置１０４、入力インタフェース１０５、光学ドライブ装置１０６、機器接続インタフェース１０７およびネットワークインタフェース１０８ａ，１０８ｂがある。

ＨＤＤ１０３は、内蔵したディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ１０３は、Ａｐｐサーバ１００の補助記憶装置として使用される。ＨＤＤ１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、補助記憶装置としては、フラッシュメモリなどの半導体記憶装置を使用することもできる。

グラフィック処理装置１０４には、モニタ１１が接続されている。グラフィック処理装置１０４は、プロセッサ１０１からの命令に従って、画像をモニタ１１の画面に表示させる。モニタ１１としては、ＣＲＴ（Cathode Ray Tube）を用いた表示装置や液晶表示装置などがある。

入力インタフェース１０５には、キーボード１２とマウス１３とが接続されている。入力インタフェース１０５は、キーボード１２やマウス１３から送られてくる信号をプロセッサ１０１に送信する。なお、マウス１３は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。

光学ドライブ装置１０６は、レーザ光などを利用して、光ディスク１４に記録されたデータの読み取りを行う。光ディスク１４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク１４には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。

機器接続インタフェース１０７は、Ａｐｐサーバ１００に周辺機器を接続するための通信インタフェースである。例えば機器接続インタフェース１０７には、メモリ装置１５やメモリリーダライタ１６を接続することができる。メモリ装置１５は、機器接続インタフェース１０７との通信機能を搭載した記録媒体である。メモリリーダライタ１６は、メモリカード１７へのデータの書き込み、またはメモリカード１７からのデータの読み出しを行う装置である。メモリカード１７は、カード型の記録媒体である。

ネットワークインタフェース１０８ａは、スイッチ装置３１に接続されている。ネットワークインタフェース１０８ａは、スイッチ装置３１を介して、Ｗｅｂサーバ２００などの他のコンピュータとの間でデータの送受信を行う。

ネットワークインタフェース１０８ｂは、スイッチ装置３２に接続されている。ネットワークインタフェース１０８ｂは、スイッチ装置３２を介して、ＤＢサーバ３００などの他のコンピュータとの間でデータの送受信を行う。

以上のようなハードウェア構成によって、Ａｐｐサーバ１００は、第２の実施の形態の処理機能を実現することができる。なおＷｅｂサーバ２００、ＤＢサーバ３００、および分析サーバ４００も、Ａｐｐサーバ１００と同様のハードウェアにより実現することができる。また図１に示した第１の実施の形態に係る情報処理装置１も、図８に示したＡｐｐサーバ１００と同様のハードウェアにより実現することができる。

Ａｐｐサーバ１００は、例えばコンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第２の実施の形態の処理機能を実現する。Ａｐｐサーバ１００に実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。例えば、Ａｐｐサーバ１００に実行させるプログラムをＨＤＤ１０３に格納しておくことができる。プロセッサ１０１は、ＨＤＤ１０３内のプログラムの少なくとも一部をＲＡＭ１０２にロードし、プログラムを実行する。またＡｐｐサーバ１００に実行させるプログラムを、光ディスク１４、メモリ装置１５、メモリカード１７などの可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えばプロセッサ１０１からの制御により、ＨＤＤ１０３にインストールされた後、実行可能となる。またプロセッサ１０１が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。

次に、ジョブ実行優先度制御を行うためのＡｐｐサーバ１００の機能について説明する。
図９は、Ａｐｐサーバの機能の一例を示すブロック図である。Ａｐｐサーバ１００は、パラメータ記憶部１１０、状態設定部１２０、閾値算出部１３０、複数のアプリケーション１４１，１４２，１４３，１４４、複数のジョブ制御部１５０，１６０、および振り分け決定部１７０を有する。

パラメータ記憶部１１０は、ジョブへのコネクションの割り当てに利用される各種パラメータを記憶する。例えばＲＡＭ１０２またはＨＤＤ１０３の記憶領域の一部が、パラメータ記憶部１１０として使用される。

状態設定部１２０は、ジョブ実行優先度制御を実行するか否かを示すジョブ実行優先度制御状態を示すフラグを、パラメータ記憶部１１０に格納する。また状態設定部１２０は、ＤＢサーバ３００に対して同時に実行させることができる最大のジョブ数を示す同時最大実行ジョブ数Ｎ（Ｎは、１以上の整数）を、パラメータ記憶部１１０に格納する。例えば状態設定部１２０は、ジョブ実行優先度制御状態の変更指示を分析サーバ４００から取得し、取得した変更指示に従ってジョブ実行優先度制御状態を示すフラグを、パラメータ記憶部１１０に格納する。また状態設定部１２０は、同時最大実行ジョブ数を分析サーバ４００から取得し、取得した同時最大実行ジョブ数をパラメータ記憶部１１０に格納する。

閾値算出部１３０は、重いジョブを投入するスレッドへコネクションを割り当てるか否かの判断に利用する閾値α（αは、０＜α＜Ｎを満たす実数）を算出する。そして閾値算出部１３０は、例えば、ＤＢサーバ３００で実行されているジョブのうち、軽いジョブの数が閾値αより少なければ、重いジョブを投入するスレッドへのジョブ投入用のコネクションの割り当てを許容する。

閾値算出部１３０は、閾値αを、例えば、それまでに取得し蓄積した統計値（低負荷時における各ジョブ種の平均処理時間と発生比率）から自動算出する。低負荷という判断は、例えば、ＤＢサーバ３００で実行されている同時に実行されているジョブ数が所定値より少ないことで判定できる。また、第２の実施の形態における処理時間とは、１つのスレッドが最初のジョブを実行開始してから最後のジョブの実行が完了するまでの時間となる。第２の実施の形態では、ジョブの投入の際にコネクションの割り当てが行われる。そのため、スレッドがコネクションプールからコネクションの割り当てを受け、そのスレッドがコネクションを返却するまでの時間が、そのスレッドが投入したジョブの処理時間となる。そして、あるジョブ種のジョブの処理時間の平均が、そのジョブ種の平均処理時間である。

なおコネクションを使用している時間の中で、ＤＢサーバ３００へリクエストを送ってから返信を待っている時間（ＤＢサーバ３００へ複数回のリクエストを送る場合はそれらの合計）を処理時間とすることもできる。このほうが、ＤＢサーバ３００に与える負荷が正確に表される。ただし、コネクションの割り当てから解放までの時間を処理時間としても、ＤＢサーバ３００に与える負荷の度合いが十分正確に反映されている。

ジョブ種の発生比率とは、全ジョブの中で、そのジョブ種に属するジョブが占める割合である。
これら統計値より、ＤＢサーバ３００における同時実行ジョブ数の合計が、最大同時実行ジョブ数Ｎとなったときに、ＤＢサーバ３００で同時に実行されるジョブに含まれる軽いジョブの数の期待値を算出することができる。閾値算出部１３０は、その期待値を閾値αとして用いることができる。この場合、閾値算出部１３０は、ジョブ種ごとに、そのジョブ種に属するジョブの平均処理時間と発生比率とを乗算する。次に閾値算出部１３０は、軽いジョブ種それぞれの乗算結果の合計を、全ジョブ種それぞれの乗算結果の合計で除算する。閾値算出部１３０は、除算結果に最大同時実行ジョブ数Ｎを乗算した値を、閾値αとする。

例えば、最大同時実行ジョブ数Ｎ＝６の場合において、統計値が
ジョブＡ（軽いジョブに分類）：平均処理時間５ｍｓ，発生比率０．３０
ジョブＢ（軽いジョブに分類）：平均処理時間２ｍｓ，発生比率０．３５
ジョブＣ（重いジョブに分類）：平均処理時間２０ｍｓ，発生比率０．２０
ジョブＤ（重いジョブに分類）：平均処理時間３０ｍｓ，発生比率０．１５
の場合を想定する。この場合の閾値αは、（５×０．３０＋２×０．３５）÷（５×０．３０＋２×０．３５＋２０×０．２０＋３０×０．１５）×６＝１．２３となる。軽いジョブを優先させる閾値αが１．２３なので、同時実行されている軽いジョブの数が、１．２３を超えたら（ジョブ数は整数なので１を超えて２に達したら）、その超えている間は軽いジョブが重いジョブより優先して実行される。

この閾値αは、動的に変更することも可能である。例えば閾値算出部１３０は、定期的に、なるべく近い時期に収集した統計値で新たな閾値αを計算し、古い統計値から算出した古い閾値αを更新してもよい。使用される統計値はいずれも、アプリケーション１４１〜１４４で収集することができる。なおジョブ制御部１５０，１６０が統計値を収集してもよい。

アプリケーション１４１，１４２，１４３，１４４は、アプリケーションソフトウェアによって実現される処理機能である。例えばアプリケーション１４１，１４２，１４３，１４４は、サーブレットと呼ばれるプログラムをプロセッサ１０１が実行することで実現される。

アプリケーション１４１は、Ｗｅｂサーバ２００からのジョブの処理要求に応じてジョブを実行する。またアプリケーション１４１は、ジョブの実行過程において、適宜ＤＢサーバ３００に対してジョブを投入する。ＤＢサーバ３００からジョブの実行結果が応答されると、アプリケーション１４１は、Ｗｅｂサーバ２００から投入されたジョブの続きを実行する。そしてアプリケーション１４１は、ジョブの実行が終了すると、ジョブの実行結果をＷｅｂサーバ２００に送信する。例えばアプリケーション１４１は、Ｗｅｂサーバ２００からジョブの処理要求が入力されるごとに、スレッド１４１ａを立ち上げ、立ち上げたスレッド１４１ａに、処理要求に従ったジョブを実行させる。

なおアプリケーション１４１は、振り分け決定部１７０によって、ＤＢサーバ３００へジョブを投入する際に使用するジョブ制御部が指定されている。例えばジョブを実行するスレッド１４１ａは、ＤＢサーバ３００へのアクセスが必要な場合、ＤＢサーバ３００に投入するジョブを生成する。生成されたジョブは、処理内容などを定義した情報である。そしてスレッド１４１ａは、生成したジョブをＤＢサーバ３００に投入するためのコネクションの割り当て要求を、指定されたジョブ制御部に送信する。これにより、アプリケーション１４１は、ジョブの投入に使用するコネクションの割り当てを受けることができる。

またアプリケーション１４１は、計測部１４１ｂを有している。計測部１４１ｂは、アプリケーション１４１の各スレッドがＤＢサーバ３００に投入した一連のジョブの平均処理時間、呼出回数などを計測する。一連のジョブの平均の処理時間は、例えば、１つのスレッドが投入した一連のジョブのうちの、先頭のジョブの投入時刻から、最後のジョブの実行完了の応答時刻までの時間である。また呼出回数は、例えば、各スレッドがＤＢサーバに投入したジョブの数である。

アプリケーション１４２，１４３，１４４は、アプリケーション１４１と同様に、スレッド１４２ａ，１４３ａ，１４４ａを用いてジョブを実行する。またアプリケーション１４２，１４３，１４４は、計測部１４２ｂ，１４３ｂ，１４４ｂを有する。アプリケーション１４２，１４３，１４４は、それぞれ振り分け決定部１７０によって、ＤＢサーバ３００へジョブを投入する際に使用するジョブ制御部が指定されている。アプリケーション１４２、１４３，１４４のスレッド１４２ａ，１４３ａ，１４４ａは、予め指定されたジョブ制御部を介して、ＤＢサーバ３００にジョブを投入する。計測部１４２ｂ，１４３ｂ，１４４ｂは、アプリケーション１４２，１４３，１４４の各スレッドがＤＢサーバ３００に投入した一連のジョブの平均処理時間、呼出回数などの統計値を計測する。

ジョブ制御部１５０，１６０の一方は、ＤＢサーバ３００に同時に実行させる重いジョブの数を制御し、他方は、ＤＢサーバ３００に同時に実行させる軽いジョブの数を制御する。第２の実施の形態では、ジョブ制御部１５０が重いジョブのジョブ数を制御し、ジョブ制御部１６０が軽いジョブのジョブ数を制御するものとする。

ジョブ制御部１５０は、ＤＢサーバ３００との通信用に確立されたコネクションのコネクションプール１５１を有している。そしてジョブ制御部１５０は、コネクションプール１５１に含まれるコネクションを、重いジョブをＤＢサーバ３００に投入するスレッドに割り当てる。ただしジョブ制御部１５０は、使用中の合計のコネクション数が所定の最大同時実行ジョブ数Ｎを超えないように、コネクションの割り当てを制御する。またジョブ制御部１５０は、ジョブ実行優先度制御がＯＮ（有効）になっており、ＤＢサーバ３００で実行されている軽いジョブの数が閾値αを超えており、かつ投入待ちの軽いジョブが存在する場合には、重いジョブのＤＢサーバ３００への投入を抑止する。

ジョブ制御部１６０は、ＤＢサーバ３００との通信用に確立されたコネクションのコネクションプール１６１を有している。そしてジョブ制御部１６０は、コネクションプール１６１に含まれるコネクションを、軽いジョブをＤＢサーバ３００に投入するスレッドに割り当てる。ただしジョブ制御部１６０は、使用中の合計のコネクション数が最大同時実行ジョブ数Ｎを超えないように、コネクションの割り当てを制御する。

振り分け決定部１７０は、アプリケーション１４１〜１４４がＤＢサーバ３００に投入するジョブの、ジョブ制御部１５０，１６０への振り分けを決定する。例えばユーザからの入力に従って、アプリケーション１４１〜１４４それぞれが使用するジョブ制御部１５０，１６０を決定することができる。

また振り分け決定部１７０は、アプリケーション１４１〜１４４それぞれが使用するジョブ制御部を、以下のように自動決定することもできる。その場合、振り分け決定部１７０は、それまでに取得した統計値から、各ジョブ種別をどのような組み合わせでジョブ制御部１５０，１６０に割り振れば、処理時間の短縮効果が最も高くなるかを見積もる。統計値は、例えば低負荷時におけるジョブ種ごとの平均処理時間や、処理能力が飽和している期間のジョブ種ごとの発生数である。なお、第２の実施の形態では、同じアプリケーションから投入されるジョブは、同じジョブ種とする。

例えば、振り分け決定部１７０は、ジョブ種を、処理の重さ（待ち時間がない場合の平均処理時間の長さ）順にソートする。次に振り分け決定部１７０は、ソートされたジョブ種の配列を任意の位置で分割し、分割位置よりも重い方のジョブ種を重いジョブ種群、分割位置よりも軽い方のジョブ種を軽いジョブ種群とする。振り分け決定部１７０は、ジョブ種の配列上の分割位置を変えながら、重いジョブ種群と軽いジョブ種群との組み合わせパターンを複数生成する。

次に、振り分け決定部１７０は、生成した組み合わせパターンごとに、処理時間の短縮効果を見積もる。処理時間の短縮効果の見積もりには、例えば、重いジョブ種群に属する重いジョブと軽いジョブ種群に属する軽いジョブとの、ＤＢサーバ３００が低負荷時の平均処理時間の比率ｍ：１（ｍは１以上の実数）を用いる。ここで、ＤＢサーバ３００の処理能力が飽和している期間における重いジョブと軽いジョブとの発生数を、それぞれｎ₁とｎ₂とする。このとき、最悪のスケジューリングの場合の処理時間と最高のスケジューリングの場合の処理時間の比は以下の通りとなる。

振り分け決定部１７０は、生成した複数の組み合わせパターンごとに、式（１）で示した比率を計算する。さらに振り分け決定部１７０は、式（１）で示した比が最適となる組み合わせパターンを選出する。比が最適であるとは、例えば、比の値の逆数（最高のスケジューリングの合計処理時間／最悪のスケジューリングの合計処理時間）が最も小さいことである。そして振り分け決定部１７０は、選出した組み合わせパターンに従って、各アプリケーションからのコネクション割り当て要求の送信先となるジョブ制御部を決定する。

なお、比の値の逆数は、最悪のスケジューリングから最高のスケジューリングに、ジョブの実行順を変更した場合の平均処理時間の短縮率を表している。平均処理時間の短縮率が一定の閾値（例えば０．７（７０％））を超えなかった場合は、ジョブ実行の優先度制御を行ったとしても効果が小さい。そこで比が最適の組み合わせパターンであっても平均処理時間の短縮率が一定の閾値以上の場合、ジョブ実行の優先度制御をＯＦＦにしてもよい。効果が発揮できない場合には、ジョブ実行の優先度制御をＯＦＦにしておくことで、Ａｐｐサーバ１００の処理負荷を軽減できる。

なお図９に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。また、閾値算出部１３０は、図１に示した第１の実施の形態の算出手段１ｅの一例である。アプリケーション１４１〜１４４は、図１に示した第１の実施の形態の実行手段１ａ−１，１ａ−２，１ａ−３，１ａ−４の一例である。ジョブ制御部１５０，１６０それぞれは、図１に示した第１の実施の形態の計数手段１ｆと抑止手段１ｇとを包含する機能の一例である。振り分け決定部１７０は、図１に示した第１の実施の形態の決定手段１ｂの一例である。

次にパラメータ記憶部１１０に格納されるパラメータについて詳細に説明する。
図１０は、パラメータ記憶部のデータ構造の一例を示す図である。パラメータ記憶部１１０には、優先度制御フラグ１１１、最大同時実行ジョブ数１１２、閾値１１３、同時実行ジョブ数カウンタ１１４、重いジョブ実行数カウンタ１１５、軽いジョブ実行数カウンタ１１６、重いジョブ待ち数カウンタ１１７、および軽いジョブ待ち数カウンタ１１８が格納されている。

優先度制御フラグ１１１は、ジョブ実行優先度制御の状態を示すフラグである。例えばジョブ実行優先度制御が有効（ＯＮ）の場合、優先度制御フラグ１１１に「１」が設定される。またジョブ実行優先度制御が無効（ＯＦＦ）の場合、優先度制御フラグ１１１に「０」が設定される。

最大同時実行ジョブ数１１２は、ＤＢサーバ３００に同時に実行させるジョブの最大数である。以下、最大同時実行ジョブ数１１２に設定された値をＮとする。
閾値１１３は、ジョブ実行優先度制御が有効な場合に、重いジョブを投入するスレッドにコネクションを割り当てるか否かの判断基準となる閾値である。以下、閾値１１３の値をαとする。

同時実行ジョブ数カウンタ１１４は、ＤＢサーバ３００で同時に実行されているジョブ数を示すカウンタである。同時実行ジョブ数カウンタ１１４の初期値は「０」である。同時実行ジョブ数カウンタ１１４の値は、ＤＢサーバ３００にジョブが投入されるごとに、１ずつカウントアップされ、ＤＢサーバ３００で実行されたジョブが終了するごとにカウントダウンされる。

重いジョブ実行数カウンタ１１５は、ＤＢサーバ３００で実行中のジョブのうちの、重いジョブの数を示すカウンタである。重いジョブ実行数カウンタ１１５の初期値は「０」である。重いジョブ実行数カウンタ１１５の値は、ＤＢサーバ３００に重いジョブが投入されるごとに、１ずつカウントアップされ、ＤＢサーバ３００で実行された重いジョブが終了するごとにカウントダウンされる。

軽いジョブ実行数カウンタ１１６は、ＤＢサーバ３００で実行中のジョブのうちの、軽いジョブの数を示すカウンタである。軽いジョブ実行数カウンタ１１６の初期値は「０」である。軽いジョブ実行数カウンタ１１６の値は、ＤＢサーバ３００に軽いジョブが投入されるごとに、１ずつカウントアップされ、ＤＢサーバ３００で実行された軽いジョブが終了するごとにカウントダウンされる。

重いジョブ待ち数カウンタ１１７は、ＤＢサーバ３００への投入待ち状態の重いジョブの数を示すカウンタである。重いジョブ待ち数カウンタ１１７の初期値は「０」である。重いジョブ待ち数カウンタ１１７の値は、重いジョブをＤＢサーバ３００に投入するスレッドへのコネクションの割り当てが保留されるごとにカウントアップされる。また重いジョブ待ち数カウンタ１１７の値は、コネクションの割り当てが保留された、重いジョブをＤＢサーバ３００に投入するスレッドについて、コネクションの割り当てを行うか否かの判断を再度行う際にカウントダウンされる。

軽いジョブ待ち数カウンタ１１８は、ＤＢサーバ３００への投入待ち状態の軽いジョブの数を示すカウンタである。軽いジョブ待ち数カウンタ１１８の初期値は「０」である。軽いジョブ待ち数カウンタ１１８の値は、軽いジョブをＤＢサーバ３００に投入するスレッドへのコネクションの割り当てが保留されるごとにカウントアップされる。また軽いジョブ待ち数カウンタ１１８の値は、コネクションの割り当てが保留された、軽いジョブをＤＢサーバ３００に投入するスレッドについて、コネクションの割り当てを行うか否かの判断を再度行う際にカウントダウンされる。

図１０に示すようなパラメータ記憶部１１０内の各種パラメータを用いて、ＤＢサーバ３００の応答時間の変動を抑止させるような、コネクションの割り当てを行う。
図１１は、コネクションの割り当て状況の一例を示す図である。図１１の例では、アプリケーション１４１，１４２がＤＢサーバ３００に投入するジョブは重いジョブであり、アプリケーション１４３，１４４がＤＢサーバ３００に投入するジョブは軽いジョブである。そこでアプリケーション１４１，１４２には、コネクション割り当て要求の送信先として、ＤＢサーバ３００に実行させる重いジョブの数を制御するジョブ制御部１５０が指定されている。また、アプリケーション１４３，１４４には、コネクション割り当て要求の送信先として、ＤＢサーバ３００に実行させる軽いジョブの数を制御するジョブ制御部１６０が指定されている。

Ｗｅｂサーバ２００とＡｐｐサーバ１００との間には、複数のコネクション４１が確立されている。またＡｐｐサーバ１００とＤＢサーバ３００との間にも、複数のコネクション４２が確立されている。Ａｐｐサーバ１００とＤＢサーバ３００との間に確立されたコネクションは、ジョブ制御部１５０，１６０において、コネクションプール１５１，１６１として管理されている。図１１では、複数のコネクション４１，４２のうち、使用されているコネクションを実線で示し、使用されていないコネクションを点線で示している。

Ｗｅｂサーバ２００からＡｐｐサーバ１００へは、いずれかのコネクションを用いてジョブが投入される。Ｗｅｂサーバ２００からＡｐｐサーバ１００に投入されるジョブでは、ジョブを実行するアプリケーションが指定されている。Ａｐｐサーバ１００は、投入されたジョブで指定されたアプリケーションにそのジョブを実行させる。

各アプリケーション１４１〜１４４は、ジョブを実行する場合、そのジョブを実行するスレッドを生成する。そして生成したスレッドにジョブを実行させる。アプリケーション１４１〜１４４内のスレッドは、ジョブの実行中にＤＢサーバ３００との連携処理が発生すると、ＤＢサーバ３００に投入するジョブを生成し、予め指定されたジョブ制御部にコネクション割り当て要求を送信する。例えば重いジョブを実行するアプリケーション１４１，１４２内のスレッドは、ジョブ制御部１５０に対してコネクション割り当て要求を送信する。また、軽いジョブを実行するアプリケーション１４３，１４４内のスレッドは、ジョブ制御部１６０に対してコネクション割り当て要求を送信する。

ジョブ制御部１５０，１６０では、コネクション割り当て要求に応じて、スレッドに対するコネクションの割り当てを行う。コネクションが割り当てられたスレッドは、そのコネクションを用いてＤＢサーバ３００に対してジョブを投入する。コネクションの割り当てが保留された場合、そのスレッドが投入するジョブは、例えば、待ち行列１４１ｃ，１４２ｃ，１４３ｃ，１４４ｃにキューイング（待ち行列の最後尾にジョブを登録すること）される。アプリケーション１４１，１４２それぞれが投入するジョブの待ち行列１４１ｃ，１４２ｃは、例えばジョブ制御部１５０で管理される。またアプリケーション１４３，１４４それぞれが投入するジョブの待ち行列１４３ｃ，１４４ｃは、例えばジョブ制御部１６０で管理される。

このような構成のＷｅｂ３階層システムにより、ユーザへのサービスが提供される。以下、ＤＢサーバ３００の処理能力の飽和状態の発生による、システム全体としての応答時間の乱高下を抑止する場合を例に採って、優先度制御処理を説明する。

図１２は、第２の実施の形態に係るＡｐｐサーバの処理の概要を示す図である。ジョブ実行の優先度制御を行うかどうかは、分析サーバ４００から送られる、優先度制御状態のＯＮ／ＯＦＦ信号によって切り替えられる。例えば分析サーバ４００は、各サーバが通信したパケットを収集して、短い時間間隔（例えば０．１秒）の時間帯ごとに、各サーバの処理能力が飽和しているかどうかを監視する。そして分析サーバ４００は、処理能力が飽和状態となっている時間帯が存在するサーバを検出すると、そのサーバが属する階層の上位の階層のサーバに対して、ジョブ実行の優先度制御をＯＮにすることを指示する信号を送信する。例えばＤＢサーバ３００の処理能力が間欠的に飽和状態となっている場合、Ａｐｐサーバ１００に対して、ジョブ実行の優先度制御をＯＮにすることを指示する信号を送信する。また分析サーバ４００は、優先度制御をＯＮにしたサーバの下位の階層のサーバについて、飽和状態が長期間継続すること（完全飽和状態）、または飽和状態がまったく検出されなくなったこと（未飽和状態）を検出する。分析サーバ４００は、サーバの完全飽和状態への移行、または未飽和状態への移行を検知すると、そのサーバの上位の階層の、ジョブ実行の優先度制御がＯＮとなっているサーバに、優先度制御をＯＦＦにすることを指示する信号を送信する。

分析サーバ４００は、例えば、ＤＢサーバ３００で実行されるジョブの多重度（同時並行に実行する処理の個数）と、１つのジョブの応答時間との関係に基づいて、多重度の飽和状態を判断し、優先度制御のＯＮまたはＯＦＦを指示する信号を送信する。例えば分析サーバ４００は、観測期間を細分化して得られる集計区間ごとに、その集計区間内で実行された単位期間における処理の多重度の平均と、その単位期間における処理の合計進行量との関係を求める。合計進行量は、集計区間内で実行された処理それぞれの進行量を合計したものである。各処理の進行量は、例えばその処理全体の所要時間に対する、該当集計区間内で実行した時間の割合で表される。分析サーバ４００は、多重度が上昇しても合計進行量が上昇しなくなっている境界の多重度を、処理性能が限界（飽和状態）に達した多重度とする。そして分析サーバ４００は、飽和多重度以上の多重度である集計区間の出現割合が所定の第１の閾値を超えたサーバを、部分飽和状態にあると判断する。分析サーバ４００は、部分飽和状態となったサーバの上位の階層のサーバに、優先度制御のＯＮを指示する信号を送信する。また分析サーバ４００は、飽和多重度以上の多重度である集計区間の出現割合が、第１の閾値より大きな第２の閾値を超えたサーバを、完全飽和状態にあると判断する。分析サーバ４００は、完全飽和状態となったサーバの上位の階層のサーバに、優先度制御のＯＦＦを指示する信号を送信する。さらに分析サーバ４００は、飽和多重度以上の多重度である集計区間の出現割合が第１の閾値より小さな第３の閾値未満にあるサーバを、未飽和状態と判断する。分析サーバ４００は、未飽和状態となったサーバの上位の階層のサーバに、優先度制御のＯＦＦを指示する信号を送信する。

また分析サーバ４００は、例えば、ＤＢサーバ３００に同時に実行させるジョブの合計の最大数（最大同時実行ジョブ数Ｎ）を、Ａｐｐサーバ１００に通知する。最大同時実行ジョブ数Ｎは、例えば、処理能力が飽和しつつある層のサーバを完全飽和させるのに丁度よい、不必要なオーバヘッドを生じさせない数である。

分析サーバ４００は、例えば、ＤＢサーバ３００で実行されるジョブの多重度と、１つのジョブの応答時間との関係に基づいて、最大同時実行ジョブ数Ｎを決定する。例えば分析サーバ４００は、観測期間を細分化して得られる集計区間ごとに、その集計区間内での平均の多重度を計算する。また分析サーバ４００は、各集計区間内における、応答時間が所定の許容時間以下のトランザクションを抽出する。そして分析サーバ４００は、抽出したトランザクションを実行するジョブのうちの、ＤＢサーバ３００内のジョブによる処理の合計進行量を計算する。そして分析サーバ４００は、多重度の増加に伴って合計進行量が低下し始める多重度を、最大同時実行ジョブ数Ｎとする。このようにして求められた最大同時実行ジョブ数Ｎは、応答時間を許容範囲内に維持できる多重度制限値の上限である。

なおジョブの多重度を用いた優先度制御のＯＮ／ＯＦＦ制御や最大同時実行ジョブ数Ｎの決定は一例であり、他の方法で優先度制御のＯＮ／ＯＦＦ制御や最大同時実行ジョブ数Ｎの決定を行ってもよい。

分析サーバ４００からＡｐｐサーバ１００に送られた優先度制御のＯＮまたはＯＦＦを指示する信号に基づいて、状態設定部１２０が、パラメータ記憶部１１０内の優先度制御フラグ１１１の値を変更する。また分析サーバ４００からＡｐｐサーバ１００に送られた最大同時実行ジョブ数Ｎを、状態設定部１２０が受信し、パラメータ記憶部１１０に格納する。

またＡｐｐサーバ１００内で動作するアプリケーション１４１〜１４４それぞれの計測部１４１ｂ，１４２ｂ，１４３ｂ，１４４ｂでは、投入した一連のジョブの平均処理時間や呼出回数（ＤＢサーバ３００へのジョブの投入回数）などの統計値が収集される。なお１つのスレッドがＤＢサーバ３００に複数回のジョブの投入を行う場合、最初のジョブの投入時刻から、最後のジョブの完了応答の受信時刻までの時間が、そのスレッドにおける一連のジョブの処理時間となる。そして、各計測部１４１ｂ，１４２ｂ，１４３ｂ，１４４ｂから閾値算出部１３０へ、統計値が送信される。

閾値算出部１３０では、アプリケーション１４１〜１４４から受け取った統計値を、ＲＡＭ１０２またはＨＤＤ１０３に蓄積する。そして閾値算出部１３０は、ジョブ実行の優先度の動的変更を行うための閾値αを、それまでに取得し蓄積しておいた統計値から自動算出する。例えば閾値算出部１３０は、低負荷時における各ジョブ種の平均処理時間と発生比率に基づいて、閾値αを算出する。低負荷という判断は、両方のジョブ制御部１５０，１６０で実行されている同時実行ジョブ数の合計値が、所定の閾値より低いことで判定できる。閾値算出部１３０は、例えば、最大同時実行ジョブ数Ｎをパラメータ記憶部１１０から読み出す。そして閾値算出部１３０は、最大同時実行ジョブ数Ｎの中で軽いジョブが占める数の期待値を、各ジョブ種の平均処理時間と発生比率に基づいて算出する。閾値算出部１３０は、算出した期待値を閾値αとして、パラメータ記憶部１１０に登録する。

最大同時実行ジョブ数Ｎにおける軽いジョブが占める数の期待値を閾値αとしたのは、次の理由による。処理能力が飽和しつつある階層に対して、最大同時実行ジョブ数Ｎでジョブを送り込むと、その階層の処理能力が飽和することが分かっている。また、２つのジョブ制御部１５０，１６０に割り当てられている重いジョブと軽いジョブの間での、同時実行ジョブ数の比率の期待値も分かっている。そこで、軽いジョブがその閾値αを超えた場合には、重いジョブと軽いジョブの合計で同時実行ジョブ数の合計値がＮまで達していなくても、その階層における処理能力は飽和状態に近づいていると判断できる。そこで第２の実施の形態では、最大同時実行ジョブ数Ｎにおける軽いジョブが占める数の期待値を閾値αとして、軽い実行ジョブ数が閾値αを超えた場合、その階層における処理能力は飽和状態に近づいていると判断するようにした。

このようにして、設定された各種パラメータを用いて、２つのジョブ制御部１５０，１６０が、ＤＢサーバ３００に実行させるジョブの優先度を動的に制御する。以下、投入するジョブの優先度制御を行っているときの、重いジョブと軽いジョブとの優先度制御について、図１３を参照して説明する。

図１３は、ジョブの優先度制御の一例を示す図である。Ｗｅｂサーバ２００には複数のスレッド２０１，２０２が生成されている。スレッド２０１，２０２は、ユーザが使用する端末装置から入力された処理要求（ジョブの投入）に応じて生成されている。スレッド２０１，２０２は、それぞれ処理要求に応じたジョブ２１１，２１２を実行する。スレッド２０１，２０２は、ジョブ２１１，２１２の実行過程において、Ａｐｐサーバ１００との連携動作を行う処理があると、Ａｐｐサーバ１００に依頼するジョブを生成し、そのジョブをＡｐｐサーバ１００に投入する。

Ａｐｐサーバ１００は、Ｗｅｂサーバ２００からのジョブ投入に応じ、スレッド１４１ａ，１４３ａを生成する。スレッド１４１ａは、スレッド２０１から投入されたジョブ１８１を実行する。スレッド１４３ａは、スレッド２０２から投入されたジョブ１８２を実行する。スレッド１４１ａは、ジョブ１８１の実行過程で、ＤＢサーバ３００に対するジョブ投入を３回行う。スレッド１４１ａが投入するジョブ１つ当たりのＤＢサーバ３００での処理時間は短いが、３個のジョブ３１１〜３１３からなる一連のジョブの最初のジョブ３１１の投入から、最後のジョブ３１３の完了までの処理時間は長い。第２の実施の形態において、同一コネクションで投入される一連のジョブは、処理時間の計算上、同一のジョブとして扱われる。そのため、一連のジョブ３１１〜３１３は重いジョブと判断される。また、スレッド１４３ａがＤＢサーバ３００に投入するジョブ３１４は、ＤＢサーバ３００の処理能力が飽和していなければ、短時間で実行可能な軽いジョブである。

ここでＡｐｐサーバ１００において、優先度制御フラグ１１１がＯＮとなっており、優先度制御が行われているものとする。また図示しない別の軽いジョブが、待ち行列１４３ｃにキューイングされており、ＤＢサーバ３００における軽いジョブの同時実行数が、閾値αを超えているものとする。

このような状況において、スレッド１４１ａがジョブ１８１を実行する過程でＤＢサーバ３００と連携する処理が発生すると、スレッド１４１ａは、重いジョブ用のジョブ制御部１５０に対して、コネクション割り当て要求を送信する（ステップＳ１１）。ジョブ制御部１５０は、優先度制御中であり、軽いジョブが待ち行列１４３ｃにキューイングされているため、重いジョブのコネクション割り当てを抑止する（ステップＳ１２）。

他方、スレッド１４３ａがジョブ１８２を実行する過程でＤＢサーバ３００と連携する処理が発生すると、スレッド１４３ａは、軽いジョブ用のジョブ制御部１６０に対して、コネクション割り当て要求を送信する（ステップＳ１３）。ジョブ制御部１６０は、ＤＢサーバ３００に投入しているジョブの総数が同時最大実行ジョブ数Ｎ未満であれば、コネクション割り当て要求に応じて、スレッド１４３ａにコネクションを割り当てる（ステップＳ１４）。そしてジョブ制御部１６０は、スレッド１４３ａに対して、コネクション割り当て完了通知を送信する（ステップＳ１５）。その後、スレッド１４３ａは、割り当てられたコネクションを用いて、ＤＢサーバ３００にジョブを投入する。するとＤＢサーバ３００でスレッド３０２が生成され、投入されたジョブ３１４をスレッド３０２が実行する。ジョブ３１４の処理が完了すると、スレッド３０２からＡｐｐサーバ１００へ、ジョブの完了応答が送信される。

Ａｐｐサーバ１００のスレッド１４３ａは、ＤＢサーバ３００からのジョブの完了応答を受信すると、ジョブ制御部１６０に対し、コネクション返却通知を送信する（ステップＳ１６）。ジョブ制御部１６０は、コネクション返却通知に応答して、スレッド１４３ａに割り当てたコネクションを解放する（ステップＳ１７）。そしてジョブ制御部１６０は、スレッド１４３ａに、コネクション解放完了応答を送信する（ステップＳ１８）。コネクション解放完了応答を受信したスレッド１４３ａは、ジョブ１８２の残りの処理を実行し、ジョブ１８２の処理が完了すると、Ｗｅｂサーバ２００にジョブの完了応答を送信する。

その後、ジョブ制御部１５０は、優先度制御がＯＦＦに変更されるか、待ち行列１４３ｃ，１４４ｃに登録された軽いジョブが無くなったときに、スレッド１４１ａに対してコネクションを割り当てる。そしてジョブ制御部１５０は、スレッド１４１ａに対して、コネクション割り当て完了通知を送信する。その後、スレッド１４１ａは、割り当てられたコネクションを用いて、ＤＢサーバ３００に３つのジョブを順番に投入する。するとＤＢサーバ３００でスレッド３０１が生成され、投入されたジョブ３１１〜３１３をスレッド３０１が実行する。ジョブ３１１〜３１３の処理が完了すると、スレッド３０１からＡｐｐサーバ１００へ、ジョブの完了応答が送信される。

Ａｐｐサーバ１００のスレッド１４１ａは、ＤＢサーバ３００からのジョブの完了応答を受信すると、ジョブ制御部１５０に対し、コネクション返却通知を送信する（ステップＳ２０）。ジョブ制御部１５０は、コネクション返却通知に応答して、スレッド１４１ａに割り当てたコネクションを解放する（ステップＳ２１）。そしてジョブ制御部１５０は、スレッド１４１ａに、コネクション解放完了応答を送信する（ステップＳ２２）。コネクション解放完了応答を受信したスレッド１４１ａは、ジョブ１８１の残りの処理を実行し、ジョブ１８１の処理が完了すると、Ｗｅｂサーバ２００にジョブの完了応答を送信する。

このように第２の実施の形態では、軽いジョブ用のジョブ制御部１６０を経由してＤＢサーバ３００に投入されているジョブの同時実行数が閾値αを超えている間は、軽いジョブが、高い優先度でＤＢサーバ３００に投入される。またＤＢサーバ３００に投入されているジョブの同時実行数が閾値αを超えている間は、ジョブ制御部１５０は、重いジョブの新規の投入を抑止する。ただし、既に実行を開始している重いジョブに関しては、そのまま完了するまで処理が継続される。こうすることによって、軽いジョブが重いジョブより前にスケジューリングされて、軽いジョブの実行が重いジョブの実行に巻き込まれて余分な待ち時間が発生することが抑止される。その結果、システム全体としての応答時間の増加を最小限に止めることができる。

図１４は、ジョブの実行順の違いによる平均応答時間の変化の一例を示す図である。図１４の例では、重いジョブＡ（処理に要する時間：２０ミリ秒）と軽いジョブＢ（処理に要する時間：２ミリ秒）が同時に到着した場合の、実行順の違いによる平均応答時間の違いを示している。なお、図１４では、簡略化のために並列度（同時に投入可能なジョブ数）が「１」であると仮定している。

図１４の上段は、重いジョブＡを先に投入した場合の例である。この場合、重いジョブＡの応答時間は２０ミリ秒、軽いジョブＢの応答時間は２２ミリ秒となる。その結果、平均応答時間は２１ミリ秒となる。

図１４の下段は、軽いジョブＢを先に投入した場合の例である。この場合、重いジョブＡの応答時間は２２ミリ秒、軽いジョブＢの応答時間は２ミリ秒となる。その結果、平均応答時間は１２ミリ秒となる。

このように、軽いジョブを優先的に実行することで、ＤＢサーバ３００が部分飽和状態になっても、平均応答時間の増加を最小限に抑えることができる。応答時間の増加が少ないということは、システム内に滞留している同時実行ジョブ数の増加が少ないということである。これは、同時処理されるジョブ数の増加により、上位の階層において資源が枯渇し、応答時間の増加をさらに拡大させることが抑止されることを意味する。すなわち前述の第２の原因が取り除かれ、応答時間の乱高下が抑止される。

なお、第２の実施の形態では、軽いジョブ用のジョブ制御部１６０を経由して実行されているジョブの同時実行数が閾値αを超えている期間において、重いジョブが投入されるのは、次のケースに限られる。
・ＤＢサーバ３００に同時に投入されている重いジョブと軽いジョブとの合計値が、最大同時実行ジョブ数Ｎ未満であり、かつ、軽いジョブ用の待ち行列１４３ｃ，１４４ｃにジョブが存在しない場合である。

なお、軽いジョブ用のジョブ制御部１６０を経由して投入されているジョブの同時実行数が閾値α未満になれば、重いジョブは初期状態に従って処理される。
次に、このようなジョブの優先度制御の処理手順について詳細に説明する。まず、状態設定部１２０による状態設定処理について説明する。

図１５は、状態設定処理の手順の一例を示すフローチャートである。以下、図１５に示す処理をステップ番号に沿って説明する。
［ステップＳ１０１］状態設定部１２０は、分析サーバ４００から、ジョブ実行の優先度制御をＯＮすることを指示する信号が入力されたか否かを判断する。状態設定部１２０は、その信号が入力された場合、処理をステップＳ１０２に進める。また状態設定部１２０は、その信号が入力されていなければ、処理をステップＳ１０３に進める。

［ステップＳ１０２］状態設定部１２０は、優先度制御をＯＮすることを指示する信号が入力されると、優先度制御状態をＯＮにする。例えば状態設定部１２０は、パラメータ記憶部１１０内の優先度制御フラグ１１１に「１」を設定する。その後、状態設定部１２０は、処理をステップＳ１０３に進める。

［ステップＳ１０３］状態設定部１２０は、分析サーバ４００から、ジョブ実行の優先度制御をＯＦＦにすることを指示する信号が入力されたか否かを判断する。状態設定部１２０は、その信号が入力された場合、処理をステップＳ１０４に進める。また状態設定部１２０は、その信号が入力されていなければ、処理をステップＳ１０５に進める。

［ステップＳ１０４］状態設定部１２０は、優先度制御をＯＦＦすることを指示する信号が入力されると、優先度制御状態をＯＦＦにする。例えば状態設定部１２０は、パラメータ記憶部１１０内の優先度制御フラグ１１１に「０」を設定する。その後、状態設定部１２０は、処理をステップＳ１０５に進める。

［ステップＳ１０５］状態設定部１２０は、状態設定処理の停止コマンドが入力されたか否かを判断する。状態設定部１２０は、停止コマンドが入力された場合、状態設定処理を終了する。また状態設定部１２０は、停止コマンドが入力されていなければ、処理をステップＳ１０１に進める。

このように、第２の実施の形態では、分析サーバ４００からの指示により、ジョブ実行の優先度制御のＯＮ／ＯＦＦの切り替えが行われる。
次に、重いジョブ用のジョブ制御部１５０におけるジョブ数制御処理について説明する。

図１６は、重いジョブ数制御処理の手順の一例を示すフローチャートの前半である。以下、図１６に示す処理をステップ番号に沿って説明する。なお、重いジョブ数制御処理は、アプリケーション１４１，１４２内のスレッドが、ジョブ制御部１５０にコネクション割り当て要求を送信したときに実行される。以下、スレッド１４１ａがコネクション割り当て要求を送信したものとして、重いジョブ数制御処理を説明する。

［ステップＳ１１１］ジョブ制御部１５０は、ジョブ実行の優先度制御がＯＮに設定されているか否かを判断する。例えばジョブ制御部１５０は、パラメータ記憶部１１０内の優先度制御フラグ１１１の値が「１」であれば、優先度制御がＯＮであると判断する。ジョブ制御部１５０は、優先度制御がＯＮであれば、処理をステップＳ１１２に進める。またジョブ制御部１５０は、優先度制御がＯＦＦであれば、処理をステップＳ１１８に進める。

［ステップＳ１１２］ジョブ制御部１５０は、優先度制御がＯＮの場合、ＤＢサーバ３００で実行されているジョブの総数（同時実行ジョブ数）が、パラメータ記憶部１１０に設定された最大同時実行ジョブ数Ｎより小さいか否かを判断する。なおジョブ制御部１５０は、パラメータ記憶部１１０内の同時実行ジョブ数カウンタ１１４を参照することで、現在の同時実行ジョブ数を認識する。ジョブ制御部１５０は、同時実行ジョブ数が、最大同時実行ジョブ数Ｎより小さければ、処理をステップＳ１１３に進める。またジョブ制御部１５０は、同時実行ジョブ数が、最大同時実行ジョブ数Ｎ以上であれば、処理をステップＳ１１５に進める。

［ステップＳ１１３］ジョブ制御部１５０は、ＤＢサーバ３００で実行されている軽いジョブの数（軽いジョブ実行数）が、パラメータ記憶部１１０に設定された閾値αより小さいか否かを判断する。なおジョブ制御部１５０は、パラメータ記憶部１１０内の軽いジョブ実行数カウンタ１１６を参照することで、現在の軽いジョブ実行数を認識する。ジョブ制御部１５０は、軽いジョブ実行数が閾値αより小さければ、処理をステップＳ１１８に進める。またジョブ制御部１５０は、軽いジョブ実行数が閾値α以上であれば、処理をステップＳ１１４に進める。

［ステップＳ１１４］ジョブ制御部１５０は、軽いジョブ用のジョブ制御部１６０が管理するジョブの待ち行列１４３ｃ，１４４ｃに、処理待ちの軽いジョブがあるか否かを判断する。例えばジョブ制御部１５０は、パラメータ記憶部１１０内の軽いジョブ待ち数カウンタ１１８を参照し、軽いジョブ待ち数カウンタ１１８の値が「１」以上であれば、処理待ちの軽いジョブがあると判断する。ジョブ制御部１５０は、処理待ちの軽いジョブがある場合、処理をステップＳ１１５に進める。またジョブ制御部１５０は、処理待ちの軽いジョブがなければ、処理をステップＳ１１８に進める。

［ステップＳ１１５］ジョブ制御部１５０は、パラメータ記憶部１１０内の重いジョブ待ち数カウンタ１１７の値を「１」だけ増加させる。
［ステップＳ１１６］ジョブ制御部１５０は、コネクションプール１５１，１６１のいずれかにコネクションが返却されるまで、スレッド１４１ａを待機させる。

［ステップＳ１１７］ジョブ制御部１５０は、コネクションが返却されスレッド１４１ａの待機状態が解除されると、パラメータ記憶部１１０内の重いジョブ待ち数カウンタ１１７の値を「１」だけ減少させる。その後、ジョブ制御部１５０は処理をステップＳ１１１に進める。

［ステップＳ１１８］ジョブ制御部１５０は、パラメータ記憶部１１０内の同時実行ジョブ数カウンタ１１４の値を「１」だけ増加させる。
［ステップＳ１１９］ジョブ制御部１５０は、パラメータ記憶部１１０内の重いジョブ実行数カウンタ１１５の値を「１」だけ増加させる。

［ステップＳ１２０］ジョブ制御部１５０は、重いジョブ用のコネクションプール１５１から１つのコネクションを獲得し、獲得したコネクションをスレッド１４１ａに割り当てる。その後、ジョブ制御部１５０は処理をステップＳ１３１（図１７参照）に進める。

図１７は、重いジョブ数制御処理の手順の一例を示すフローチャートの後半である。以下、図１７に示す処理をステップ番号に沿って説明する。
［ステップＳ１３１］ジョブ制御部１５０からコネクションの割り当てを受けたスレッド１４１ａは、投入するジョブがあるか否かを判断する。スレッド１４１ａは、投入するジョブがあれば、処理をステップＳ１３２に進める。またスレッド１４１ａは、投入するジョブがなければ、処理をステップＳ１３４に進める。

［ステップＳ１３２］スレッド１４１ａは、割り当てられたコネクションを使用して、ＤＢサーバ３００に対してジョブを投入する。
［ステップＳ１３３］スレッド１４１ａは、ＤＢサーバ３００から、ステップＳ１３２で投入したジョブの完了応答を受信する。その後、スレッド１４１ａは、処理をステップＳ１３１に進める。

［ステップＳ１３４］スレッド１４１ａは、ジョブの投入に使用したコネクションを、コネクションプール１５１に返却する。例えばスレッド１４１ａは、ジョブ制御部１５０へ、コネクション返却通知を送信する。するとジョブ制御部１５０は、スレッド１４１ａに割り当てられていたコネクションを解放する。

［ステップＳ１３５］ジョブ制御部１５０は、パラメータ記憶部１１０内の重いジョブ実行数カウンタ１１５の値を「１」だけ減少させる。
［ステップＳ１３６］ジョブ制御部１５０は、パラメータ記憶部１１０内の同時実行ジョブ数カウンタ１１４の値を「１」だけ減少させる。

［ステップＳ１３７］ジョブ制御部１５０は、待機中のスレッドの待機状態を解除する。例えばジョブ制御部１５０は、待機状態となっているスレッドのうちの、重いジョブを投入するスレッドについて、コネクション割り当て要求の送信時刻が最も古いスレッドから順に待機状態を解除する。またジョブ制御部１５０は、軽いジョブ用のジョブ制御部１６０に対して、コネクションが返却されたことを通知する。するとジョブ制御部１６０は、例えば、待機状態となっているスレッドのうちの、軽いジョブを投入するスレッドについて、コネクション割り当て要求の送信時刻が最も古いスレッドから順に待機状態を解除する。コネクション割り当て要求の送信時刻が最も古いスレッドから順に待機状態を解除することで、コネクション割り当て要求を先に送信したスレッドに、優先的にコネクションが割り当てられる。

次に、軽いジョブ用のジョブ制御部１６０におけるジョブ数制御処理について説明する。
図１８は、軽いジョブ数制御処理の手順の一例を示すフローチャートの前半である。以下、図１８に示す処理をステップ番号に沿って説明する。なお、軽いジョブ数制御処理は、アプリケーション１４３，１４４内のスレッドが、ジョブ制御部１６０にコネクション割り当て要求を送信したときに実行される。以下、スレッド１４３ａがコネクション割り当て要求を送信したものとして、軽いジョブ数制御処理を説明する。

［ステップＳ１４１］ジョブ制御部１６０は、ジョブ実行の優先度制御がＯＮに設定されているか否かを判断する。例えばジョブ制御部１６０は、パラメータ記憶部１１０内の優先度制御フラグ１１１の値が「１」であれば、優先度制御がＯＮであると判断する。ジョブ制御部１６０は、優先度制御がＯＮであれば、処理をステップＳ１４２に進める。またジョブ制御部１６０は、優先度制御がＯＦＦであれば、処理をステップＳ１４６に進める。

［ステップＳ１４２］ジョブ制御部１６０は、優先度制御がＯＮの場合、ＤＢサーバ３００で実行されているジョブの総数（同時実行ジョブ数）が、パラメータ記憶部１１０に設定された最大同時実行ジョブ数Ｎより小さいか否かを判断する。なおジョブ制御部１６０は、パラメータ記憶部１１０内の同時実行ジョブ数カウンタ１１４を参照することで、現在の同時実行ジョブ数を認識する。ジョブ制御部１６０は、同時実行ジョブ数が、最大同時実行ジョブ数Ｎより小さければ、処理をステップＳ１４６に進める。またジョブ制御部１６０は、同時実行ジョブ数が、最大同時実行ジョブ数Ｎ以上であれば、処理をステップＳ１４３に進める。

［ステップＳ１４３］ジョブ制御部１６０は、パラメータ記憶部１１０内の軽いジョブ待ち数カウンタ１１８の値を「１」だけ増加させる。
［ステップＳ１４４］ジョブ制御部１６０は、コネクションプール１５１，１６１のいずれかにコネクションが返却されるまで、スレッド１４３ａを待機させる。

［ステップＳ１４５］ジョブ制御部１６０は、コネクションが返却されスレッド１４３ａの待機状態が解除されると、パラメータ記憶部１１０内の軽いジョブ待ち数カウンタ１１８の値を「１」だけ減少させる。その後、ジョブ制御部１６０は処理をステップＳ１４１に進める。

［ステップＳ１４６］ジョブ制御部１６０は、パラメータ記憶部１１０内の同時実行ジョブ数カウンタ１１４の値を「１」だけ増加させる。
［ステップＳ１４７］ジョブ制御部１６０は、パラメータ記憶部１１０内の軽いジョブ実行数カウンタ１１６の値を「１」だけ増加させる。

［ステップＳ１４８］ジョブ制御部１６０は、軽いジョブ用のコネクションプール１６１から１つのコネクションを獲得し、獲得したコネクションをスレッド１４３ａに割り当てる。その後、ジョブ制御部１６０は処理をステップＳ１５１（図１９参照）に進める。

図１９は、軽いジョブ数制御処理の手順の一例を示すフローチャートの後半である。以下、図１９に示す処理をステップ番号に沿って説明する。
［ステップＳ１５１］ジョブ制御部１６０からコネクションの割り当てを受けたスレッド１４３ａは、投入するジョブがあるか否かを判断する。スレッド１４３ａは、投入するジョブがあれば、処理をステップＳ１５２に進める。またスレッド１４３ａは、投入するジョブがなければ、処理をステップＳ１５４に進める。

［ステップＳ１５２］スレッド１４３ａは、割り当てられたコネクションを使用して、ＤＢサーバ３００に対してジョブを投入する。
［ステップＳ１５３］スレッド１４３ａは、ＤＢサーバ３００から、ステップＳ１５２で投入したジョブの完了応答を受信する。その後、スレッド１４３ａは、処理をステップＳ１５１に進める。

［ステップＳ１５４］スレッド１４３ａは、ジョブの投入に使用したコネクションを、コネクションプール１６１に返却する。例えばスレッド１４３ａは、ジョブ制御部１６０へ、コネクション返却通知を送信する。するとジョブ制御部１６０は、スレッド１４３ａに割り当てられていたコネクションを解放する。

［ステップＳ１５５］ジョブ制御部１６０は、パラメータ記憶部１１０内の軽いジョブ実行数カウンタ１１６の値を「１」だけ減少させる。
［ステップＳ１５６］ジョブ制御部１６０は、パラメータ記憶部１１０内の同時実行ジョブ数カウンタ１１４の値を「１」だけ減少させる。

［ステップＳ１５７］ジョブ制御部１６０は、待機中のスレッドの待機状態を解除する。例えばジョブ制御部１６０は、待機状態となっているスレッドのうちの、軽いジョブを投入するスレッドについて、コネクション割り当て要求の送信時刻が最も古いスレッドから順に待機状態を解除する。例えばジョブ制御部１６０は、重いジョブ用のジョブ制御部１５０に対して、コネクションが返却されたことを通知する。するとジョブ制御部１５０は、例えば、待機状態となっているスレッドのうちの、重いジョブを投入するスレッドについて、コネクション割り当て要求の送信時刻が最も古いスレッドから順に待機状態を解除する。

以上のように、第２の実施の形態では、ＤＢサーバ３００に投入したジョブの数に基づいて、ジョブ実行の優先度の動的制御を行っている。これは、他の階層における飽和しつつある資源の状態を、待ち行列の長さから判断するのではなく、同時実行ジョブ数の増減から判断していることになる。こうすることによって、ＤＢサーバ３００の処理能力が飽和し始めた後、完全に飽和する直前のタイミングを判断できる。そのため、軽いジョブの応答時間が、重いジョブの影響で長期化する前に、軽いジョブの優先実行に移行させることが可能となる。

このように、軽いジョブを優先的に実行させれば、平均応答時間が短くなる。その結果、下位の階層のサーバでの資源枯渇の影響が、上位の階層のサーバに伝搬することが抑止され、端末装置に対する応答時間の乱高下が抑止される。

図２０は、ジョブの優先度制御を行った場合の応答時間の変化の一例を示す図である。図２０のグラフは、横軸に時間進行を示し、縦軸に応答時間を示している。応答時間は、細かい時間粒度（例えば０．１秒）ごとの平均応答時間である。図２０に示したグラフを、図３に示したジョブの優先度制御を行わない場合のグラフと比較すると、応答時間の最大値が低くなっているのが分かる。すなわち、応答時間の乱高下が抑止されている。

なお第２の実施の形態では、軽いジョブの実行数が閾値α以上の間、軽いジョブが優先的にＤＢサーバ３００に投入される。ここで、軽いジョブだけが一時的に集中して投入され、処理能力が完全に飽和するまで余裕がある段階で、軽いジョブの同時実行ジョブ数が閾値αを超えることも考えられる。この場合、軽いジョブを優先的に実行しても、軽いジョブは完了するまでの時間が短いので、すぐにその状態が解消される。その結果、重いジョブの実行が待たされることによる応答時間への悪影響は軽微である。

また第２の実施の形態では、Ａｐｐサーバ１００と同様のジョブ数制御機能が、ジョブを下位の階層に投入する全ての階層のサーバに実装される。各サーバでは、普段はジョブ実行の優先度制御は無効（ＯＦＦ）に設定される。そして、分析サーバ４００が、ある階層のサーバの処理能力が部分的に飽和していることを検出した場合に、そのサーバへジョブを送っている上位の階層のサーバに、優先度制御をＯＮにすることを指示する信号を送信する。これにより、部分飽和状態の階層の上位の階層のサーバにおいて、ジョブ実行の優先度制御がＯＮに切り替わる。このようにして、ＤＢサーバ３００以外の階層のサーバで処理能力が飽和状態となった場合でも、上位の階層のサーバにおいて、適切なジョブの優先度制御を行うことができる。

また、分析サーバ４００は、ある階層のサーバの処理能力が完全飽和になったことを検出した場合は、そのサーバの上位の階層のサーバに、優先度制御をＯＦＦにすることを指示する信号を送信する。これにより、その信号を受信したサーバのジョブ実行の優先度制御がＯＦＦに切り替わる。処理能力が完全飽和となったときに優先度制御を停止するようにしたのは以下の理由による。

完全飽和の状態では、ジョブ実行の優先度制御を行っても、応答時間の乱高下を抑止する十分な効果が期待できない。他方、下位の階層のサーバが完全に飽和している状態で軽いジョブを優先的に投入し続けると、重いジョブが投入できず、ジョブ間で実行順序の不公平が過大となる。そこで第２の実施の形態では、処理能力が完全飽和となったときに優先度制御を停止するようにし、応答時間の乱高下を抑止する効果が期待できない状況下では、各ジョブの投入順に従ってジョブを実行し、ジョブ実行の公平性を担保するようにしている。

なお、重いジョブだけが一時的に集中して生成される場合もあり得る。この場合には、軽いジョブのＤＢサーバ３００での同時実行数が閾値α未満であっても、ＤＢサーバ３００は部分飽和状態となり得る。このとき、軽いジョブの実行数が閾値α未満のため、軽いジョブの優先投入は行われないが、ＤＢサーバ３００には重いジョブが大量に投入され、すぐにＤＢサーバ３００が完全飽和状態となってしまう。そのため、重いジョブだけが一時的に集中して生成された場合に、軽いジョブを優先的に投入する必要性はない。

〔第３の実施の形態〕
次に第３の実施の形態について説明する。第３の実施の形態は、優先度制御のＯＮ／ＯＦＦの切り替え判断を、多階層システム内の各サーバが自律的に行うようにしたものである。

図２１は、第３の実施の形態のシステムの全体構成の一例を示す図である。第３の実施の形態は、Ｗｅｂサーバ６００、Ａｐｐサーバ５００、およびＤＢサーバ７００によるＷｅｂ３階層システムが設けられている。このＷｅｂ３階層システムにより、Ｗｅｂサーバ６００にネットワーク１０を介して接続された端末装置２９ａ，２９ｂ，・・・を使用するユーザにサービスを提供する。

図２１に示すように、第３の実施の形態では、第２の実施の形態における分析サーバ４００に相当する装置がない。すなわち第２の実施の形態では、サーバのジョブ実行の優先度制御をＯＮ／ＯＦＦするために、そのサーバのジョブの投入先の階層のサーバが部分的飽和状態になっているかどうかを検出するための分析サーバ４００が設けられている。一方、第３の実施の形態では、ジョブ実行の優先度制御のＯＮ／ＯＦＦをＷｅｂ３階層システムを構成する各サーバが自律的に判断するため、分析サーバ４００は不要となっている。これにより、システム構成の簡略化が可能となる。

外部からのジョブ実行の優先度制御のＯＮ／ＯＦＦの指示を不要とする手法の１つとしては、ジョブ実行の優先度制御を常にＯＮにしておくことが考えられる。ただしジョブ実行の優先度制御が常にＯＮだと、下位の階層のサーバが完全飽和状態に達したときに、軽いジョブだけが実行されて、重いジョブの待ち時間がどんどん増加していってしまう。そこで第３の実施の形態では、重いジョブ用のジョブ制御部１５０におけるジョブの待ち時間が、一定程度まで長くなったら、２つのジョブ制御部１５０，１６０におけるジョブ実行の優先度制御をＯＦＦにする。それ以外の場合は、ジョブ実行の優先度制御はＯＮのままとする。これにより、下位の階層のサーバが完全飽和状態に達した場合には、重いジョブ用のジョブ制御部１５０を経由したジョブの実行を再開することができる。

すなわち、第３の実施の形態は、少なくとも以下の点で第２の実施の形態と異なる。
・第１の相違点：外部の部分的飽和検出器からの情報を得ずに各階層が自律的に動作するので、全く飽和に達していない状態でもジョブ実行の優先度制御を機能させる。
・第２の相違点：下位の階層のサーバが完全飽和状態に達したことが、重いジョブ用のジョブ制御部１５０におけるジョブの待ち時間で判断される。

このような２つの相違点のうち特に第１の相違点によって、低負荷な状態で、瞬間的に軽いジョブだけが多数同時に到着した場合でも、ジョブ実行の優先度制御が機能してしまう。すると、結果的にシステム全体の性能（スループット（単位時間当たりの処理能力）、応答時間の両面）を低下させてしまう可能性が存在する。ただし、軽いジョブの同時実行数が閾値α以上となるまでは重いジョブも実行されるため、低負荷な状態にも拘わらず重いジョブの実行が抑止されるのは稀であると考えられる。そのため全く飽和に達していない状態でもジョブ実行の優先度制御を機能させることとしても、それによるシステム全体の性能低下は無視できるほど軽微になると期待することができる。

なお、第２の実施の形態では、最大同時実行ジョブ数Ｎが、分析サーバ４００から通知されているが、第３の実施の形態では、最大同時実行ジョブ数Ｎは、予め管理者によって各サーバに設定されているものとする。

以下、第３の実施の形態では、重いジョブ用のジョブ制御部１５０における第２の実施の形態との相違点を詳細に説明する。
図２２は、第３の実施の形態におけるＡｐｐサーバの機能の一例を示す図である。Ａｐｐサーバ５００は、パラメータ記憶部５１０、閾値算出部５３０、複数のアプリケーション５４１〜５４４、および２つのジョブ制御部５５０，５６０を有している。ジョブ制御部５５０が重いジョブ用であり、ジョブ制御部５６０が軽いジョブ用である。ジョブ制御部５５０は、重いジョブを実行するスレッドに割り当てるコネクションプール５５１を有している。またジョブ制御部５６０は、軽いジョブを実行するスレッドに割り当てるコネクションプール５６１を有している。図２２に示した要素のうち、ジョブ制御部５５０，５６０以外の各要素は、図９に示した第２の実施の形態の同名の要素と同じ機能を有している。また、軽いジョブ用のジョブ制御部５６０は、図９に示した第２の実施の形態の軽いジョブ用のジョブ制御部１６０と同様の機能を有している。

なおパラメータ記憶部５１０には、第２の実施の形態におけるパラメータ記憶部１１０に格納されるパラメータに加え、重いジョブの待ち時間に関する２つの閾値が格納される。

図２３は、第３の実施の形態のパラメータ記憶部のデータ構造の一例を示す図である。パラメータ記憶部５１０には、優先度制御フラグ５１１、最大同時実行ジョブ数５１２、閾値５１３、同時実行ジョブ数カウンタ５１４、重いジョブ実行数カウンタ５１５、軽いジョブ実行数カウンタ５１６、重いジョブ待ち数カウンタ５１７、軽いジョブ待ち数カウンタ５１８、第１の実行時間閾値５１９ａ、および第２の実行時間閾値５１９ｂが格納されている。第１の実行時間閾値５１９ａと第２の実行時間閾値５１９ｂ以外の各パラメータは、図１０に示した第２の実施の形態の同名のパラメータと同種のパラメータである。

第１の実行時間閾値５１９ａは、ジョブ実行の優先度制御の状態をＯＦＦからＯＮに切り替える際に用いられる、重いジョブの待ち時間の閾値である。重いジョブの待ち時間が第１の実行時間閾値５１９ａに設定された値（β₁）未満となると、優先度制御がＯＮに変更される。

第２の実行時間閾値５１９ｂは、ジョブ実行の優先度制御の状態をＯＮからＯＦＦに切り替える際に用いられる、重いジョブの待ち時間の閾値である。重いジョブの待ち時間が第２の実行時間閾値５１９ｂに設定された値（β₂）を超えると、優先度制御がＯＦＦに変更される。

重いジョブ用のジョブ制御部５５０は、図９に示した第２の実施の形態の重いジョブ用のジョブ制御部１５０と同じ機能に加え、優先度制御のＯＮ／ＯＦＦを切り替える機能を有する。

このような構成の第３の実施の形態では、システムの管理者は、階層のサーバが低負荷のときには、ジョブ実行の優先度制御をＯＮにしておく。例えば管理者は、各サーバのシステムの起動時の初期値として、ジョブ実行の優先度制御をＯＮに設定しておく。その後、下位の階層のサーバの負荷状況に応じて、優先度制御のＯＮ／ＯＦＦの切り替えが行われる。

優先度制御のＯＦＦへの切り替え方は以下の通りである。
重いジョブ用のジョブ制御部５５０におけるジョブの待ち時間が、予め定めた第２の実行時間閾値β₂を超えたら、ジョブ実行の優先度の制御をＯＦＦにして、重いジョブの実行を開始する。

優先度制御のＯＮへの戻し方は以下の通りである。
重いジョブ用のジョブ制御部５５０におけるジョブの待ち時間が、予め定めた一定の閾値β₁（β₁≦β₂）を下回ったら、ジョブ実行優先度の制御を再度ＯＮにする。

第３の実施の形態では、優先度制御のＯＮ／ＯＦＦの切り替えを、重いジョブの実行が終了したときに行う。以下、このような切り替えを実現するための処理手順について説明する。なお、第３の実施の形態における重いジョブ数制御処理の前半は、図１６に示した処理と同様である。そこで、重いジョブ数制御処理の後半を、図２４を参照して説明する。

図２４は、第３の実施の形態における重いジョブ数制御処理の手順の一例を示すフローチャートの後半である。なお第２の実施の形態と同様の処理については図１７と同様のステップ番号を付し、説明を省略する。第２の実施の形態と異なる処理は、ステップＳ２１０である。

［ステップＳ２１０］ジョブ制御部５５０は、待機中のスレッドの待機状態を解除後、優先度制御ＯＮ／ＯＦＦ切り替え処理を実行する。優先度制御ＯＮ／ＯＦＦ切り替え処理完了後、ジョブ制御部５５０は、重いジョブ数制御処理を終了する。

図２５は、優先度制御ＯＮ／ＯＦＦ切り替え処理の手順の一例を示すフローチャートである。以下、図２５に示す処理をステップ番号に沿って説明する。
［ステップＳ２１１］ジョブ制御部５５０は、優先度制御の状態がＯＮか否かを判断する。例えばジョブ制御部５５０は、パラメータ記憶部５１０に設定されている優先度制御フラグの値が「１」であれば、優先度制御がＯＮであると判断する。ジョブ制御部５５０は、優先度制御がＯＮであれば、処理をステップＳ２１２に進める。またジョブ制御部５５０は、優先度制御がＯＦＦであれば、処理をステップＳ２１４に進める。

［ステップＳ２１２］ジョブ制御部５５０は、コネクション待機待ちの時間を含む、重いジョブの実行に要した時間が、第２の実行時間閾値（β₂）を超えているか否かを判断する。ジョブ制御部５５０は、ジョブの実行に要した時間が第２の実行時間閾値（β₂）を超えている場合、処理をステップＳ２１３に進める。またジョブ制御部５５０は、ジョブの実行に要した時間が第２の実行時間閾値（β₂）以下であれば、優先度制御ＯＮ／ＯＦＦ切り替え処理を終了する。

［ステップＳ２１３］ジョブ制御部５５０は、ジョブ実行の優先度制御の状態をＯＦＦに変更する。例えばジョブ制御部５５０は、パラメータ記憶部５１０内の優先度制御フラグ５１１の値を「０」に変更する。その後、ジョブ制御部５５０は、優先度制御ＯＮ／ＯＦＦ切り替え処理を終了する。

［ステップＳ２１４］優先度制御がＯＦＦの場合、コネクション待機待ちの時間を含む、重いジョブの実行に要した時間が、第１の実行時間閾値（β₁）未満か否かを判断する。ジョブ制御部５５０は、ジョブの実行に要した時間が第１の実行時間閾値（β₁）未満であれば、処理をステップＳ２１５に進める。またジョブ制御部５５０は、ジョブの実行に要した時間が第１の実行時間閾値（β₁）以上であれば、優先度制御ＯＮ／ＯＦＦ切り替え処理を終了する。

［ステップＳ２１５］ジョブ制御部５５０は、ジョブ実行の優先度制御の状態をＯＮに変更する。例えばジョブ制御部５５０は、パラメータ記憶部５１０内の優先度制御フラグ５１１の値を「１」に変更する。その後、ジョブ制御部５５０は、優先度制御ＯＮ／ＯＦＦ切り替え処理を終了する。

このようにして、各サーバが自律的にジョブ実行の優先度制御のＯＮ／ＯＦＦを適切に切り替えることができる。なお、この優先度制御のＯＮ／ＯＦＦの切り替えについては、他の方法も考えられる。例えば、以下のような切り替え方がある。

優先度制御のＯＦＦへの切り替え方の他の例は以下の通りである。
重いジョブ用のジョブ制御部５５０は、重いジョブの待ち時間が、予め定めた一定の閾値γを予め定めた一定回数連続で上回り続けたら、もしくは予め定めた一定時間の間連続で上回り続けたら、ジョブ実行の優先度制御をＯＦＦにする。

優先度制御をＯＮへの戻し方の他の例は以下の通りである。
重いジョブ用のジョブ制御部５５０は、重いジョブの待ち時間が、予め定めた一定の閾値γを予め定めた一定回数連続で下回ったら、もしくは予め定めた一定時間の間連続で下回り続けたら、ジョブ実行の優先度制御をＯＮにする。

このように、重いジョブの待ち時間、または待ち時間を含む実行時間を用いて、下位の階層のサーバの負荷の状況を判断し、上位の階層のサーバが自律的にジョブ実行の優先度制御のＯＮ／ＯＦＦを適切に切り替えることができる。

〔第４の実施の形態〕
次に第４の実施の形態について説明する。第４の実施の形態は、ジョブ制御部の数を、３つ以上へ拡張したものである。

ジョブ制御部の数は２つに限らず、ｎ個（ｎは３以上の整数）にすることが可能である。その場合、第２の実施の形態に閾値αに代えて、ｎ−１個の閾値α₁，α₂，・・・，α_n-1（０＜α₁＜α₂＜・・・＜α_n-1＜Ｎ）が用いられる。これらの閾値を用いて、ジョブ実行の優先度はｎ段階に分けて制御される。こうすることによって、ジョブの種別によるジョブ処理時間に大きく差があって、２つのグループでは効果的なジョブ実行優先度制御が行えない場合にも、きめ細かく対応することが可能となる。

以下、図７に示した第２の実施の形態のシステムのうち、Ａｐｐサーバにおけるジョブ制御部の数を３つ以上にした場合を想定し、第４の実施の形態について詳細に説明する。
図２６は、第４の実施の形態におけるＡｐｐサーバの機能の一例を示す図である。Ａｐｐサーバ８００は、パラメータ記憶部８１０、状態設定部８２０、閾値算出部８３０、複数のアプリケーション８４１−１，８４１−２，・・・，８４２−１，８４２−２，・・・，８４ｎ−１，８４ｎ−２，・・・、および複数のジョブ制御部８５１，８５２，・・・，８５ｎを有している。ジョブ制御部８５１，８５２，・・・，８５ｎは、それぞれコネクションプール８５１ａ，８５２ａ，・・・，８５ｎａを管理している。

ジョブ制御部８５１，８５２，・・・，８５ｎには、識別番号ｋ（ｋは１以上ｎ以下の整数）が付与されている。ジョブ制御部８５１，８５２，・・・，８５ｎは、１または複数のアプリケーションが属するアプリケーション集合からのコネクション割り当て要求の送信先に指定されている。このとき、識別番号の値が小さいジョブ制御部ほど、軽いジョブを投入するアプリケーション集合からのコネクション割り当て要求の送信先に指定される。図２６の例では、ジョブ制御部８５１の識別番号ｋの値が「１」である。この場合、ジョブ制御部８５１は、最も軽いジョブを投入するアプリケーション集合からのコネクション割り当て要求の送信先に指定される。またジョブ制御部８５ｎは、最も重いジョブを投入するアプリケーション集合からのコネクション割り当て要求の送信先に指定される。

以下、ｋ＝ｉのジョブ制御部を、ｉ番目のジョブ制御部と呼ぶ。またｉ番目のジョブ制御部にジョブの処理要求を送信するアプリケーションが、ＤＢサーバ３００に投入するジョブを、ｉ番目のジョブ種のジョブと呼ぶ。

図２６の例では、アプリケーション８４１−１，８４１−２，・・・は、コネクション割り当て要求の送信先としてジョブ制御部８５１が指定されている。アプリケーション８４１−１，８４１−２，・・・のスレッドは、ジョブ制御部８５１からコネクションの割り当てを受け、割り当てられたコネクションを用いてＤＢサーバ３００にジョブを投入する。

アプリケーション８４２−１，８４２−２，・・・は、コネクション割り当て要求の送信先としてジョブ制御部８５２が指定されている。アプリケーション８４２−１，８４２−２，・・・のスレッドは、ジョブ制御部８５２からコネクションの割り当てを受け、割り当てられたコネクションを用いてＤＢサーバ３００にジョブを投入する。

アプリケーション８４ｎ−１，８４ｎ−２，・・・は、コネクション割り当て要求の送信先としてジョブ制御部８５ｎが指定されている。アプリケーション８４ｎ−１，８４ｎ−２，・・・のスレッドは、ジョブ制御部８５ｎからコネクションの割り当てを受け、割り当てられたコネクションを用いてＤＢサーバ３００にジョブを投入する。

次に、第４の実施の形態におけるパラメータ記憶部８１０のデータ構造について説明する。
図２７は、第４の実施の形態のパラメータ記憶部のデータ構造の一例を示す図である。パラメータ記憶部８１０には、優先度制御フラグ８１１、最大同時実行ジョブ数８１２、複数の閾値８１３ａ，８１３ｂ，・・・、同時実行ジョブ数カウンタ８１４、複数のジョブ実行数カウンタ８１５ａ，８１５ｂ，・・・、および複数のジョブ待ち数カウンタ８１６ａ，８１６ｂ，・・・が格納されている。優先度制御フラグ８１１、最大同時実行ジョブ数８１２、および同時実行ジョブ数カウンタ８１４は、図１０に示した第２の実施の形態の同名のパラメータと同種のパラメータである。

複数の閾値８１３ａ，８１３ｂ，・・・は、ｎ−１個の閾値α₁，α₂，・・・，α_n-1である。
ジョブ実行数カウンタ８１５ａ，８１５ｂ，・・・は、それぞれジョブ制御部８５１，８５２，・・・，８５ｎに１対１で対応付けられている。ジョブ実行数カウンタ８１５ａ，８１５ｂ，・・・は、対応付けられたジョブ制御部がＤＢサーバ３００に投入し、実行中のジョブの数を示す。

ジョブ待ち数カウンタ８１６ａ，８１６ｂ，・・・は、それぞれジョブ制御部８５１，８５２，・・・，８５ｎに１対１で対応付けられている。ジョブ待ち数カウンタ８１６ａ，８１６ｂ，・・・は、対応付けられたジョブ制御部の待ち行列において実行待ちのジョブ数を示す。

次に、ｉ番目（ｋ＝ｉ）のジョブ制御部がジョブ数制御処理を行う場合を例にとって、第４の実施の形態におけるジョブ数制御処理を詳細に説明する。
図２８は、第４の実施の形態のジョブ数制御処理の手順の一例を示すフローチャートの前半である。以下、図２８に示す処理をステップ番号に沿って説明する。なおｉ番目のジョブ制御部は、対応するアプリケーション内のスレッドが、ｉ番目のジョブ制御部にコネクション割り当て要求を送信したときに、ジョブ数制御処理を実行する。

［ステップＳ３１１］ｉ番目のジョブ制御部は、ジョブ実行の優先度制御がＯＮに設定されているか否かを判断する。ｉ番目のジョブ制御部は、優先度制御がＯＮであれば、処理をステップＳ３１２に進める。またｉ番目のジョブ制御部は、優先度制御がＯＦＦであれば、処理をステップＳ３２０に進める。

［ステップＳ３１２］ｉ番目のジョブ制御部は、優先度制御がＯＮの場合、ＤＢサーバ３００で実行されているジョブの総数（同時実行ジョブ数）が、パラメータ記憶部８１０に設定された最大同時実行ジョブ数Ｎより小さいか否かを判断する。なおｉ番目のジョブ制御部は、パラメータ記憶部８１０内の同時実行ジョブ数カウンタ８１４を参照することで、現在の同時実行ジョブ数を認識する。ｉ番目のジョブ制御部は、同時実行ジョブ数が、最大同時実行ジョブ数Ｎより小さければ、処理をステップＳ３１３に進める。またｉ番目のジョブ制御部は、同時実行ジョブ数が、最大同時実行ジョブ数Ｎ以上であれば、処理をステップＳ３１７に進める。

［ステップＳ３１３］ｉ番目のジョブ制御部は、変数ｊを１からｉ−１まで１ずつカウントアップし、ｊの値ごとにステップＳ３１４，Ｓ３１５の処理を実行する。
［ステップＳ３１４］ｉ番目のジョブ制御部は、ｋ＝１からｋ＝ｊまでの実行ジョブ数の合計値が、閾値α_jより小さいか否かを判断する。例えばｉ番目のジョブ制御部は、パラメータ記憶部８１０内のｋ＝１，２，・・・，ｊ用のジョブ実行数カウンタそれぞれの値を合計する。そしてｉ番目のジョブ制御部は、合計値を、ｊ番目の閾値α_jと比較して、実行ジョブ数の合計値が閾値α_jより小さいか否かを判断する。ｉ番目のジョブ制御部は、実行ジョブ数の合計値が閾値α_jより小さい場合、処理をステップＳ３１６に進める。またｉ番目のジョブ制御部は、実行ジョブ数の合計値が閾値α_j以上の場合、処理をステップＳ３１５に進める。

［ステップＳ３１５］ｉ番目のジョブ制御部は、ｋ＝１からｋ＝ｊまでのジョブ制御部のいずれかに処理待ちのジョブが少なくとも１つ存在するか否かを判断する。例えばｉ番目のジョブ制御部は、パラメータ記憶部８１０内のｋ＝１，２，・・・，ｊ用のジョブ実行数カウンタの少なくとも１つに、１以上の値が設定されていれば、処理待ちのジョブがあると判断する。ｉ番目のジョブ制御部は、処理待ちのジョブがある場合、ステップＳ３１３〜Ｓ３１６のループを抜けて、処理をステップＳ３１７に進める。またｉ番目のジョブ制御部は、処理待ちのジョブがなければ、処理をステップＳ３１６に進める。

［ステップＳ３１６］ｉ番目のジョブ制御部は、変数ｊを１からｉ−１までの各値について、ステップＳ３１４，Ｓ３１５の処理が完了し、ステップＳ３１５でＹＥＳと判断されることがなかった場合、ループを抜け、処理をステップＳ３２０に進める。

［ステップＳ３１７］同時実行ジョブ数が最大同時実行ジョブ数Ｎ以上であるか、またはステップＳ３１５でＹＥＳと判断された場合、ｉ番目のジョブ制御部は、パラメータ記憶部８１０内のｋ＝ｉ用のジョブ待ち数カウンタの値を「１」だけ増加させる。

［ステップＳ３１８］ｉ番目のジョブ制御部は、いずれかのコネクションプールにコネクションが返却されるまで、アプリケーション８４ｉ−１内のコネクション割り当て要求を送信したスレッドを待機させる。

［ステップＳ３１９］ｉ番目のジョブ制御部は、コネクションが返却されスレッドの待機状態が解除されると、パラメータ記憶部８１０内のｋ＝ｉ用のジョブ待ち数カウンタの値を「１」だけ減少させる。その後、ｉ番目のジョブ制御部は処理をステップＳ３１１に進める。

［ステップＳ３２０］ステップＳ３１５でＹＥＳとならずにステップＳ３１３からＳ３１６のループを抜けた場合、ｉ番目のジョブ制御部は、パラメータ記憶部８１０内の同時実行ジョブ数カウンタ８１４の値を「１」だけ増加させる。

［ステップＳ３２１］ｉ番目のジョブ制御部は、パラメータ記憶部８１０内のｋ＝ｉ用のジョブ実行数カウンタの値を「１」だけ増加させる。
［ステップＳ３２２］ｉ番目のジョブ制御部は、ｋ＝ｉ用のコネクションプールから１つのコネクションを獲得し、獲得したコネクションを、コネクション割り当て要求を送信したスレッドに割り当てる。その後、ｉ番目のジョブ制御部は処理をステップＳ３３１（図２９参照）に進める。

図２９は、第４の実施の形態のジョブ数制御処理の手順の一例を示すフローチャートの後半である。以下、図２９に示す処理をステップ番号に沿って説明する。
［ステップＳ３３１］ｉ番目のジョブ制御部からコネクションの割り当てを受けたスレッドは、投入するジョブがあるか否かを判断する。スレッドは、投入するジョブがあれば、処理をステップＳ３３２に進める。またスレッドは、投入するジョブがなければ、処理をステップＳ３３４に進める。

［ステップＳ３３２］コネクションの割り当てを受けたスレッドは、割り当てられたコネクションを使用して、ＤＢサーバ３００に対して、ｉ番目のジョブ種のジョブを投入する。

［ステップＳ３３３］コネクションの割り当てを受けたスレッドは、ＤＢサーバ３００から、ステップＳ３３２で投入したジョブの完了応答を受信する。その後、スレッドは、処理をステップＳ３３１に進める。

［ステップＳ３３４］コネクションの割り当てを受けたスレッドは、ジョブの投入に使用したコネクションを、コネクションプールに返却する。例えばスレッドは、ｉ番目のジョブ制御部へ、コネクション返却通知を送信する。するとｉ番目のジョブ制御部は、そのスレッドに割り当てられていたコネクションを解放する。

［ステップＳ３３５］ｉ番目のジョブ制御部は、パラメータ記憶部８１０内のｋ＝ｉ用のジョブ実行数カウンタの値を「１」だけ減少させる。
［ステップＳ３３６］ｉ番目のジョブ制御部は、パラメータ記憶部８１０内の同時実行ジョブ数カウンタ８１４の値を「１」だけ減少させる。

［ステップＳ３３７］ｉ番目のジョブ制御部は、待機中のスレッドの待機状態を解除する。
このように第４の実施の形態では、優先度制御がＯＮの間は、ｉ番目のジョブ種のジョブをＤＢサーバ３００に投入させるかどうかについて、以下の３つの条件に基づいて判断される。
・第１の条件：すべてのジョブ種に関する同時実行ジョブ数が最大同時実行ジョブ数Ｎより小さいこと（ステップＳ３１２の条件）。
・第２の条件：ｊ＝１，２，・・・，ｉ−１の値をとるすべてのｊについて、１番目からｊ番目までの各ジョブ種の実行ジョブ数の合計が閾値α_jより小さいこと（ステップＳ３１４の条件）。
・第３の条件：１番目からｉ−１番目のいずれかのジョブ種の処理待ちのジョブが存在しないこと（ステップＳ３１５の条件）。

第１の条件と第２の条件を共に満たした場合、または第１の条件と第３の条件を共に満たした場合に、ｉ番目のジョブ種のジョブをＤＢサーバ３００に投入するスレッドにコネクションが割り当てられる。そしてｉ番目のジョブ種のジョブがＤＢサーバ３００に投入される。

第１の条件を満たさない場合、または第１の条件を満たすが第２の条件と第３の条件とのいずれも満たさない場合には、ジョブの投入は抑止される。
以上のように、第４の実施の形態では、３以上のジョブ制御部を用いて、処理の重さに応じたジョブの実行の優先度を、多段階に分けて管理することができる。

〔その他の実施の形態〕
第２〜第４の実施の形態では、Ｗｅｂ３階層システムの例を用いて説明したが、他の複数階層のコンピュータにシステムにおいても、同様の処理を実行可能である。

以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。

１ 情報処理装置
１ａ−１，１ａ−２，１ａ−３，１ａ−４ 実行手段
１ｂ 決定手段
１ｃ 重いジョブの待ち行列
１ｄ 軽いジョブの待ち行列
１ｅ 算出手段
１ｆ 計数手段
１ｇ 抑止手段
２，４ サーバ
３，５ コネクション

Claims (10)

1. サーバに実行させるジョブが複数のグループに分類され、属するジョブによる前記サーバへの負荷が軽いほど上位となるように、グループが順位付けされており、前記サーバで実行中のジョブのうち、上位から所定数のグループに属するジョブの数を計数する計数手段と、
   前記計数したジョブの数が予め定められた閾値以上であり、前記上位から所定数のグループに属する処理待ちのジョブがある場合、前記上位から所定数のグループ以外のグループに属するジョブの処理要求を抑止対象として、該抑止対象の処理要求の前記サーバへの送信を抑止する抑止手段と、
   を有する情報処理装置。
2. 前記複数のグループそれぞれについて、グループに属するジョブを前記サーバに実行させたときの平均処理時間と、前記サーバに実行させたジョブのうち該グループに属するジョブが占める割合を示す発生比率とを計算し、前記複数のグループそれぞれについての平均処理時間と発生比率とに基づいて前記閾値を算出する算出手段をさらに有することを特徴とする請求項１記載の情報処理装置。
3. 前記算出手段は、グループごとに平均処理時間と発生比率とを乗算し、前記上位から所定数のグループそれぞれの乗算結果の合計を、前記複数のグループすべての乗算結果の合計で除算し、除算結果に、前記サーバに同時に実行させることを許容するジョブ数の最大値を乗算し、該最大値の乗算結果を、前記閾値とすることを特徴とする請求項２記載の情報処理装置。
4. ジョブの種別ごとに、前記サーバに実行させたときの平均処理時間を計算し、平均処理時間が短い種別のジョブほど上位のグループとなるように、ジョブが属するグループを決定する決定手段をさらに有することを特徴とする請求項１乃至３のいずれかに記載の情報処理装置。
5. 前記決定手段は、ジョブの種別ごとに、該種別のジョブを前記サーバに実行させたときの平均処理時間と、前記サーバに実行させたジョブのうち該種別のジョブが占める割合を示す発生比率とを計算し、種別ごとにジョブを複数のグループに振り分ける組み合わせパターンを複数生成し、組み合わせパターンごとに、前記上位から所定数のグループ以外のグループに属するジョブの処理要求の抑止による、ジョブの処理時間の短縮率を計算し、最も短縮率が大きくなる組み合わせパターンに従って、ジョブが属するグループを決定することを特徴とする請求項４記載の情報処理装置。
6. 前記抑止手段は、前記上位から所定数のグループ以外のグループに属するジョブの処理要求の待ち時間が所定の上限値を超えた場合、抑止対象の処理要求の前記サーバへの送信の抑止を停止することを特徴とする請求項１乃至５のいずれかに記載の情報処理装置。
7. 前記抑止手段は、抑止対象の処理要求の前記サーバへの送信の抑止を停止した後、前記上位から所定数のグループ以外のグループに属するジョブの処理要求の待ち時間が所定の下限値を下回った場合、抑止対象の処理要求の前記サーバへの送信の抑止を再開することを特徴とする請求項６記載の情報処理装置。
8. 前記抑止手段は、抑止対象の処理要求のサーバへの送信に使用する、コネクションの割り当てを停止することで、該停止対象の処理要求の前記サーバへの送信を抑止することを特徴とする請求項１乃至７のいずれかに記載の情報処理装置。
9. 情報処理装置に、
   サーバに実行させるジョブが複数のグループに分類され、属するジョブによる前記サーバへの負荷が軽いほど上位となるように、グループが順位付けされており、前記サーバで実行中のジョブのうち、上位から所定数のグループに属するジョブの数を計数し、
   前記計数したジョブの数が予め定められた閾値以上であり、前記上位から所定数のグループに属する処理待ちのジョブがある場合、前記上位から所定数のグループ以外のグループに属するジョブの処理要求を抑止対象として、該抑止対象の処理要求の前記サーバへの送信を抑止する、
   処理を実行させるプログラム。
10. 情報処理装置が、
    サーバに実行させるジョブが複数のグループに分類され、属するジョブによる前記サーバへの負荷が軽い上位となるように、グループが順位付けされており、前記サーバで実行中のジョブのうち、上位から所定数のグループに属するジョブの数を計数し、
    前記計数したジョブの数が予め定められた閾値以上であり、前記上位から所定数のグループに属する処理待ちのジョブがある場合、前記上位から所定数のグループ以外のグループに属するジョブの処理要求を抑止対象として、該抑止対象の処理要求の前記サーバへの送信を抑止する、
    ことを特徴とするジョブ制御方法。

Images