"複数の顧客組織の各々について、応答保証を行う時間帯である保証時間帯と、当該保証時間帯における前記応答保証の内容と、を記憶した記憶手段と、前記複数の顧客組織内の各ユーザからの処理要求に応答してデータ処理を実行するデータ処理システム、の負荷を監視する監視手段と、前記監視手段の監視により前記データ処理システムの高負荷状態が検知されている期間は、当該期間を前記保証時間帯内に含む顧客組織である保証時間内組織についての当該保証時間帯における前記応答保証の内容を満たすよう、当該保証時間内組織内のユーザからの処理要求を、当該期間を前記保証時間帯に含んでいない顧客組織である保証外組織内のユーザからの処理要求よりも優先して前記データ処理システムに実行させる制御を行う制御手段と、を備える処理要求実行管理装置。前記制御手段は、前記各顧客組織内の各ユーザからの処理要求を一時的に保持するキューを備えており、前記データ処理システムの高負荷状態が検知されていない期間は、保証時間内組織及び保証時間外組織のいずれのユーザからの処理要求であるかを区別せずに前記キューの先頭から順に処理要求を前記キューから取り出して前記データ処理システムに実行させると共に、前記データ処理システムの高負荷状態が検知されている期間は、保証時間外組織内のユーザからの処理要求は前記キューから取り出さず、保証時間内組織内のユーザからの処理要求のみを前記キューから取り出して前記データ処理システムに実行させる、ことを特徴とする請求項1に記載の処理要求実行管理装置。前記顧客組織に対応する前記応答保証の内容には、当該顧客組織に割り当てられた最大同時要求処理数が含まれており、前記制御手段は、前記データ処理システムの高負荷状態が検知されている期間において前記保証時間内組織が複数存在する場合に、前記キューからそれら各保証時間内組織の処理要求が取り出される割合が、それら各保証時間内組織に割り当てられた前記最大同時要求処理数同士の比率に応じたものとなるように制御する、ことを特徴とする請求項2に記載の処理要求実行管理装置。処理要求が再実行可能か否かを判定する再実行可否判定手段を更に備え、前記制御手段は、前記データ処理システムの高負荷状態が検知されている期間において、前記データ処理システムが実行中の前記保証外組織内のユーザからの処理要求のうち、前記再実行可否判定手段で再実行可能と判定される処理要求の実行を強制終了するよう前記データ処理システムに指示する、ことを特徴とする請求項1~3のいずれか1項に記載の処理要求実行管理装置。処理要求が、前記データ処理システムによる実行に予め定められた時間以下の時間しか要さない軽負荷タイプであるか否かを判定する要求タイプ判定手段を更に備え、前記監視手段は、前記顧客組織ごとに前記データ処理システムが同時に実行している当該顧客組織からの処理要求のうち軽負荷タイプでないと判定される処理要求の数を同時実行数として監視しており、監視している前記各顧客組織の前記同時実行数に基づいて前記データ処理システムが高負荷状態であるか否かを判定する、ことを特徴とする請求項1~4のいずれか1項に記載の処理要求実行管理装置。コンピュータを、複数の顧客組織の各々について、応答保証を行う時間帯である保証時間帯と、当該保証時間帯における前記応答保証の内容と、を記憶した記憶手段、前記複数の顧客組織内の各ユーザからの処理要求に応答してデータ処理を実行するデータ処理システム、の負荷を監視する監視手段、前記監視手段の監視により前記データ処理システムの高負荷状態が検知されている期間は、当該期間を前記保証時間帯内に含む顧客組織である保証時間内組織についての当該保証時間帯における前記応答保証の内容を満たすよう、当該保証時間内組織内のユーザからの処理要求を、当該期間を前記保証時間帯に含んでいない顧客組織である保証外組織内のユーザからの処理要求よりも優先して前記データ処理システムに実行させる制御を行う制御手段、として機能させるためのプログラム。本発明は、データ処理システムに余力がある場合には応答保証の時間帯の外にある顧客組織内のユーザの処理要求も受け付けつつも、高負荷状態となった場合には応答保証の時間帯内にある顧客組織の応答保証ができるようにすることを目的とする。請求項1に記載の発明は、複数の顧客組織の各々について、応答保証を行う時間帯である保証時間帯と、当該保証時間帯における前記応答保証の内容と、を記憶した記憶手段と、前記複数の顧客組織内の各ユーザからの処理要求に応答してデータ処理を実行するデータ処理システム、の負荷を監視する監視手段と、前記監視手段の監視により前記データ処理システムの高負荷状態が検知されている期間は、当該期間を前記保証時間帯内に含む顧客組織である保証時間内組織についての当該保証時間帯における前記応答保証の内容を満たすよう、当該保証時間内組織内のユーザからの処理要求を、当該期間を前記保証時間帯に含んでいない顧客組織である保証外組織内のユーザからの処理要求よりも優先して前記データ処理システムに実行させる制御を行う制御手段と、を備える処理要求実行管理装置である。請求項2に記載の発明は、前記制御手段は、前記各顧客組織内の各ユーザからの処理要求を一時的に保持するキューを備えており、前記データ処理システムの高負荷状態が検知されていない期間は、保証時間内組織及び保証時間外組織のいずれのユーザからの処理要求であるかを区別せずに前記キューの先頭から順に処理要求を前記キューから取り出して前記データ処理システムに実行させると共に、前記データ処理システムの高負荷状態が検知されている期間は、保証時間外組織内のユーザからの処理要求は前記キューから取り出さず、保証時間内組織内のユーザからの処理要求のみを前記キューから取り出して前記データ処理システムに実行させる、ことを特徴とする請求項1に記載の処理要求実行管理装置である。請求項3に記載の発明は、前記顧客組織に対応する前記応答保証の内容には、当該顧客組織に割り当てられた最大同時要求処理数が含まれており、前記制御手段は、前記データ処理システムの高負荷状態が検知されている期間において前記保証時間内組織が複数存在する場合に、前記キューからそれら各保証時間内組織の処理要求が取り出される割合が、それら各保証時間内組織に割り当てられた前記最大同時要求処理数同士の比率に応じたものとなるように制御する、ことを特徴とする請求項2に記載の処理要求実行管理装置である。請求項4に記載の発明は、処理要求が再実行可能か否かを判定する再実行可否判定手段を更に備え、前記制御手段は、前記データ処理システムの高負荷状態が検知されている期間において、前記データ処理システムが実行中の前記保証外組織内のユーザからの処理要求のうち、前記再実行可否判定手段で再実行可能と判定される処理要求の実行を強制終了するよう前記データ処理システムに指示する、ことを特徴とする請求項1~3のいずれか1項に記載の処理要求実行管理装置である。請求項5に記載の発明は、処理要求が、前記データ処理システムによる実行に予め定められた時間以下の時間しか要さない軽負荷タイプであるか否かを判定する要求タイプ判定手段を更に備え、前記監視手段は、前記顧客組織ごとに前記データ処理システムが同時に実行している当該顧客組織からの処理要求のうち軽負荷タイプでないと判定される処理要求の数を同時実行数として監視しており、監視している前記各顧客組織の前記同時実行数に基づいて前記データ処理システムが高負荷状態であるか否かを判定する、ことを特徴とする請求項1~4のいずれか1項に記載の処理要求実行管理装置である。請求項6に記載の発明は、コンピュータを、複数の顧客組織の各々について、応答保証を行う時間帯である保証時間帯と、当該保証時間帯における前記応答保証の内容と、を記憶した記憶手段、前記複数の顧客組織内の各ユーザからの処理要求に応答してデータ処理を実行するデータ処理システム、の負荷を監視する監視手段、前記監視手段の監視により前記データ処理システムの高負荷状態が検知されている期間は、当該期間を前記保証時間帯内に含む顧客組織である保証時間内組織についての当該保証時間帯における前記応答保証の内容を満たすよう、当該保証時間内組織内のユーザからの処理要求を、当該期間を前記保証時間帯に含んでいない顧客組織である保証外組織内のユーザからの処理要求よりも優先して前記データ処理システムに実行させる制御を行う制御手段、として機能させるためのプログラムである。請求項1又は6に係る発明によれば、データ処理システムが高負荷状態でなければ保証時間外組織内のユーザの処理要求も受け付けつつも、高負荷状態となった場合には保証時間内組織の応答保証の内容を満たすよう制御することができる。請求項2に係る発明によれば、データ処理システムが高負荷状態である間、保証時間外組織の処理要求が実行される数が減っていき、これにより生じたデータ処理システムの処理余力を保証時間内組織の処理要求の処理に振り向けることができる。請求項3に係る発明によれば、最大同時要求処理数が多い保証時間内組織ほど処理要求が実行されやすくし、応答保証が実現されやすくすることができる。請求項4に係る発明によれば、保証時間外組織の処理要求の実行が完了するのを単に待つよりも、データ処理システムの負荷を急速に低減させ、その負荷低減により生じた余力を保証時間内組織の処理要求に振り向けることができる。請求項5に係る発明によれば、処理要求が軽負荷タイプであるか否かの区別をせずに単に同時実行数により高負荷状態であるか否かを判定する方式よりも、高負荷状態の判定をより適切に行うことができる。図1を参照して、本発明に係る処理要求実行管理装置10を備えるASPアプリケーションサービスプロバイダシステムの一実施形態を説明する。このASPシステムは、顧客に対して、インターネット等のデータ通信ネットワークを介してデータ処理サービスを提供するシステムである。ここでは、個々の顧客は企業等の組織図1では、A社、B社などであるとする。ASPシステムは、それら各顧客に所属する個々のユーザのPCパーソナルコンピュータから処理要求を受け、その処理要求に対応するデータ処理を実行する。各顧客及びその顧客に所属する個々のユーザはあらかじめASPシステムの中の例えば処理要求実行管理装置10に登録されている。各顧客に属するユーザは、このシステムにログインし、必要とするアプリケーションを呼び出し、そのアプリケーションによるデータ処理を要求する。ASPシステムは、この処理要求に応じたデータ処理を実行する。このASPシステムは、処理要求実行管理装置10と、サービスレベル登録部20と、データ処理システム30とを備える。データ処理システム30は、顧客に対するアプリケーションサービスのためのデータ処理を実行するシステムであり、複数のデータ処理部32-1,32-2,...32-NNは2以上の整数と、処理用データ保持部34とを備えている。データ処理部32-1,32-2,...32-N以下、区別の必要がない場合はデータ処理部32と総称するは、アプリケーションを実行する個々のコンピュータである。データ処理部32は、必要なアプリケーションを実行することで、ユーザから処理要求に応じた個々のデータ処理を実現する。データ処理部32が実行するアプリケーションには特に限定はない。処理用データ保持部34は、各データ処理部32のデータ処理に用いられるデータを記憶した記憶装置であり、例えばデータベースとして構築されている。処理用データ保持部34は、物理的に単一の装置であってもよいし、複数の装置から構成されていてもよい。各データ処理部32は、ユーザからの処理要求に応じて、必要なデータを処理用データ保持部34から取得し、取得したデータを用いてデータ処理を実行する。また、実行したデータ処理が、処理用データ保持部34内のデータを変更するものであれば、データ処理部32は、そのデータ処理の結果により処理用データ保持部34内のデータを更新する。データ処理部32が実行する処理の流れの具体例を以下に示す。例えば、ある顧客内のユーザが自身のPC上のブラウザからデータ処理部32上のウェブサーバにアクセスし、データベースの検索UIユーザインタフェース画面を要求する処理要求をHTTPリクエストの形で送信すると、データ処理部32はその要求に応じた検索UI画面のウェブページを提供する。また、ユーザがそのUI画面に検索条件を入力して検索の処理要求を発すると、データ処理部32はその処理要求に応じて処理用データ保持部34内の当該顧客のデータベースを検索し、検索結果を表示したウェブページを生成してユーザに返す。また、ユーザがデータベースへの入力フォームに対してデータを入力し、データ入力の要求を発すると、データ処理部32はその入力データにより処理用データ保持部34内の当該顧客のデータベースを更新する。なお、この具体例はあくまで説明のための一例に過ぎず、データ処理部32が実行するアプリケーションの種類やそのアプリケーションに対する処理要求の種類は、上に例示したものに限られない。処理要求実行管理装置10は、各顧客に属する各ユーザからの処理要求を、データ処理システム30内の各データ処理部32-1,32-2,...32-Nに割り振る処理を行う。処理要求実行管理装置10は、処理要求受付部11、処理要求保持部13、処理要求スケジュール部15、サービスレベルデータ保持部17、及び応答時間記録部19を備える。処理要求受付部11は、ネットワークを介して、各顧客図示例ではA,B,C社内のユーザからの処理要求を受け付ける。受け付けた処理要求は、処理要求保持部13に入れられる。処理要求保持部13は、処理要求を保持するキュー待ち行列である。処理要求受付部11が処理要求を受け付けるごとに、新たに受け付けられた処理要求はそのキューの末尾に追加される。処理要求保持部13に保持された処理要求は、次に説明する処理要求スケジュール部15により取り出され、いずれかのデータ処理部32に渡される。取り出された処理要求は、処理要求保持部13から削除される。処理要求スケジュール部15は、処理要求保持部13内のキュー内の処理要求を、データ処理システム30内の各データ処理部32に分配して実行させる。例えば、いずれかのデータ処理部32が次の処理要求を受け入れ可能になると、処理要求スケジュール部15は、処理要求保持部13から処理要求を取り出し、取り出した処理要求をそのデータ処理部32に対して割り当てる。処理要求スケジュール部15は、キュー処理要求保持部13からの処理要求の取り出し方のモードとして、少なくとも通常モードと保証モードと呼ぶ2つのモードを有している。通常モードは、処理要求保持部13のキューの先頭から順に処理要求を取り出すという一般的なFIFO先入れ先出し方式のモードである。保証モードは、顧客に保証したサービスレベルを達成するために、保証対象の顧客からの処理要求を保証対象でない顧客からの処理要求よりも優先してキューから取り出すモードである。一つの例では、すべての顧客に保証したサービスレベルが達成できている状況では、処理要求スケジュール部15は通常モードで動作し、データ処理システム30が高負荷状態となった場合には、処理要求スケジュール部15は保証モードで動作する。なお、高負荷状態とは、少なくとも1つの顧客に保証したサービスレベルが達成されなくなったあるいは達成できなくなりそうになった状態のことである。サービスレベルデータ保持部17には、各顧客に保証したサービスレベルの内容を示すデータが記憶されている。サービスレベルとは、このシステムを運用するプロバイダが各顧客に対して保証するASPサービスの品質の内容である。図2に、サービスレベルデータ保持部17に記憶されるサービスレベルデータの例を示す。この例では、ASPサービスの品質として、最大同時セッション数と目標応答時間の組合せを用いている。ここで、最大同時セッション数は、プロバイダが顧客に保証する同時セッション数の上限値である。なお、同時セッション数は、データ処理システム30が同時に実行する一つの顧客からの処理要求の数である。また、目標応答時間は、ユーザのPCが処理要求を発してから、データ処理部32がその処理要求の実行結果をユーザのPCに返すまでの時間この時間を応答時間と呼ぶの目標上限値である。この実施形態では、処理要求スケジュール部15は、顧客からの処理要求の数が最大同時セッション数に達するまでは、その顧客からの処理要求に対するデータ処理システム30の応答時間が目標応答時間を超えないよう保証すべく、処理要求保持部13内の処理要求の実行順序を制御する。ここで、目標応答時間は、個々の処理要求についての応答時間についてのものであってもよいし、直近のある期間における当該顧客からの処理要求についての応答時間の平均についてものであってもよい。すなわち、処理要求スケジュール部15は、顧客からの個々の処理要求についての応答時間がすべてその顧客の目標応答時間を超えないように制御するものであってもよいし、直近のある期間における当該顧客からの処理要求についての応答時間の平均が目標応答時間を超えないように制御するものであってもよい。処理要求スケジュール部15がこれら2つの方式のうちのいずれの方式で動作するかを選択できるようにしてもよい。また、図2の例では、ASPサービスのレベル応答保証の内容を時間帯ごとに登録している。例えば、顧客企業Aについては、午前9時~午前10時の時間帯に最大セッション数100、目標応答時間5秒という応答保証内容が登録され、顧客企業Cについては、午前8時~午後6時の時間帯に最大同時セッション数30、目標応答時間8秒という応答保証内容が登録されている。一方、顧客企業Bについては、午前11時~正午の時間帯に最大同時セッション数50、目標応答時間5秒という応答保証内容が、午後1時~午後2時の時間帯に最大同時セッション数100、目標応答時間5秒という応答保証内容が登録されている。このように、サービスレベル応答保証内容が登録された時間帯のことを、以下では保証時間帯と呼ぶ。図2の例では、顧客A及びCは保証時間帯を1つだけ登録しており、顧客Bは保証時間帯を2つ登録している。なお、ある顧客の保証時間帯以外の時間帯でも、その顧客内のユーザはデータ処理システム30を利用するすなわちデータ処理システム30に処理要求を送ってデータ処理を実行させることはできる。しかし、サービスレベルの保証は行われない。したがって、ユーザが保証時間帯以外の時間帯にデータ処理システム30を利用していたとしても、保証時間帯内に他の顧客の応答保証が必要となった等の理由で、利用が制限される例えば新たな処理要求が受け付けられなくなることがある。図2に示したサービスレベルデータが示す保証内容を、図3に模式的に示す。保証時間帯の設定がない場合、顧客A、B、Cの最大同時セッション数を満たすには、データ処理システム30は230セッション230の処理要求を同時に実行する処理能力を有する。これに対し、図2のように各顧客の保証時間帯が設定されている場合、データ処理システム30は130セッションを同時に実行する処理能力を持てばよい。すなわち、データ処理システム30は、同一時刻における各顧客の最大同時セッション数の合計値の、全時間帯の中での最大値を同時に処理できる能力を持っていればよい。サービスレベル登録部20は、サービスレベルデータ保持部17に対してサービスレベルデータの登録を行うためのUIである。サービスレベル登録部20は、例えばウェブページの形で処理要求実行管理装置10から顧客内のユーザ例えば顧客内のシステム管理者に提供してもよい。この場合、そのユーザがそのウェブページ内の入力欄に保証時間帯、最大同時セッション数、目標応答時間等を入力し、入力結果を送信することで、サービスレベルデータ保持部17内に当該顧客のサービスレベルの情報が登録される。同様にして、顧客の既登録のサービスレベルデータを更新できるようにしてもよい。また、サービスレベル登録部20をASPシステム内に設け、ASPシステムの職員が顧客からの要請に応じてサービスレベルデータ保持部17へのデータの登録又は更新を行ってもよい。応答時間記録部19は、各顧客の各ユーザが発した処理要求に対するデータ処理システム30の応答時間を計測し、顧客ごとに処理要求の応答時間の実測値を記録する。応答時間記録部19が管理する応答時間の実測値データのデータ構造の一例を図4に示す。図示のように、応答時間記録部19は、顧客ごとに、現在実行しているその顧客の処理要求の数実行中セッション数と、現時点でのその顧客の処理要求についての応答時間の実測値と、をメモリに記憶する。例えば、応答時間記録部19は、処理要求受付部11がある顧客の所属ユーザからの処理要求を受け付けると、その処理要求にID識別情報を付与し、その処理要求IDに対応づけて、その処理要求を発したユーザのIDと、その処理要求の受付時刻を記録する。処理要求スケジュール部15が処理要求保持部13から処理要求を取り出していずれかのデータ処理部32に割り当てると、応答時間記録部19はその処理要求の発行元ユーザの属する顧客の実行中セッション数を1増加させる。処理要求を発したユーザがどの顧客に属するかどうかは、顧客IDとユーザIDの対応関係のデータベースを参照する等の処理により判別すればよい。また、データ処理部32から処理要求の実行が完了した旨の通知その処理要求のIDを含むを受けると、その処理要求を発したユーザの属する顧客の実行中セッション数を1つ減少させる。また、このとき、その処理要求の受付時刻から完了時刻までの時間、すなわちその処理要求についての応答時間、を計算し、その応答時間により当該顧客の応答時間の実測値を更新する。応答時間実測値として、単一の処理要求についての応答時間を用いる場合には、そのとき計算した応答時間を当該顧客の応答時間実測値の値に上書きすればよい。また、応答時間の平均を用いる場合は、例えば過去ある一定の期間の間に実行が完了した処理要求の応答時間を顧客ごとに分類して記憶しておき、新たにある顧客内のユーザからの処理要求の応答時間が計算された場合、その新たに計算された応答時間を考慮して応答時間の平均を更新すればよい。このように、応答時間記録部19は、処理要求保持部13内の処理要求をデータ処理システム30に渡す都度、その処理要求の発行元の顧客の実行中セッション数をインクリメントし、データ処理部32で処理要求の実行が完了する都度、その処理要求の発行元の顧客の実行中セッション数をデクリメントし、応答時間実測値を更新する。このような処理により、各顧客の実行中セッション数及び応答時間実測値が常に最新状況を表すように管理される。処理要求スケジュール部15は、応答時間記録部19が管理する各顧客の実行中セッション数及び応答時間実測値の情報と、サービスレベルデータ保持部17に保持された各顧客のサービスレベルデータとを参照して、処理要求保持部13からの処理要求の取り出しの制御を行う。この取り出し制御には、前述のように少なくとも通常モードと保証モードの2つの動作モードがある。処理要求スケジュール部15は、データ処理システム30が高負荷状態になった場合に、通常モードから保証モードへの切換を行う。一つの例では、保証時間帯内にある顧客のうちの少なくとも1つの目標応答時間が達成されていない又は近いうちに達成できなくなる可能性が高いと判定される場合に、データ処理システム30が高負荷状態となったと判定する。ある顧客の目標応答時間が達成されているか否かは、その顧客の目標応答時間と応答時間実測値とを比較することで判定すればよい。応答時間実測値が目標応答時間よりも長ければ目標応答時間が達成されておらず、応答時間実測値が目標応答時間以下であれば目標応答時間が達成できているということである。また、応答時間実測値が、目標応答時間より少し短く設定した閾値時間よりも長くなった場合に、近いうちに目標応答時間が達成できなくなる可能性が高いと判定し、高負荷状態と判定してもよい。また、応答時間実測値の履歴を記録しておき、その履歴から、このままでは近いうちに応答時間実測値が目標応答時間を超えると判定される場合に、目標応答時間が達成できなくなる可能性が高いと判定し、高負荷状態と判定してもよい。なお、以下では、記載を簡潔にするために、目標応答時間が近いうちに達成できなくなる可能性が高い状態も、目標応答時間が達成されていないという記載で包括して表現することとする。同様に、目標応答時間が近いうちに達成できなくなる可能性が低い状態を、目標応答時間が達成されているという記載で包括して表現することとする。高負荷状態と判定した場合、処理要求スケジュール部15は、サービスレベルデータ保持部17に保持された各顧客の保証時間帯や目標応答時間等の情報と、応答時間記録部19が保持している各顧客の応答時間実測値等の情報とを参照して、高負荷状態か否かを判定する。高負荷状態と判定し、保証モードに移行した場合、処理要求スケジュール部15は、保証時間帯内の顧客以下、保証時間内顧客と呼ぶの処理要求を保証時間帯外の顧客以下、保証時間外顧客と呼ぶの処理要求よりも優先的に処理要求保持部13から取り出し、データ処理システム30に処理させる。また、保証モードでは、同じ保証時間内顧客のうちでも、目標応答時間が達成されていない顧客の処理要求を、目標応答時間が達成されている顧客の処理要求よりも優先して処理要求保持部13から取り出すようにしてもよい。また、保証モードでは、同じ保証時間内顧客のうちでも、実行中セッション数図4参照が最大同時セッション数よりも少ない顧客の処理要求を、そうでない顧客の処理要求よりも優先して処理要求保持部13から取り出すようにしてもよい。保証モードにおける処理要求の実行の優先関係をまとめると以下のようになる。1保証モードのときに最も優先するのは、目標応答時間が達成されておらず、且つ実行中セッション数が最大同時セッション数に達していない保証時間内顧客である。このような顧客の処理要求を優先して処理することで、目標応答時間が達成されやすくするのである。2次に優先するのは、実行中セッション数は最大同時セッション数に達しているが目標応答時間は達成できていない保証時間内顧客である。最大同時セッション数以上の処理要求を現在処理中であるからといって、このような顧客の処理要求を待機させたのでは、応答時間実測値がますます延びることになり、目標応答時間の達成が更に難しくなるからである。3その次に優先するのは、目標応答時間は達成できているが実行中セッション数は最大同時セッション数に達していない保証時間内顧客である。このような顧客は、目標応答時間が達成されているので、処理要求の実行を多少待たせても上記1及び2のケースよりは問題が少ない。したがって、上記1及び2のケースよりは優先度は下がる。しかし、最大同時セッション数までの同時実行は保証しているので、応答時間実測値が目標応答時間を超過してしまうことのないよう、ある程度の優先度で処理要求を実行していく必要はある。4その次に優先するのは、実行中セッション数が最大同時セッション数に達しており、且つ目標応答時間が達成されている保証時間内顧客である。このような顧客は、目標応答時間が達成されているので、処理要求の実行を多少待たせても上記1及び2のケースよりは問題が少ない。また、最大同時セッション数以上の処理要求を現に処理しているので、更に同時実行数を増やす必要もない。したがって、このケースは、上記3のケースよりも優先度が下がる。5優先度が最も低いのは、保証時間外顧客である。保証時間外顧客は、応答保証の時間帯から外れているのだから応答保証の必要がない。そこで、保証モードでは、保証時間外顧客の処理要求を処理要求保持部13から新たに取り出すそしてデータ処理システム30に実行させることはしない。これにより、データ処理システム30の持つ限られた処理能力が、より優先度の高い顧客に振り向けられるようにする。以上、ケース1~5の優先順位を例示したが、システムに実装する場合にこれら5段階のすべてを区別する必要は必ずしもない。例えば、ケース1~4を同じ扱いとするなど後述する図6の例、優先順位が隣り合う複数のケースの取扱を同じレベルとしてもよい。また、優先順位取扱のレベルが同じ顧客が複数存在する場合には、処理要求保持部13からの処理要求の取り出し数のそれら顧客間での比率が、それら顧客の最大同時セッション数の比率と等しくなるよう、処理要求保持部13からの処理要求の取り出しを制御してもよい。以上、処理要求スケジュール部15の制御内容について概説した。次に、その制御の具体例を、図5を参照して説明する。まず、システムの起動時点では、処理要求スケジュール部15の動作モードは通常モードに設定される。処理要求スケジュール部15は、自身の動作モードをデータ処理システム30の最新の状態に合わせて動的に切り換えるために、定期的に図5の処理を繰り返す。図5の手順では、処理要求スケジュール部15は、現在時刻とサービスレベルデータ保持部17に記憶された各顧客の保証時間帯とを比較し、保証時間内顧客自身の保証時間帯内に現在時刻が含まれる顧客を特定するS12。S12で、保証時間内顧客が1つもなければ、動作モードを通常モードとしS14、S12に戻る。また、S12で保証時間内顧客が1つでも見つかれば、応答時間記録部19から各保証時間内顧客の応答時間実測値を取得しS16、取得した応答時間実測値をサービスレベルデータ保持部17内の当該顧客の目標応答時間と比較することで、目標応答時間が達成されていない保証時間内顧客が存在するかどうかを判定するS18。目標応答時間が達成されていない保証時間内顧客が存在しない場合、この例ではデータ処理システム30は高負荷状態ではないと判定し、動作モードを通常モードとしS14、S12に戻る。S18で目標応答時間が達成されていない保証時間内顧客が存在すると判定した場合、処理要求スケジュール部15は、動作モードを保証モードとしS20、S12に戻る。データ処理システム30内の各データ処理部32は、新たな処理要求の処理が可能になる都度、処理要求スケジュール部15に対して、新たな処理要求を割り当てるよう要求する。処理要求スケジュール部15は、データ処理部32から新たな処理要求を要求されると、処理要求スケジュール部15から処理要求を取り出し、要求元のデータ処理部32に供給する。ここで、動作モードが通常モードである場合は、処理要求スケジュール部15は、処理要求保持部13キュー内の順序に従い、その順序の先頭の処理要求を取り出して要求元のデータ処理部32に供給する。一方、動作モードが保証モードである場合の処理要求スケジュール部15の処理手順の一例を図6に示す。この手順では、処理要求スケジュール部15は、データ処理システム30内の各データ処理部32からの割当要求を待ちS22、割当要求が到来すると、制御変数nnは1以上の整数を1に初期化するS24。そして、キュー処理要求保持部13の先頭からn番目の処理要求の発行元の顧客を特定し、サービスレベルデータ保持部17を参照してその顧客が保証時間内顧客であるかどうかを判定するS26。n番目の処理要求の発行元の顧客が保証時間内顧客でなければ、その処理要求は処理要求保持部13から取り出さずに、nを1増加させてS28S26に戻り、キュー内の次の処理要求を検査する。S26で、キュー内のn番目の処理要求が保証時間内顧客のものであると判定した場合、処理要求スケジュール部15は、そのn番目の処理要求を処理要求保持部13から取り出し、割当要求発行元のデータ処理部32に割り当てS30、S22に戻る。図6の処理手順では、キューの先頭からみて最初に見つかる保証時間内顧客上述したケース1~4のいずれかに該当の処理要求が処理要求保持部13から取り出され、処理されることとなる。逆に、保証時間外顧客上述したケース5に該当の処理要求は、処理要求保持部13内に残ったままとなる。このような処理によれば、保証モードの間は、保証時間外顧客の新たな処理要求は実行されないので、現に実行中の保証時間外顧客の各処理要求の処理が時間の経過に伴って完了していくにつれて、データ処理システム30の余力が増大していく。そして、その増大した余力が保証時間内顧客の新たな処理要求に振り向けられることになる。これにより、保証時間内顧客の処理要求の実行が加速され、目標応答時間が達成される方向に推移していく。図6の処理手順では、保証時間内顧客が複数存在する場合、高負荷状態では、それら各保証時間内顧客の処理要求が単純にキュー内の順序に従って処理されていく。これに対し、別の例として、データ処理システム30が高負荷状態にある期間において保証時間内顧客が複数存在する場合、キューからそれら各保証時間内顧客の処理要求が取り出される割合が、それら各保証時間内顧客に割り当てられた最大同時セッション数同士の比率に応じたものとなるように制御してもよい。例えば、キューから取り出す数の比率が最大同時セッション数同士の比率と等しくなるように、各保証時間内顧客の処理要求のキューからの取り出しの間引きを行ってもよい例えば、最大同時セッション数同士の比率よりも実際の取り出し数の比率が高い保証時間内顧客の処理要求はキューからの取り出しの間引き率を高くするなど。次に、図7を参照して、保証モードにおける処理要求スケジュール部15の別の処理手順の例を説明する。この手順では、処理要求スケジュール部15は、データ処理システム30内の各データ処理部32からの割当要求を待ちS22、割当要求が到来すると、制御変数nnは1以上の整数を1に初期化するS24。そして、キュー処理要求保持部13の先頭からn番目の処理要求の発行元の顧客を特定し、サービスレベルデータ保持部17を参照してその顧客が保証時間内顧客であるかどうかを判定するS26。n番目の処理要求の発行元の顧客が保証時間内顧客でなければ、その処理要求は処理要求保持部13から取り出さずに、nを1増加させてS28S26に戻り、キュー内の次の処理要求を検査する。S26で、キュー内のn番目の処理要求が保証時間内顧客のものであると判定した場合、処理要求スケジュール部15は、応答時間記録部19とサービスレベルデータ保持部17を参照して、当該保証時間内顧客の目標応答時間が達成されているかどうかを判定するS32。達成されていない場合は、そのn番目の処理要求を処理要求保持部13から取り出し、割当要求発行元のデータ処理部32に割り当てS30、S22に戻る。S32で、その保証時間内顧客の目標応答時間が達成されていると判定した場合、処理要求スケジュール部15は、更にその保証時間内顧客の実行中セッション数が最大同時セッション数に達しているかを判定するS34。達している場合は、そのn番目の処理要求は処理要求保持部13から取り出さず、nを1増加させてS28、S26に戻る。達していない場合は、そのn番目の処理要求を処理要求保持部13から取り出し、割当要求発行元のデータ処理部32に割り当てS30、S22に戻る。図7の処理手順では、キューの先頭からみて最初に見つかる、上述したケース1~3に該当する顧客の処理要求が処理要求保持部13から取り出され、処理されることとなる。逆に、上述したケース4又は5に該当する顧客の処理要求は、処理要求保持部13内に残ったままとなる。すなわち、この手順では、ケース4又は5に該当する顧客の処理要求を待たせることでデータ処理システム30の負荷を低減し、この負荷低減により生じた余力でケース1~3に該当する顧客の処理要求が早く実行されるようにするのである。以上に説明した図6及び図7の例では、処理要求保持部13内の処理要求を待たせるかどうかの区切りを、図6の手順ではケース5と4の間に置き、図7の手順ではケース4と3の間に置いた。しかし、これらはあくまで一例に過ぎず、例えば別の例としてその区切りをケース3と2の間に設定してもよい。以上の例では、保証モード時の制御は、優先されない顧客の処理要求は処理要求保持部13内で待たせ、優先される顧客の処理要求は先入れ先出し順に実行するという2段階の段階分けであったが、これは一例に過ぎない。別の例として、例えば、優先順位が高いほど、相対的に高い頻度で処理要求が処理要求保持部13内から取り出されるように制御してもよい。この例では、例えば、ケース5保証時間外顧客の処理要求はキュー処理要求保持部13内で完全に待たせ、ケース1~4の顧客は、優先順位が高いほど処理要求がキューから取り出されやすくする。例えば、キューを先頭から調べていく過程で、ケース1の顧客の処理要求は見つけるたびにすべてキューから取り出し、ケース2の顧客の処理要求は2回見つけるごとに1回の割合でキューから取り出す等というように、優先順位が下がるほどキューから取り出す割合を下げていくのである。また、同じ優先順位の保証時間内顧客が複数存在している場合には、キューからそれら同順位の各保証時間内顧客の処理要求が取り出される割合が、それら各保証時間内顧客に割り当てられた最大同時セッション数同士の比率に応じたものとなるように制御してもよい。また、以上の例では、保証時間外顧客のように優先されない顧客の現に実行中の処理要求は実行が完了するまで待ったが、これも一例に過ぎない。この代わりに、次のような制御を行ってもよい。すなわち、この例では、処理要求を、再実行可能なものと再実行不可能なものとに分類しておき、保証モードでは、優先されない顧客の現にデータ処理システム30内で実行中の処理要求のうち、再実行可能な処理要求については、その実行を強制的に取りやめる途中までの処理結果を破棄。また、別の例として、再実行可能な処理要求は強制的に中断途中までの処理結果を保持してサスペンドしてもよい。再実行不可能な処理要求については、そのような強制的な取りやめ又は中断は行わず、実行が完了するのを待つ。実行を取りやめた再実行可能な処理要求は、例えばキューの先頭に戻すなどにより、動作モードが通常モードに戻ったときにその取りやめた処理要求から実行されるようにしてもよい。また中断した処理要求は、動作モードが通常モードに戻り次第、途中の処理結果を用いて再開する。なお、再実行可能な処理要求としては、例えば、データベースの内容の閲覧などのように、実行を取りやめ又は中断して後で再開しても、最初の実行時と再開後の実行時で実行結果が変わらない種類の処理要求がある。再実行不可能な処理要求には、例えば、データベースへの書き込み処理の要求などがある。この制御のためには、処理要求スケジュール部15は、各処理要求が再実行可能か否かを示す分類情報を保持していればよい。このように優先されない顧客の再実行可能な処理要求の実行を取りやめ又は中断することで、そのような取りやめ又は中断をしない場合よりも急速にデータ処理システム30の余力を増大させ、その余力が優先される顧客に振り向けられることとなる。また、以上の例では、データ処理システム30が高負荷状態であるか否かを、各顧客の目標応答時間の達成状況に基づいて判定したが、これは一例に過ぎない。この他に、例えば、すべての顧客の実行中セッション数の総和が予め定められた閾値を超えた場合に、高負荷状態と判定してもよい。また、各顧客の目標応答時間の達成状況と、全顧客の実行中セッション数の総和との組合せにより、高負荷状態か否かを判定してもよい。この場合、例えば、少なくとも1つの顧客の目標応答時間が達成されていない場合は高負荷状態と判定すると共に、すべての顧客の目標応答時間が達成されている場合でも、全顧客の実行中セッション数の総和が閾値を超えていれば高負荷状態と判定する、等の判定条件を用いればよい。また、各顧客の目標応答時間の達成状況や全顧客の実行中セッション数ではなく、各データ処理部32のCPU中央演算装置の使用率等といった、ハードウエアの負荷状況の計測値に基づき、データ処理システム30が高負荷状態であるか否かを判定してもよい。さて、処理要求の中には、単純な画面遷移の要求等のように、極めて短時間で処理が完了するすなわちデータ処理システム30にとっての負荷が極めて低いものが存在する。またその一方で、大量のデータ処理や大量のデータ更新などを伴う処理のように、ある程度以上の処理時間を要するすなわち処理負荷が高い処理要求も存在する。一般に、各ユーザからの処理要求にはそのような負荷の異なるものが混在している。このような状況において、処理負荷が極めて軽い処理要求と、そうでない処理要求とを同列に取り扱ったのでは、不都合な場合もある。例えば、保証モード時に、保証時間外顧客の単純な画面遷移の要求をキュー内で待たせたとしても、データ処理システム30の負荷軽減にはあまり寄与しないが、その顧客にとっての操作の快適性は著しく低下する。また、データ処理システム30が高負荷状態か否かの判定に実行中セッション数を用いる場合に、単純な画面遷移要求のようなほとんど負荷のない処理要求も1つのセッションとしてカウントすると、カウント結果と実際の負荷との乖離が激しくなってしまう。そこで、処理要求を、極めて短時間で処理が完了するものとそうでないものとに分類しておき、前者は実行中セッション数にカウントしないようにしてもよい。この場合、極めて短時間で処理が完了する処理要求を、保証時間外顧客からのものであっても、キュー内で待機させずに、先入れ先出し順に実行するようにしてもよい。以上に例示した処理要求実行管理装置10は、例えば、汎用のコンピュータに上述の各機能モジュールの処理を表すプログラムを実行させることにより実現してもよい。ここで、コンピュータは、例えば、ハードウエアとして、CPU等のマイクロプロセッサ、ランダムアクセスメモリRAMおよびリードオンリメモリROM等のメモリ一次記憶、HDDハードディスクドライブを制御するHDDコントローラ、各種I/O入出力インタフェース、ローカルエリアネットワークなどのネットワークとの接続のための制御を行うネットワークインタフェース等が、たとえばバスを介して接続された回路構成を有する。また、そのバスに対し、例えばI/Oインタフェース経由で、CDやDVDなどの可搬型ディスク記録媒体に対する読み取り及び/又は書き込みのためのディスクドライブ、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体に対する読み取り及び/又は書き込みのためのメモリリーダライタ、などが接続されてもよい。上に例示した各機能モジュールの処理内容が記述されたプログラムがCDやDVD等の記録媒体を経由して、又はネットワーク等の通信手段経由で、ハードディスクドライブ等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがRAMに読み出されCPU等のマイクロプロセッサにより実行されることにより、上に例示した機能モジュール群が実現される。"