複数クライアント装置からの処理要求を受け付けるサーバ装置における受付制御のためのサービス要求受付制御方法であって、前記クライアント装置からの要求に対する一連の処理に要した平均時間を算出するステップと、前記平均時間を目標サービス処理時間と比較することでサービスの負荷状態を判定するステップと、前記負荷状態に基づいて、前記クライアント装置からの要求受付を拒否するステップと、を有することを特徴とするサービス要求受付制御方法。前記平均時間を算出するステップは、2相コミット手法における仮要求メッセージの受信時刻を、前記クライアント装置からの要求に対する処理の開始時間として、2相コミット手法における確定応答メッセージの送信時刻を、前記クライアント装置からの要求に対する処理の終了時間として、平均時間を算出することを特徴とする請求項1に記載のサービス要求受付制御方法。前記要求受付を拒否するステップは、2相コミット手法における仮要求メッセージのみを選択して、受付拒否の対象とすることを特徴とする請求項1または2に記載のサービス要求受付制御方法。前記サービスの負荷状態を判定するステップは、要求受付を拒否した後、処理中の要求が予め設定された一定数終了した場合、または、全ての要求が処理された場合、再度判定を行うことを特徴とする請求項1から3のいずれか1項に記載のサービス要求受付制御方法。複数クライアント装置からの処理要求を受け付けるサーバ装置における受付制御のためのサービス要求受付制御装置であって、前記クライアント装置からの要求に対する一連の処理に要した平均時間を算出する手段と、前記平均時間を目標サービス処理時間と比較することでサービスの負荷状態を判定する手段と、前記負荷状態に基づいて、前記クライアント装置からの要求受付を拒否する手段と、を備えていることを特徴とするサービス要求受付制御装置。複数クライアント装置と、該複数クライアント装置からの処理要求を受け付けるサーバ装置と、請求項5に記載のサービス要求受付制御装置とを備えることを特徴とするサービス要求受付制御システム。しかしながら、従来手法1では、ボトルネックが判明していないと使えない、または全てのボトルネック候補に対して設計する必要がある。さらに、ハードウェア資源の状態によらず上限が決められてしまうため、設計上の上限値を低く設定しすぎることによりハードウェア資源を十分使い切れない可能性がある。つまり、性能上限がハードウェア性能ではなく設計上の上限値で制限される。逆に設計上の上限値を高く設定しすぎることでハードウェア資源がボトルネックになってしまい、過負荷状態に陥ってしまう可能性があるといった課題があった。また、従来手法2では、どのハードウェア資源がボトルネックになるかをあらかじめ知っておかなければならず、設計上困難を伴う点が課題であった。また、ソフトウェア実装がハードウェア性能を十分使い切れない実装であったりした場合、ハードウェア資源の逼迫の検出が困難である例:マルチコアCPUの場合、ソフトウェア実装により利用率上限が変わりうるといった課題があった。したがって本発明は、1利用可能なハードウェア資源量をあらかじめ知ることなくハードウェア資源を使い切ることが可能で、2ボトルネック原因をあらかじめ知ることなく過剰なサービス要求の受信を検出することが可能な、受付拒否の仕組みを伴うサービス要求受付制御方法、装置およびシステムを実現することを目的とする。上記目的を実現するため本発明によるサービス要求受付制御方法は、複数クライアント装置からの処理要求を受け付けるサーバ装置における受付制御のためのサービス要求受付制御方法であって、前記クライアント装置からの要求に対する一連の処理に要した平均時間を算出するステップと、前記平均時間を目標サービス処理時間と比較することでサービスの負荷状態を判定するステップと、前記負荷状態に基づいて、前記クライアント装置からの要求受付を拒否するステップとを有する。また、前記平均時間を算出するステップは、2相コミット手法における仮要求メッセージの受信時刻を、前記クライアント装置からの要求に対する処理の開始時間として、2相コミット手法における確定応答メッセージの送信時刻を、前記クライアント装置からの要求に対する処理の終了時間として、平均時間を算出することも好ましい。また、前記要求受付を拒否するステップは、2相コミット手法における仮要求メッセージのみを選択して、受付拒否の対象とすることも好ましい。また、前記サービスの負荷状態を判定するステップは、要求受付を拒否した後、処理中の要求が予め設定された一定数終了した場合、または、全ての要求が処理された場合、再度判定を行うことも好ましい。上記目的を実現するため本発明によるサービス要求受付制御装置は、複数クライアント装置からの処理要求を受け付けるサーバ装置における受付制御のためのサービス要求受付制御装置であって、前記クライアント装置からの要求に対する一連の処理に要した平均時間を算出する手段と、前記平均時間を目標サービス処理時間と比較することでサービスの負荷状態を判定する手段と、前記負荷状態に基づいて、前記クライアント装置からの要求受付を拒否する手段とを備えている。上記目的を実現するため本発明によるサービス要求受付制御システムは、複数クライアント装置と、該複数クライアント装置からの処理要求を受け付けるサーバ装置と、上記に記載のサービス要求受付制御装置とを備える。本発明の利用可能なハードウェア資源量をあらかじめ知ることなくハードウェア資源を使い切ることが可能という特徴によれば、OSやソフトウェアで設定された設計上の受付上限値が実際に利用可能なハードウェア資源量からずれることによって生じるハードウェア資源の余剰や不足を防止するという効果を得ることができる。また、本発明のボトルネック原因をあらかじめ知ることなく過剰なサービス要求を検出することが可能という特徴によれば、システム導入時のハードウェア形態によらず過負荷を防止可能という効果を得ることができる。本発明を実施するための最良の実施形態について、以下では図面を用いて詳細に説明する。図1は、本発明の実施形態におけるシステム構成図である。本システムは、制御要求受付サーバ1、複数のクライアント装置2、および複数の制御対象装置3から構成される。制御要求受付サーバ1は、クライアント2が発生する制御対象装置3への制御要求を受け付け、要求内容に基づき適切な装置を選択し制御する。その際、クライアント2からの要求を仮要求確定要求の2段階で受け付ける2相コミット手法。図2に本発明の制御要求受付サーバの機能構成を示す。制御要求受付サーバ1は、メッセージ処理部11、受付可否判定部12、処理時間監視部13、および要求処理部14を備えている。メッセージ処理部11は、クライアント2からの要求メッセージを受信しメッセージの種別仮要求か確定要求かその他の制御メッセージかやパラメータを抽出する機能を持つ。また、クライアント2に対して応答メッセージを送信する機能を持つ。受付可否判定部12は、現在の負荷状況に基づき仮要求の受付が可能かどうかを判定する。仮要求の受付が可能な場合は、仮要求処理を進めるよう要求処理部14へ通知し、受付が不可能な場合は拒否応答を行う。また、確定要求については負荷に関係なく要求処理部14へ通知する。処理時間監視部13は、仮要求の受信から確定応答の送信までの時間=処理時間の履歴を蓄積しておき、処理時間に基づく負荷状況を受付可否判定部12に通知する。平均処理時間が目標として予め設定された閾値目標サービス処理時間を超えることが検出された場合には、これ以上の仮要求の受付を行わないように通知する。また、受付拒否状態を解除可能な場合、再度仮要求の受付を行うよう受付可否判定部12に通知する受付拒否状態の解除は以下で詳細に説明される。要求処理部14では、リクエストに基づいた制御を制御対象装置3に対して行う。制御対象機器3からの応答が全て返ってくるのを待機してから、処理の成否をメッセージ処理部11に応答する。図3に本発明を用いたシステムの処理フローを示す。本フローに基づいて、制御要求受付サーバ1の動作を説明する。1解読処理パラメータ抽出:制御要求受付サーバ1は、クライアント2から仮要求の要求メッセージを受信する。メッセージ処理部11は、要求メッセージを解読して、メッセージの種別を判別する。仮要求であるため、パラメータを抽出し、受付可否判定部12に渡す。2新規要求の受付可否判定:受付可否判定部12は、現在の負荷状況に基づき仮要求の受付が可能かどうかを判定する。新規要求拒否が有効化されている場合、現在の負荷状況では仮要求の受付が不可能として、拒否応答を行う。新規要求拒否が有効化されていない場合、受付が可能であるため、処理時間監視部13に仮要求受付時刻の通知を行い、要求処理部14に仮要求の要求メッセージのパラメータを渡す。3処理時間測定の開始:処理時間監視部13は、処理時間測定のため、仮要求メッセージ受信時刻を仮要求受付時間として記録する。4制御可否判定:要求処理部14は、上記パラメータを解析し、制御可能かどうか判定する。パラメータ異常等により制御できない要求の場合、制御不可能として、メッセージ処理部11に拒否応答を行う。メッセージ処理部11はこの拒否応答をクライアント2に通知する。なお、この場合、処理時間監視部13に、処理時間測定の停止通知を行う。制御可能な場合、次の処理に進む。5制御対象機器への問い合わせ:要求処理部14は、上記パラメータで制御対象機器3に処理が可能であるか問い合わせを行う。ここで、複数の制御対象機器3に処理を依頼する必要がときは、複数の制御対象機器3に問い合わせを行う。6成否判定:制御対象機器3からの応答が全て返ってくるのを待機してから、処理の成否を受付可否判定部12を介して、メッセージ処理部11に応答する。メッセージ処理部11はクライアント2に仮応答を返す。制御対象機器3からの応答が処理否である場合、処理時間監視部13に、処理時間測定の停止通知を行う。制御対象機器3からの応答が処理成功である場合、制御要求受付サーバ1は、クライアント2から、確定要求の要求メッセージを受信する。メッセージ処理部11は受付可否判定部12を介して、要求処理部13に通知する。7制御対象機器への制御実施:要求処理部14では、リクエストに基づいた制御を制御対象装置3に対して行う。8成否判定:制御対象機器3からの応答が全て返ってくるのを待機してから、処理の成否をメッセージ処理部11に応答する。メッセージ処理部11は、処理時間監視部13に処理終了時刻の通知を行い、クライアント2に確定応答を返す。9処理時間測定の終了:処理時間監視部13は、仮要求受付時刻と、確定応答メッセージ送信時刻間を処理時間として記録する。上記の1から9により、クライアント2からの仮要求から確定応答に至るまでの一連の処理が実行される。処理時間監視部13では、これとは独立に、平均処理時間の閾値超過判定と滞留要求数の計測が以下のように行われる。10平均処理時間の閾値超過判定:平均処理時間が閾値Tthを超えた場合、受付可否判定部12に、閾値超過通知を行い、受付可否判定部12は新規要求拒否を有効化する。上記に記載したように、新規要求拒否が有効化されると、仮要求が拒否対象になる。確定要求は、拒否すると非効率なため拒否対象にならない。11滞留要求数の計測:クライアント2からの仮要求から確定応答に至るまでの処理中の要求数を計測する。処理時間監視部13における、平均処理時間は以下のように検出される。図4は、平均処理時間算出のイメージを示す。1リクエストの処理時間は、仮要求メッセージの受信から確定応答の送信までの時間である。ただし、滞留中のリクエストを考慮に入れるため、処理中のリクエストについては、仮要求メッセージの受信~現在時刻と現時点での平均処理時間のうち大きい方とする。例えば、図4において、下の3つのリクエストは、現時点での平均処理時間で考慮し、その2つ上のリクエストは、滞留時間が平均処理時間より既に大きいため、滞留時間で考慮する。平均処理時間の算出対象リクエストは、極端に古いリクエストの処理時間を排除するため、直近N個と直近Trec秒までに受け付けたリクエスト数の少ない方とする。図4の場合、N個前のリクエストの仮要求メッセージの受信が、Trec秒前以前にあるため、図4の上の2つのリクエスト算出対象外となる。なお、図3において、制御可否判定で制御できない要求と判定された要求、および成否判定で制御対象機器3からの応答が処理否である要求は、途中で処理時間測定が停止されているため、算出対象リクエストに含めない。処理時間監視部13における、受付拒否状態の解除は以下のように行われる。処理時間監視部13は、下記のいずれかを満たすとき、受付拒否状態を解除可能か確認する。1受付拒否後M個のリクエストの処理が完了2全ての待機中リクエストの処理が完了この場合、処理時間監視部13は、直近のデータで改めて平均処理時間と閾値を比較して、閾値以下であれば受付拒否状態を解除する。閾値を超えていたら、受付拒否状態を継続再度Mリクエスト/全リクエストの処理終了を待つする。なお、上記に記載された各種制御パラメータTth、Trec、N、Mはサーバ管理者が手動で制御要求受付サーバ1に事前に設定する。本発明は、ネットワーク機器の制御サーバシステムに適用できる。ネットワーク機器の制御サーバは、1台のサーバで複数の機器を管理しており、設定要求の集中が発生しうる。また、制御にかかる時間がサーバ外制御対象となる機器の過負荷による可能性があり、ボトルネック推定が容易ではない。そのため、本発明が効果的に機能する。以上のように本発明は、クライアントからの要求の処理時間をモニタリングして処理性能の劣化を検出し、受付制御を行う。このため、ボトルネックの箇所を意識しないで済み、性能逼迫の検出が容易ソフトウェア実装におけるハードウェア資源利用の特性等を意識しないですむであり、設計上の上限値に制限されず、システムのハードウェア性能を使い切ることができる。特に本発明は、ボトルネックが分かりにくいサーバシステム例:多段サーバ、機器制御サーバに容易に適用可能である。また、以上述べた実施形態は全て本発明を例示的に示すものであって限定的に示すものではなく、本発明は他の種々の変形態様および変更態様で実施することができる。従って本発明の範囲は特許請求の範囲およびその均等範囲によってのみ規定されるものである。