JP4394710B2 - 負荷制御装置及び方法及びプログラム - Google Patents

Description

本発明は、負荷制御装置及び方法及びプログラムに係り、特に、クライアント装置とサーバとの間に配置され、クライアント装置から受信したリクエストをサーバに転送し、当該リクエストに対してサーバから返却されるレスポンスをクライアント装置に転送する装置における、リクエスト・レスポンスのバッファリングとスケジューリングに関する。なお、本明細書では、Ｗｅｂサーバに着目して説明するが、必ずしも他のサーバへの本発明の適用を制限するものではない。

インターネットの普及に伴い、ネットワークを介して様々なサービスを利用できるようになっている。メール、ホームページの閲覧、検索、オンライン取引、ＩＰ電話、ビデオオンデマンドなどは、その一例である。これらのネットワークサービスは様々な形態で提供し得るが、近年、クライアント装置とのインタフェースとして、Ｗｅｂの利用が主流になっている。

Ｗｅｂの基本的な仕組みは以下の通りである。まず、クライアント装置がＷｅｂサーバに対して取得したいコンテンツを識別するＵＲＬ（Uniform Resource Locator）を付与したリクエストを送信する。Ｗｅｂサーバがリクエストを受け取ると、リクエスト中のＵＲＬに対応するコンテンツをレスポンスとしてクライアント装置に送り返す。Ｗｅｂにおけるサービスは全て、このリクエスト−レスポンスの繰り返しによって提供される。リクエストやレスポンスといったメッセージは、ＨＴＴＰ(Hyper Text Transfer Protocol)に基づいて転送される。以下、本明細書では、Ｗｅｂサーバ上でＨＴＴＰプロトコルを処理する機能を「ＨＴＴＰサーバ」、リクエストに応じたコンテンツを生成する機能を「Ｗｅｂアプリケーション」と呼ぶ。

Ｗｅｂが普及するにつれて、サービスを快適に利用していくための課題も明らかになりつつある。その課題の一つとして、サービス利用が集中した際の過剰リクエストへの対応が挙げられる。サービス利用が集中する例として、人気の高い銘柄の株やチケットの売買によるリクエスト集中や、災害発生時の見舞呼などがある。また、悪意のあるクライアントによって、Ｆ５アタックなど無意味なリクエストが大量に送信される場合もある。これらの要因によって、Ｗｅｂサーバにリクエストが過剰に送信されると、Ｗｅｂサーバのリクエスト処理性能の低下が生じる。

過剰リクエスト時におけるサーバのリクエスト処理性能の低下要因は以下の通りである。すなわち、第１に、サーバで処理しきれないリクエストの受信に伴う、割込み、ＴＣＰ／ＩＰ処理といった入出力オペレーションが増加する。第２に、リクエストを処理するスレッドまたはプロセス数が増大し、スレッドまたはプロセスの切替処理に要するオーバヘッドである文脈切り替えオーバヘッドが顕在化する。第３に、クライアントにレスポンスが返されるまでの応答時間が増加するため、応答を待ちきれないクライアントがリクエストを途中でキャンセルするようになる。これらの結果、Ｗｅｂサーバが混雑すればするほど、Ｗｅｂサーバの処理性能が低下するという問題が生じる。

図１５は、リクエスト過剰によるＷｅｂサーバの処理性能の低下を示す実験結果である。同図では、あるＷｅｂサーバに対して、入力するリクエストレート、すなわち、単位時間当たりのリクエスト数（ｒｐｓ）を変化させてリクエストを送信する。そして、スループット、すなわち、Ｗｅｂサーバが単位時間当たりに完了できたリクエスト数（ｒｐｓ）を計測している。同図に示されるように、入力するリクエストレートが一定範囲内であるならば、リクエストレートに対してスループットは比例して増加する（図１５（ａ））。しかしながら、Ｗｅｂサーバの最大スループットに達すると、スループットが低下に転じる（図１５（ｃ））。この結果から、Ｗｅｂサーバの最大性能を超えるリクエストを受信した場合でも、図１５（ｂ）に沿って、Ｗｅｂサーバ最大性能を維持できる技術が必要といえる。

過剰リクエストによるサーバ性能低下を防ぐため、サーバに送信されるリクエスト量を予め制限する手法が提案されている。リクエスト量を制限する指標として、（ａ）TCP接続数、（ｂ）サーバ負荷状態、（ｃ）帯域、（ｄ）並列度などが用いられる（例えば、非特許文献１，２参照）。
B. Laurie, P. Laurie, "Apache ハンドブック第２版"、オライリージャパン 松沼正浩、日比野秀章、佐藤芳樹、光来健一、千葉滋著、"過負荷時のＷｅｂアプリケーションの性能劣化を改善するSession-Level Queue Scheduling"、第２回ディペンダブルソフトウェアワークショップ（ＤＳＷ'０５），ｐｐ．１０５−１１４，２００５年１月

しかしながら、上記の指標を用いた場合には、以下のような問題がある。

（ａ）「ＴＣＰ接続数」を用いる場合は、同時接続可能なＴＣＰ接続数の上限を定めることによって、サーバの過負荷回避を試みる。ApacheのMax Clientsディレクティブなど、汎用的なＨＴＴＰサーバ、負荷分散システムなどで用いられる（非特許文献１）。しかしながら、リクエストの種類、クライアントの送受信速度などによって、ＴＣＰ接続毎にその負荷が大きく異なる。このため、ＴＣＰ接続数の上限に達する前にサーバが過負荷となる。逆に、ＴＣＰ接続数が上限に達していることによって、サーバリソースが余っていても新たなＴＣＰ接続を確立できない、といった問題が生じる。

（ｂ）「サーバの負荷状態」を用いる場合は、ＣＰＵ利用率、メモリ使用量、応答時間などを定期的に計測し、サーバが過負荷か否かを判定する。そして、過負荷と判定した場合は、サーバの負荷を軽減させるためのトラヒック制御として、新しく受信したリクエストを第三のサーバに転送したり、またはリクエストを拒絶したりする。しかし、過負荷と判定されてから初めてトラヒック制御を行うため、一時的なサーバの性能低下が免れない。

（ｃ）「帯域」を用いる場合は、シェーパなどの帯域制御機能を用いて、サーバに到達されるトラヒック量を制限する。しかしながら、帯域はサーバの負荷を正確に測る指標とはならない。例えば、画像ファイルのダウンロードは、大きな帯域を占めるがサーバに与える負荷は比較的小さい。故に、帯域制限によって、サーバのリソースを充分に活用しつつ、過負荷を確実に回避することは難しい。

（ｄ）「並列度」を用いる場合は、サーバが同時に実行するスレッドまたはプロセス数を制限する。これにより、リクエストを処理するスレッドまたはプロセス数の増大に伴う文脈切り替えオーバヘッドを削減できる。並列度を制御する具体例として、ページ単位に並列度を制限するように、ＨＴＴＰサーバを拡張した技術（非特許文献２）がある。しかし、サーバ上で並列度を制御しても、リクエスト処理性能低下の第一要因である、サーバが処理しきれないリクエストの受信に伴う、割込み、ＴＣＰ／ＩＰ処理などのオーバヘッドを避けることができない。その結果、他の手法と同様に、過剰リクエスト時におけるサーバの処理性能の低下が生じる。また、ＨＴＴＰサーバまたは、Ｗｅｂアプリケーションの変更が必要になるため、既に運用中のサービスへの導入障壁が高いといった問題がある。

本発明は、上記の点に鑑みなされたもので、過剰リクエスト時におけるサーバの性能低下を回避することができる負荷制御装置及び方法及びプログラムを提供することを目的とする。

図１は、本発明の原理構成図である。

本発明（請求項１）は、クライアント装置３００とサーバ２００との間に配置され、該クライアント装置３００からリクエストを受信するリクエスト受信手段１２０と、該リクエストを該サーバ２００に送信するリクエスト送信手段１６０と、該リクエストに対して該サーバから返却されるレスポンスを受信するレスポンス受信手段１７０と、該レスポンスを該クライアント装置３００に送信するレスポンス送信手段１３０と、を有する負荷制御装置１００であって、
クライアント装置３００から受信したリクエストデータをサーバ２００に送信するまで一時蓄積するリクエストバッファ１１１と、
サーバ２００から受信したレスポンスデータをクライアント装置３００に送信するまで一時蓄積するレスポンスバッファ１１２と、
応答待ちリクエストのリクエストデータまたはレスポンスデータをサーバ２００と送受信する速度が、クライアント装置３００と該リクエストデータまたは該レスポンスデータを送受信する速度によって制限されるか否かを、リクエストバッファ１１１のリクエストデータ及びレスポンスバッファ１１２のレスポンスデータの蓄積状態に基づいて判定する判定手段１６１１，１７１１と、
応答待ちのリクエストの総数、判定手段１６１１，１７１１でサーバ２００との送受信速度が制限されると判定された応答待ちリクエストの数、及び該判定手段１６１１，１７１１で該サーバ２００との送受信速度が制限されないと判定された応答待ちリクエストの数が、それぞれに設けられている閾値を下回るまで、該サーバ２００への新たなリクエスト送信を待ち合わせる制御手段１５０と、
を有し、
サーバ２００に送信開始済みであるが、該サーバからレスポンス全体が返却されていない応答待ちリクエストの数を制限する。

また、本発明（請求項２）は、判定手段において、
サーバへのリクエスト送信完了前に、リクエストバッファに蓄積されている当該リクエストのリクエストデータのサイズが所定の閾値以下となった場合に、該サーバとの送受信速度が制限されると判定する判定手段１６１１を含む。

また、本発明（請求項３）は、判定手段において、
サーバからのレスポンス受信完了前に、レスポンスバッファに蓄積されているレスポンスデータのサイズが所定の閾値に達した場合に、該サーバとの送受信速度が制限されると判定する判定手段１７１１を含む。

また、本発明（請求項４）は、制御手段１５０において、
リクエスト全体がリクエストバッファに蓄積されていること、または、該バッファに蓄積されているリクエストデータの大きさが所定の閾値以上であることを、サーバにリクエスト送信するための必要条件とする。

また、本発明（請求項５）は、リクエスト受信手段１２０において、
リクエストのリクエストデータまたは、該リクエストに対するレスポンスデータをサーバと送受信する速度が、クライアント装置とリクエストデータまたはレスポンスデータを送受信する速度によって制限されると判定された場合に、リクエストバッファに蓄積できるリクエストデータの最大サイズを変化させる手段を含む。
また、本発明（請求項６）は、リクエスト受信手段１２０において、
リクエストのリクエストデータまたは、該リクエストに対するレスポンスデータをサーバと送受信する速度が、クライアント装置とリクエストデータまたはレスポンスデータを送受信する速度によって制限されると判定された場合に、レスポンスバッファに蓄積できるレスポンスデータの最大サイズを変化させる手段を含む。

図２は、本発明の原理を説明するための図である。

本発明（請求項７）は、クライアント装置とサーバとの間に配置され、該クライアント装置から受信したリクエストを該サーバに送信し、該リクエストに対して該サーバから返却されるレスポンスを該クライアント装置に送信する装置における、過剰リクエストを回避させるための負荷制御方法であって、
クライアント装置とサーバとの間に配置され、該クライアント装置からリクエストを受信するリクエスト受信手段と、該リクエストを該サーバに送信するリクエスト送信手段と、該リクエストに対して該サーバから返却されるレスポンスを受信するレスポンス受信手段と、該レスポンスを該クライアント装置に送信するレスポンス送信手段と、判定手段及び制御手段とを有する負荷制御装置が、
リクエスト受信手段が、クライアント装置から受信したリクエストデータをサーバに送信するまで一時リクエストバッファに蓄積し、レスポンス受信手段が、サーバから受信したレスポンスデータをクライアント装置に送信するまで一時レスポンスバッファに蓄積している状況において、
判定手段が、応答待ちリクエストのリクエストデータまたはレスポンスデータをサーバと送受信する速度が、クライアント装置と該リクエストデータまたは該レスポンスデータを送受信する速度によって制限されるか否かを、リクエストバッファのリクエストデータ及びレスポンスバッファのレスポンスデータの蓄積状態に基づいて判定する判定ステップ（ステップ１）と、
制御手段が、応答待ちのリクエストの総数、判定ステップにおいてサーバとの送受信速度が制限されると判定された応答待ちリクエストの数、及び該判定ステップにおいて該サーバとの送受信速度が制限されないと判定された応答待ちリクエストの数が、それぞれに設けられている閾値を下回るまで、該サーバへの新たなリクエスト送信を待ち合わせるようリクエスト送信手段を制御する制御ステップ（ステップ２）と、を行い、
サーバに送信開始済みであるが、該サーバからレスポンス全体が返却されていない応答待ちリクエストの数を制限する。

また、本発明（請求項８）は、判定ステップ（ステップ１）において、
サーバへのリクエスト送信完了前に、リクエストバッファに蓄積されている当該リクエストのリクエストデータのサイズが所定の閾値以下となった場合に、該サーバとの送受信速度が制限されると判定するステップを行う。

また、本発明（請求項９）は、判定ステップ（ステップ１）において、
サーバからのレスポンス受信完了前に、レスポンスバッファに蓄積されているレスポンスデータのサイズが所定の閾値に達したか場合に、該サーバとの送受信速度が制限されると判定するステップを行う。

また、本発明（請求項１０）は、制御ステップ（ステップ２）において、
リクエスト全体がリクエストバッファに蓄積されていること、または、該バッファに蓄積されているリクエストデータの大きさが所定の閾値以上であることを、サーバにリクエスト送信するための必要条件とする。

また、本発明（請求項１１）は、判定ステップ（ステップ１）において、
リクエストのリクエストデータまたは、該リクエストに対するレスポンスデータをサーバと送受信する速度が、クライアント装置とリクエストデータまたはレスポンスデータを送受信する速度によって制限されると判定された場合に、リクエストバッファに蓄積できるリクエストデータの最大サイズを変化させるステップを行う。
また、本発明（請求項１２）は、判定ステップ（ステップ１）において、
リクエストのリクエストデータまたは、該リクエストに対するレスポンスデータをサーバと送受信する速度が、クライアント装置とリクエストデータまたはレスポンスデータを送受信する速度によって制限されると判定された場合に、レスポンスバッファに蓄積できるレスポンスデータの最大サイズを変化させるステップを行う。

本発明（請求項１３）は、請求項１乃至６のいずれか１項に記載の負荷制御装置を構成する各手段としてコンピュータを機能させる負荷制御プログラムである。

上記のように本発明の負荷制御装置によれば、サーバからの応答待ちリクエストの数を制限し、サーバへのリクエストの送信を待ち合わせることにより、サーバが処理しきれないリクエストがサーバに送信されない。これにより、サーバが処理しきれないリクエストの受信処理に伴うサーバのオーバヘッドを削減することができる。

以下、図面と共に本発明の実施の形態を説明する。

最初に、本発明の概要を前述の図１の構成に基づいて説明する。

本発明の負荷制御装置は、クライアント装置３００とサーバ２００との間に配置され、両者のリクエスト・レスポンスの送受信を仲介する。すなわち、クライアント装置３００から受信したリクエストをサーバに転送し、さらにサーバ２００から返却されるレスポンスをクライアント装置３００に転送する。このとき、本発明は、サーバ２００に送信済みであるが、サーバ２００からレスポンスが返却されていないリクエスト、すなわち、応答待ちリクエストの数を制限する。この制限を行うためには、判定手段１６１１が応答待ちリクエスト数が閾値を超える場合は、リクエストをリクエストバッファ１１１にバッファリングし、制御手段１５０が応答待ちリクエスト数が閾値を下回るまで、リクエストの送信を待ち合わせるようリクエスト送信手段１６０を制御する。

説明を単純化し、まず、応答待ちリクエスト数の閾値を"１"とした場合を、図３に示す。

本発明では、サーバ２００でのスレッドの実行完了をサーバ２００からレスポンスの受信によって認識する。そして、先に送信したリクエストに対するレスポンスが返却されて初めて、次のリクエストをサーバ２００に送信する。このため、本発明に基づけば、サーバ２００が処理しきれないリクエストがサーバに送信されない。ゆえに、処理しきれないリクエストの受信処理に伴うサーバのオーバヘッドが削減される。

図３では、サーバ２００が負荷制御装置１００のレスポンス受信手段１７０にレスポンスを返却してから、負荷制御装置１００が次のリクエストを送信するまでの遅延によって、サーバ２００に空き時間が生じている。この問題を回避するため、本発明では、応答待ちリクエスト数の閾値として、"１"より大きい値を設定できる。図４は、応答待ちリクエスト数の閾値を"２"とした場合の実行例を示している。応答待ちリクエスト数を複数とすることによって、サーバ上で実行可能状態にあるスレッド数が増加する。あるスレッドの実行が完了すると、次のスレッドの実行を即時に開始できるため、サーバ２００のリソースに空きが生じ難くなる。また、閾値より多くのスレッドがサーバ２００上で生成されないため、文脈切替のオーバヘッドを抑えることができる。

さらに、本発明に基づけば、サーバ２００の内部情報を参照することなく、サーバ２００の外部からサーバ２００の負荷を制御できる。故に、既に稼動中のサーバ２００に対して付加的な機能の追加または変更を行わないで、本発明を導入することができる。

さらに、本発明の負荷制御装置１００は、応答待ちリクエスト数を制限してもサーバ２００の効率を低下しないようにするため、クライアント装置３００から受信するリクエスト、及びサーバ２００から受信するレスポンスをレスポンスバッファ１１２に一時蓄積する。

インターネットでは、クライアント装置のアクセス環境は多様であり、ＦＴＴＨ（Fiber To The Home）を使って高速にリクエスト・レスポンスを送受信できるクライアント装置もあれば、携帯電話などのように送受信速度が低いクライアント装置もある。一方で、負荷制御装置は、サーバに隣接されるため、負荷制御装置−サーバ間は、高速な通信を仮定できる。このとき、負荷制御装置にて、クライアント装置から受信したリクエスト、または、サーバから受信したレスポンスを一時蓄積なしに転送すると、低速なクライアント装置がアクセスした際に、サーバの利用効率が低下するという問題が生じる。図５、図６は、このような問題を示したもので、負荷制御装置が、一時蓄積なしに、クライアント装置から受信したリクエストをサーバに転送し、サーバから受け取ったレスポンスをクライアント装置に返す場合のシーケンス図を例示している。図５は、高速なクライアント装置がアクセスした場合であり、図６は、低速なクライアント装置がアクセスした場合を示している。リクエストの一時蓄積をしないため、負荷制御装置は、クライアント装置からリクエストデータを受け取ると、即時にそのリクエストデータをサーバに転送しなければならない。故に、クライアント装置が低速であるほど、サーバにおいて、リクエストの受信を開始してから全体の受信を完了するまでに要する時間が増加する。また、負荷制御装置がサーバからレスポンスを受信する場合も、受信したレスポンスデータをクライアント装置に転送し終えるまで、続きのレスポンスデータをサーバから受信できない。故に、クライアント装置が低速であるほど、サーバが負荷制御装置にレスポンス送信を開始してから全体の送信が完了するまでに要する時間が増加する。従って、例え、同じリソースを取得するリクエストであっても、その送信元クライアント装置の送受信速度が低い場合、サーバでのリクエスト実行時間が増加する。その結果、サーバのスループット（単位時間当たりに処理できるリクエストの数）の低下を引き起こす。

これに対し、本発明の負荷制御装置１００は、クライアント装置３００から受信したリクエスト、及び、サーバ２００から受信したレスポンスの全体、または、一部をバッファ１１０に一時蓄積する。これにより、クライアント装置−負荷制御装置間の送受信速度に依存しないで、負荷制御装置−サーバ間で高速にリクエスト・レスポンスを送受信できる。図７に、本発明における、リクエスト・レスポンスをバッファ１１０に一時蓄積して送受信する場合のシーケンス図を示す。なお、同図にクライアント装置３００は、図６と同様の低速なクライアント装置であるとする。図７に示すように、負荷制御装置１００は、所定サイズに達するまで、クライアント装置３００から受信したリクエストデータをサーバ２００に送信せずに、自身のリクエストバッファ１１１に蓄積する。そして、所定サイズのリクエストデータがリクエストバッファ１１１に蓄積された後、サーバ２００へのリクエスト送信を開始する。従って、負荷制御装置１００からサーバ２００にリクエストを送信する際には、負荷制御装置１００内のリクエストバッファ１１１に蓄積されているリクエストデータを読み出せばよく、クライアント装置−負荷制御装置間の送受信速度に依存しないで、高速にリクエストを送信できる。同様に、レスポンス受信時には、負荷制御装置１００は、サーバ２００から受信したレスポンスデータをレスポンスバッファ１１２に蓄積する。このとき、クライアント装置３００へのレスポンスデータの送信完了を待つ必要がない。ゆえに、負荷制御装置１００は、クライアント装置３００との送受信速度に依存しないで、高速にサーバ２００からレスポンスを受信できる。このようにリクエスト・レスポンスを負荷制御装置１００にて一時蓄積することによって、送受信速度が低いクライアント装置に起因するサーバのリクエスト実行時間の増加を解消できる。

サーバの効率を高めるためには、負荷制御装置１００において、常に受信したリクエスト・レスポンスの全体を一時蓄積できることが望ましい。しかし、現実には、物理的なメモリサイズの制限などから、負荷制御装置１００にて一時蓄積できるデータサイズが制限される。その結果、サーバ２００へのリクエスト送信完了前に、負荷制御装置１００にて一時蓄積していたリクエストデータが読み尽されたり（データ枯渇）、サーバ２００からのレスポンス受信途中にレスポンスデータを格納すべき空き領域がレスポンスバッファ１１２になくなったりする（バッファ溢れ）。これらの場合、図６のバッファ１１０に一時蓄積しない場合と同様に、負荷制御装置−サーバ間のリクエスト・レスポンスの送受信速度が、クライアント装置−負荷制御装置間の送受信速度によって制限される。

故に、本発明では、負荷制御装置１００が、クライアント装置−負荷制御装置間の送受信速度に制限されないで、応答待ちリクエストのリクエストデータ・レスポンスデータをサーバと送受信できるか否かを、判定手段１６１１，１７１１が負荷制御装置１００におけるリクエスト・レスポンスデータのバッファ１１０への蓄積状態に基づき判定する。ここで、サーバ２００とリクエスト・レスポンスの送受信速度が、クライアント装置−負荷制御装置の送受信速度によって制限されない場合、そのリクエストを高速クラスに属するとみなす。一方、サーバ２００とのリクエスト・レスポンスの送受信速度が、クライアント−負荷制御装置間の送受信速度によって制限される場合、そのリクエストを低速クラスに属すると見做す。そして、応答待ちリクエストの総数に加え、高速クラスに属する応答待ちリクエストの数、及び、低速クラスに属する応答待ちリクエストの数それぞれに閾値を設定する。

例えば、高速クラスの応答待ちリクエスト数の閾値を"２"、低速クラスの応答待ちリクエスト数の閾値を"１０"、及び、応答待ちリクエストの総数の閾値を"１１"とする。また、リクエストは、最初は高速クラスに属するものとする。そして、データ枯渇やバッファ溢れによってサーバ２００とのリクエスト・レスポンスの送受信速度が制限されると、そのリクエストを低速クラスに分類しなおす。

この場合、負荷制御装置１００からサーバに２つのリクエストを送信した時点で、高速クラスの応答待ちリクエスト数がその閾値に達する。閾値に達すると、負荷制御装置１００は、サーバ２００への次のリクエストの送信を待ち合わせる。データ枯渇やバッファ溢れが生じない限り、図４に示したシーケンスに従ってリクエストがサーバ２００で実行される。ここで、サーバ２００で実行されている応答待ちリクエストの一つに、データ枯渇、または、バッファ溢れが生じたとする。すると、その応答待ちリクエストが属するクラスは、判定手段１６１１によって高速クラスから低速クラスに変更される。このとき、高速クラスの応答待ちリクエストの数が"２"から"１"に減少する。その結果、高速クラスの応答待ちのリクエストの数がその閾値を下回るようになるため、負荷制御装置１００は、新しいリクエストをサーバ２００に対して送信する。すなわち、ある応答待ちリクエストにデータ枯渇やバッファ溢れが生じると、制御手段１５０により、リクエスト送信手段１６０に対して、別の新しいリクエストのサーバ２００への送信が促される。その結果、データ枯渇やバッファ溢れに伴うサーバの効率低下が、新しいリクエストの実行によって埋め合わせられる。

また、本発明では、判定手段１６１１，１７１１によって、リクエストが高速クラスに属するか、低速クラスに属するかによって、そのリクエストのリクエストデータのリクエストバッファ１１１、または、レスポンスデータのレスポンスバッファ１１２に蓄積できる最大サイズを変化させることができる。すなわち、サーバとのリクエスト・レスポンスの送受信速度が制限される低速クラスのリクエストのバッファリング可能な最大サイズを小さくすることによって、効率を落とすことなく負荷制御装置のメモリ使用量を削減できる。

以下に、負荷制御装置について詳細に説明する。

図８は、本発明の一実施の形態のシステム構成を示す。同図に示すシステムは、リクエストを発行する複数のクライアント装置３００と、リクエストに対応するレスポンスを返すサーバ２００、及び、リクエスト及びレスポンスを仲介する負荷制御装置１００から構成される。なお、サーバ２００は、Apacheなどのソフトウェアモジュールであってもよく、負荷制御装置１００とは物理リソースが独立であるハードウェアモジュールであってもよい。また、本発明の負荷制御装置１００を２つ以上のサーバに接続し、１つの負荷制御装置１００で複数のサーバ２００に対して負荷制御をしてもよい。さらに、負荷制御装置１００は、リバースプロキシ、Ｗｅｂアクセラレータ、Ｆｉｒｅｗａｌｌ、負荷分散システムなどの既存技術を拡張して実装してもよい。負荷制御装置１００にて、サーバ２００に送信開始済みであるが、サーバ２００からレスポンス全体が返されていない応答待ちリクエストの数を制限する。

説明の単純化のため、以下の仮定をおく。

・クライアント装置１００から送信されるリクエストと、サーバ２００におけるリクエストの処理結果であるレスポンスとは常に１対１に対応する。すなわち、リクエストの受信完了前にサーバ２００からレスポンスが返される、リクエストに対してレスポンスが返されない、または、一つのリクエストに対して複数のレスポンスが返される、といったことはないものとする。

・負荷制御装置１００では、１つのリクエスト（またはレスポンス）のうちバッファに蓄積できる最大サイズ（メッセージあたりの最大バッファサイズ）に上限を設ける。最大バッファサイズを記号Ｓで表す。

図９は、本発明の一実施の形態における負荷制御装置の構成を示す。

負荷制御装置１００は、主に、リクエストをクライアント装置３００から受信するためのリクエスト受信部１２０、リクエストキューを用いて受信したリクエストをスケジューリングするリクエストキュー制御部１５０、リクエストをサーバ２００に送信するためのリクエスト送信部１６０、サーバ２００で処理されたリクエストの結果であるレスポンスを受け取るためのレスポンス受信部１７０、クライアント装置３００にレスポンスを送信するためのレスポンス送信部１３０、リクエスト・レスポンスのデータを格納するためのバッファ１１０（リクエストバッファ１１１、レスポンスバッファ１１２）、及びリクエストキューを格納するメモリ１４０から構成される。

リクエスト受信部１２０は、複数のリクエスト受信処理部１２１を有する。

レスポンス送信部１３０は、複数のレスポンス送信処理部１３１を有する。

リクエスト送信部１６０は、複数のリクエスト送信処理部１６１を有し、各リクエスト送信処理部１６１は、それぞれクラス判定処理部１６１１を有する。

レスポンス受信部１７０は、複数のレスポンス受信処理部１７１を有し、各レスポンス受信処理部１７１は、それぞれクラス判定処理部１７１１を有する。

負荷制御装置１００は、リクエスト受信部１２０のリクエスト受信処理部１２１においてクライアント装置３００からリクエストを受信すると、クライアント装置−負荷制御装置間と、負荷制御装置−サーバ間の送受信速度差を吸収するため、受信したリクエストの全体、乃至は、一部をリクエストバッファ１１１に一時蓄積する。そして、リクエストバッファ１１１への一時蓄積が完了したリクエストをメモリ１４０のリクエストキューに登録する。リクエストキュー制御部１５０は、応答待ちリクエスト数の制限が解消するまで、リクエストの送信を待ち合わせるようにリクエスト送信処理部１６１を制御する。そして、メモリ１４０内の応答待ちリクエスト数の制限が解消されると、リクエスト送信処理部１６１に対してサーバ２００に対してリクエストを送信するよう制御する。

サーバ２００は、リクエストを実行すると、その結果をレスポンスとして負荷制御装置１００に返す。負荷制御装置１００は、返されたレスポンスをレスポンス受信部１７０のレスポンス受信処理部１７１において受信し、リクエストの受信時と同様に、レスポンスバッファ１１２に一時蓄積する。そして、レスポンス送信部１３０のレスポンス送信処理部１３１においてレスポンスバッファ１１２に蓄積されていたレスポンスを順次読み出して、対応するクライアント装置３００に送信する。

負荷制御装置１００のクラス判定処理部１６１，１７１は、リクエスト毎にそのリクエストデータ・レスポンスデータをサーバ２００と送受信する速度が、クライアント装置３００とリクエストデータ・レスポンスデータを送受信する速度によって制限されるか否かを、バッファ１１０におけるリクエスト・レスポンスの蓄積状態に基づき判定する。ここで、サーバ２００との送受信速度がクライアント装置３００との送受信速度によって制限されないリクエストは「高速クラス」に属するものとする。一方、サーバ２００との送受信速度がクライアント装置３００との送受信速度によって制限されるリクエストは「低速クラス」に属するものとする。ここで、「高速クラス」・「低速クラス」の判定例を以下に示す。

・クライアント装置３００からのリクエスト受信時は、全てのリクエストを「高速クラス」に属するとする（分類例１）。

・リクエストバッファ１１１に一時蓄積されている未送信リクエストデータのサイズが所定の閾値以下（本形態では"０"とする）となった時点で、そのリクエストを「低速クラス」に分類する（分類例２）。

・リクエストのレスポンス受信時にレスポンスバッファ１１２に空き領域が無くなった時点、すなわち、レスポンスバッファ１１２に一時蓄積されている未送信レスポンスデータが最大バッファサイズＳに達した時点で、対応するリクエストを「低速クラス」に分類する（分類例３）。

・サーバ２００へのリクエスト送信時にその全体がバッファリングされていないリクエストを「低速クラス」に分類する（分類例４）。

・リクエストやレスポンスのヘッダを解析し、そのメッセージサイズが最大バッファサイズを超えていることが判明した時点で、そのリクエストを「低速クラス」に分類する（分類例５）。

上記の分類方法は、自由に組み合わせて利用できるが、本形態では、分類例１〜３までを併用する場合について記述する。

図１０は、本発明の一実施の形態におけるクライアント装置からのリクエスト受信処理のフローチャートである。

まず、負荷制御装置１００のリクエスト受信処理部１２１は、クライアント装置３００からリクエストを受信する度に、リクエスト毎個別に起動される（ステップ１０１）。リクエスト受信処理部１２１では、リクエスト全体を受信するまで、または、リクエストバッファ１１１に蓄積される当該リクエストのリクエストデータの大きさが最大バッファサイズＳに達するまで（すなわち、バッファ溢れが生じるまで）、受信したリクエストデータをリクエストバッファ１１１に蓄積する（ステップ１０２、１０３）。バッファ溢れが生じることなく、リクエスト全体を受信できた場合には（ステップ１０４、Ｙｅｓ）、メモリ１４０のリクエストキューに当該リクエストを登録する（ステップ１０５，１０６）。そして、当該リクエストの受信処理を終了する。

一方、バッファ溢れが生じた場合には、空き領域がリクエストバッファ１１１にないため、クライアント装置３００から新たにリクエストデータを受信できなくなる。ゆえに、当該リクエストのサーバ２００への送信開始によってバッファ溢れが解消されるまで、当該リクエスト受信処理を停止させる。すなわち、当該リクエストをメモリ１４０のリクエストキューに格納した上で（ステップ１０７〜１０９）、バッファ溢れが解消するまでリクエスト受信処理を待ち合わせる（ステップ１１０）。後述する図１２に示すサーバ２００へのリクエスト送信処理によってバッファ溢れが解消すると、リクエスト受信処理部１２１は、サーバ２００へのリクエストデータの送信によって、リクエストバッファ１１１に生じた空き領域分だけ、クライアント装置３００からの残りのリクエストデータを受信する。これを、当該リクエストの全体を受信するまで繰り返す（ステップ１０２〜１０４、１０７，１０８，１１０）。リクエスト全体を受信すると（ステップ１０４，Ｙｅｓ）、既にリクエストキューへの登録が済んでいるため（ステップ１０５、Ｙｅｓ）、そのままリクエスト受信処理を終了する。

次に、リクエストキューの処理手順を説明する。

図１１は、本発明の一実施の形態におけるキュー制御部のフローチャートである。

図１０の処理でリクエストバッファ１１１に蓄積されたリクエストは、メモリ１４０のリクエストキューに格納される。キュー制御部１５０は、リクエスト送信処理部１６１に対して、応答待ちリクエスト数の制限が解消されるまでリクエストの送信を待ち合わせるよう制御する。ここで、本実施の形態では、応答待ちリクエスト数の制限として、以下を設けている。

・応答待ちリクエストの総数は、閾値Ｌ１以下でなければならない（制限１）。

・高速クラスの応答待ちリクエストの数は、閾値Ｌ２以下でなければならない（制限２）。

・低速クラスの応答待ちリクエストの数には制限を設けない。すなわち、その閾値を∞とする。

ここで、Ｌ１＞Ｌ２とする。これにより、応答待ちリクエスト数の総数がＬ１に達しない限りは同時にＬ２個の高速クラスの応答待ちリクエストをサーバ２００で実行させることができる。

図１１に示すキュー制御部１５０の処理は、負荷制御装置１００毎に１つ起動される。まず、キュー制御部１５０は、リクエスト受信処理部１２１を通じてメモリ１４０のリクエストキューに新たなリクエストが登録されるまで、または、負荷制御装置１００の応答待ちリクエスト数に変化が生じるまで、その実行を待ち合わせる（ステップ２０１）。ここで、応答待ちリクエスト数に変化が生じる事象として、サーバ２００からのレスポンス受信完了に伴う応答待ちリクエスト数の総数の変化（図１３：ステップ４０４）、リクエストが属するクラスの変更に伴うクラス別の応答待ちリクエスト数の変化がある（図１２：ステップ３０４、図１３：ステップ４０７，４０４）。リクエストキューへの登録、応答待ちリクエスト数の変化が生じると、まず、キュー制御部１５０は、リクエストキューにリクエストが存在するか否かを検証する（ステップ２０２）。リクエストが存在しないならば、ステップ２０１に移行し、その実行を待ち合わせる。

リクエストが存在するならば、次に、応答待ちリクエストの総数が閾値Ｌ１より小さいか検証する［制限１］（ステップ２０３）。［制限１］が解消されている場合は、次に、高速クラスの応答待ちリクエストの数が閾値Ｌ２より小さいか否かを検証する［制限２］（ステップ２０４）。［制限１］、［制限２］の一方でも解消されていない場合は（ステップ２０２、２０３、Ｎｏ）、再び、ステップ２０１に移行し、その実行を待ち合わせる。

［制限１］、［制限２］が共に解消されている場合は、キュー制御部１５０は、リクエストキューから、サーバ２００に送信すべきリクエストを１つ取り出す(ステップ２０５)。このとき、応答待ちリクエストの総数、及び、高速クラスのリクエストの応答待ちリクエストの数をそれぞれ１インクリメントする。そして、当該リクエストをサーバ２００に送信するためのリクエスト送信処理部１６１、当該リクエストに対するレスポンスをサーバ２００から受信するためのレスポンス受信処理部１７１、そして、サーバ２００から受信したレスポンスをクライアント装置３００に送信するためのレスポンス送信処理部１３１をそれぞれ起動する（ステップ２０６）。各処理の起動を完了すると、再び、ステップ２０１に移行し、応答待ちリクエスト数の制限が解消されるまで、リクエスト送信処理部１６１に対して次のリクエスト送信を待ち合わせるよう制御する。

次に、リクエスト送信処理について説明する。

図１２は、本発明の一実施の形態におけるリクエスト送信処理のフローチャートである。

リクエスト送信処理部１６１は、キュー制御部１５０からの制御により、メモリ１４０のリクエストキューから取り出したリクエストをリクエストバッファ１１１から読み出してサーバ２００に対して送信する。リクエスト送信処理部１６１は、キュー制御部１５０からリクエストキューによってリクエスト毎に起動される。

リクエスト送信処理部１６１は、まず、サーバ２００に対してリクエストを送信可能となるまで待ち合わせる（ステップ３０１）。例えば、ＴＣＰでは、サーバ２００から返されるＡＣＫのウィンドウサイズによってサーバ２００にリクエストを送信できるか否かを判定する。サーバ２００へのリクエスト送信が可能になると、クラス判定処理部１６１１において、リクエストバッファ１１１に当該リクエストの未送信リクエストデータが一時蓄積されているか否かを判定する（ステップ３０２）。未送信リクエストデータがない場合は（ステップ３０２、Ｎｏ）、サーバ２００へのリクエスト送信速度がクライアント装置３００からのリクエスト受信速度によって制限されることを意味する（すなわち、データ枯渇）。ゆえに、クラス判定処理部１６１１は、当該リクエストのクラスを高速クラスから低速クラスに変更する（ステップ３０３，３０４）。このとき、高速クラスの応答待ちリクエスト数を１デクリメントし、低速クラスの応答待ちリクエスト数を１インクリメントする。そして、当該リクエストの未送信リクエストデータがリクエストバッファ１１１に蓄積されるまで待ち合わせる（ステップ３０５）。リクエストバッファ１１１に当該リクエストの未送信リクエストデータがある場合は（ステップ３０２、Ｙｅｓ）、リクエストバッファ１１１からリクエストデータを読出し（ステップ３０６）、サーバ２００に対して送信する（ステップ３０７）。このとき、図１０のリクエスト受信処理において、バッファ溢れによって当該リクエストの受信が停止していた場合は、その受信が再開される。サーバ２００にリクエスト全体を送信した時点で（ステップ３０８、Ｙｅｓ）、当該リクエスト送信処理を終了する。

次に、サーバ２００からレスポンスを受信するレスポンス受信部１７０におけるレスポンス受信処理について説明する。

図１３は、本発明の一実施の形態におけるレスポンス受信処理のフローチャートである。

レスポンス受信処理部１７１は、リクエストキューによってリクエスト毎に起動される。レスポンス受信処理部１７１は、サーバ２００からレスポンス全体を受信するまで、または、レスポンスバッファ１１２に蓄積された未処理レスポンスデータの大きさが最大バッファサイズＳに達する（すなわちバッファ溢れが生じる）まで、受信したレスポンスデータをレスポンスバッファ１１２に蓄積していく（ステップ４０１，４０２）。バッファ溢れが生じた場合は、クライアント装置３００に対するリクエストデータの送信によってリクエストバッファ１１１に空きが生じるまで、サーバ２００からレスポンスが受信できなくなる。すなわち、サーバ２００から当該レスポンスの受信速度が、クライアント装置３００へのレスポンス送信速度によって制限される。故に、クラス判定処理部１７１１は、当該レスポンスに対応するリクエストが属するクラスを「高速クラス」から「低速クラス」に変更する（ステップ４０６、Ｙｅｓ，４０７）。このとき、高速クラスの応答待ちリクエスト数を１デクリメントし、低速クラスの応答待ちリクエスト数を１インクリメントする。そして、当該レスポンスデータのクライアント装置３００への送信によってバッファ溢れが解消するまで、レスポンス受信処理を中断する（ステップ４０８）。

レスポンス全体の受信が完了した時点で（ステップ４０３、Ｙｅｓ）、レスポンス受信完了処理を行う（ステップ４０４）。すなわち、応答待ちリクエストの総数を１デクリメントする。また、レスポンス受信が完了したリクエストが属するクラスの応答待ちリクエスト数を１デクリメントする。最後に、当該レスポンス受信処理を終了する。

次に、レスポンス送信処理について説明する。

図１４は、本発明の一実施の形態におけるレスポンス送信処理のフローチャートである。

レスポンス送信処理部１３１は、リクエストキューによってリクエスト毎に起動される。そして、クライアント装置３００にレスポンスデータを送信可能である限り、レスポンスバッファ１１２に蓄積されているレスポンスデータを読出し、クライアント装置３００に送信する。

まず、レスポンス送信部１３０のレスポンス送信処理部１３１は、クライアント装置３００へのレスポンス送信が可能となるまで待ち合わせる（ステップ５０１）。ここで、クライアント装置３００にレスポンスデータを送信可能であるか否かは、例えば、クライアント装置３００から返されるTCP ACKに示されるウィンドウサイズによって判定できる。

次に、レスポンスバッファ１１２中にクライアント装置３００への送信すべき未送信のレスポンスデータが蓄積されているか否かを判定する（ステップ５０２）。レスポンスバッファ１１２にレスポンスデータが蓄積されていないならば（ステップ５０２、Ｎｏ）、サーバ２００からのレスポンスデータの受信によって、レスポンスバッファ１１２に続きのレスポンスデータが蓄積されるまで、その実行を待ち合わせる（ステップ５０３）。

次に、レスポンスバッファ１１２に蓄積されているレスポンスデータを読出し（ステップ５０４）、クライアント装置３００に送信する（ステップ５０５）。このとき、図１３のレスポンス受信処理において、バッファ枯渇によって当該レスポンスのサーバ２００からの受信を停止していたならば、その受信が再開される。

最後に、当該レスポンスの全体をクライアント装置３００に送信した時点で（ステップ５０６、Ｙｅｓ）、レスポンス送信処理を終了する。

これまでの説明では、リクエスト、または、レスポンスあたりの最大バッファサイズを一律Ｓとしてきた。しかし、最大バッファサイズを、リクエストが属するクラス毎に変更してもよい。例えば、高速クラスの最大バッファサイズをＳ１とし、低速クラスの最大バッファサイズをＳ２とする。このとき、Ｓ１＞Ｓ２となるように設定することによって、送受信速度が制限されている低速クラスのリクエスト・レスポンスをバッファ１１０に蓄積するために、負荷制御装置１００のメモリが浪費されることを防ぐ。

なお、上記の負荷制御装置１００の構成要素をプログラムとして構築し、負荷制御装置として利用されるコンピュータにインストールするまたは、ネットワークを介して流通させることが可能である。

また、構築されたプログラムを、ハードディスクや、フレキシブルディスク・ＣＤ−ＲＯＭ等の可搬記憶媒体に格納して、コンピュータにインストールする、または、配布することが可能である。

なお、本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において種々変更・応用が可能である。

本発明は、サーバの過剰リクエストを防止するための装置としてクライアント装置−サーバ間に配置される、１つまたは複数のサーバと接続される装置、またはリバースプロキシ、Ｗｅｂアクセラレータ、Ｆｉｒｅｗａｌｌ、負荷分散システム等に適用可能である。

本発明の原理構成図である。 本発明の原理を説明するための図である。 本発明の負荷制御装置における概要動作を示す図（応答待ちリクエスト数の制限（閾値を１とした場合））である。 本発明の負荷制御装置における概要動作を示す図（応答待ちリクエスト数の制限（閾値を２とした場合））である。 一時蓄積しない場合のメッセージ転送（高速クライアント）を示す図である。 一時蓄積しない場合のメッセージ転送（低速クライアント）を示す図である。 本発明の負荷制御装置における概要動作を示す図（一時蓄積する場合のメッセージ転送（低速クライアント））である。 本発明の一実施の形態におけるシステム構成図である。 本発明の一実施の形態における負荷制御装置の構成図である。 本発明の一実施の形態におけるクライアント装置からのリクエスト受信処理のフローチャートである。 本発明の一実施の形態におけるキュー制御部のフローチャートである。 本発明の一実施の形態におけるリクエスト送信処理のフローチャートである。 本発明の一実施の形態におけるレスポンス受信処理のフローチャートである。 本発明の一実施の形態におけるレスポンス送信処理のフローチャートである。 リクエスト過剰によるＷｅｂサーバの処理性能の低下を示す実験結果である。

符号の説明

１００ 負荷制御装置
１１０ バッファ
１１１ リクエストバッファ
１１２ レスポンスバッファ
１２０ リクエスト受信手段、リクエスト受信部
１２１ リクエスト受信処理部
１３０ レスポンス送信手段、レスポンス送信部
１３１ レスポンス送信処理部
１４０ メモリ（リクエストキュー）
１５０ 制御手段、キュー制御部
１６０ リクエスト送信手段、リクエスト送信部
１７０ レスポンス受信手段、レスポンス受信部
２００ サーバ
３００ クライアント装置
１２１ リクエスト受信処理部
１３１ レスポンス送信処理部
１６１ リクエスト送信処理部
１７１ レスポンス受信処理部
１６１１ クラス判定処理部
１７１１ クラス判定処理部

Claims (13)

1. クライアント装置とサーバとの間に配置され、該クライアント装置からリクエストを受信するリクエスト受信手段と、該リクエストを該サーバに送信するリクエスト送信手段と、該リクエストに対して該サーバから返却されるレスポンスを受信するレスポンス受信手段と、該レスポンスを該クライアント装置に送信するレスポンス送信手段と、を有する負荷制御装置であって、
   前記クライアント装置から受信したリクエストデータを前記サーバに送信するまで一時蓄積するリクエストバッファと、
   前記サーバから受信したレスポンスデータを前記クライアント装置に送信するまで一時蓄積するレスポンスバッファと、
   応答待ちリクエストのリクエストデータまたはレスポンスデータを前記サーバと送受信する速度が、前記クライアント装置と該リクエストデータまたは該レスポンスデータを送受信する速度によって制限されるか否かを、前記リクエストバッファのリクエストデータ及び前記レスポンスバッファのレスポンスデータの蓄積状態に基づいて判定する判定手段と、
   応答待ちのリクエストの総数、前記判定手段で前記サーバとの送受信速度が制限されると判定された応答待ちリクエストの数、及び該判定手段で該サーバとの送受信速度が制限されないと判定された応答待ちリクエストの数が、それぞれに設けられている閾値を下回るまで、該サーバへの新たなリクエスト送信を待ち合わせるよう前記リクエスト送信手段を制御する制御手段と、
   を有し、
   前記サーバに送信開始済みであるが、該サーバからレスポンス全体が返却されていない応答待ちリクエストの数を制限することを特徴とする負荷制御装置。
2. 前記判定手段は、
   前記サーバへのリクエスト送信完了前に、前記リクエストバッファに蓄積されている当該リクエストのリクエストデータのサイズが所定の閾値以下となった場合に、該サーバとの送受信速度が制限されると判定する手段を含む
   請求項１記載の負荷制御装置。
3. 前記判定手段は、
   前記サーバからのレスポンス受信完了前に、前記レスポンスバッファに蓄積されているレスポンスデータのサイズが所定の閾値に達した場合に、該サーバとの送受信速度が制限されると判定する手段を含む
   請求項１記載の負荷制御装置。
4. 前記制御手段は、
   リクエスト全体が前記リクエストバッファに蓄積されていること、または、該バッファに蓄積されているリクエストデータの大きさが所定の閾値以上であることを、前記サーバにリクエスト送信するための必要条件とする
   請求項１記載の負荷制御装置。
5. 前記判定手段は、
   前記リクエストのリクエストデータまたは、該リクエストに対するレスポンスデータを前記サーバと送受信する速度が、前記クライアント装置と前記リクエストデータまたはレスポンスデータを送受信する速度によって制限されると判定された場合に、前記リクエストバッファに蓄積できるリクエストデータの最大サイズを変化させる手段を含む
   請求項１記載の負荷制御装置。
6. 前記判定手段は、
   前記リクエストのリクエストデータまたは、該リクエストに対するレスポンスデータを前記サーバと送受信する速度が、前記クライアント装置と前記リクエストデータまたはレスポンスデータを送受信する速度によって制限されると判定された場合に、前記レスポンスバッファに蓄積できるレスポンスデータの最大サイズを変化させる手段を含む
   請求項１記載の負荷制御装置。
7. クライアント装置とサーバとの間に配置され、該クライアント装置から受信したリクエストを該サーバに送信し、該リクエストに対して該サーバから返却されるレスポンスを該クライアント装置に送信する装置における、過剰リクエストを回避させるための負荷制御方法であって、
   クライアント装置とサーバとの間に配置され、該クライアント装置からリクエストを受信するリクエスト受信手段と、該リクエストを該サーバに送信するリクエスト送信手段と、該リクエストに対して該サーバから返却されるレスポンスを受信するレスポンス受信手段と、該レスポンスを該クライアント装置に送信するレスポンス送信手段と、判定手段及び制御手段とを有する負荷制御装置が、
   前記リクエスト受信手段が、前記クライアント装置から受信したリクエストデータを前記サーバに送信するまで一時リクエストバッファに蓄積し、
   前記レスポンス受信手段が、前記サーバから受信したレスポンスデータを前記クライアント装置に送信するまで一時レスポンスバッファに蓄積している状況において、
   前記判定手段が、応答待ちリクエストのリクエストデータまたはレスポンスデータを前記サーバと送受信する速度が、前記クライアント装置と該リクエストデータまたは該レスポンスデータを送受信する速度によって制限されるか否かを、前記リクエストバッファのリクエストデータ及び前記レスポンスバッファのレスポンスデータの蓄積状態に基づいて判定する判定ステップと、
   前記制御手段が、応答待ちのリクエストの総数、前記判定ステップにおいて前記サーバとの送受信速度が制限されると判定された応答待ちリクエストの数、及び該判定ステップにおいて該サーバとの送受信速度が制限されないと判定された応答待ちリクエストの数が、それぞれに設けられている閾値を下回るまで、該サーバへの新たなリクエスト送信を待ち合わせるよう前記リクエスト送信手段を制御する制御ステップと、を行い、
   前記サーバに送信開始済みであるが、該サーバからレスポンス全体が返却されていない応答待ちリクエストの数を制限することを特徴とする負荷制御方法。
8. 前記判定ステップにおいて、
   前記サーバへのリクエスト送信完了前に、前記リクエストバッファに蓄積されている当該リクエストのリクエストデータのサイズが所定の閾値以下となった場合に、該サーバとの送受信速度が制限されると判定するステップを行う
   請求項７記載の負荷制御方法。
9. 前記判定ステップにおいて、
   前記サーバからのレスポンス受信完了前に、前記レスポンスバッファに蓄積されているレスポンスデータのサイズが所定の閾値に達した場合に、該サーバとの送受信速度が制限されると判定するステップを行う
   請求項７記載の負荷制御方法。
10. 前記制御ステップにおいて、
    リクエスト全体が前記リクエストバッファに蓄積されていること、または、該バッファに蓄積されているリクエストデータの大きさが所定の閾値以上であることを、前記サーバにリクエスト送信するための必要条件とする
    請求項７記載の負荷制御方法。
11. 前記判定ステップにおいて、
    前記リクエストのリクエストデータまたは、該リクエストに対するレスポンスデータを前記サーバと送受信する速度が、前記クライアント装置と前記リクエストデータまたはレスポンスデータを送受信する速度によって制限されると判定された場合に、前記リクエストバッファに蓄積できるリクエストデータの最大サイズを変化させるステップを行う
    請求項７記載の負荷制御方法。
12. 前記判定ステップにおいて、
    前記リクエストのリクエストデータまたは、該リクエストに対するレスポンスデータを前記サーバと送受信する速度が、前記クライアント装置と前記リクエストデータまたはレスポンスデータを送受信する速度によって制限されると判定された場合に、前記レスポンスバッファに蓄積できるレスポンスデータの最大サイズを変化させるステップを行う
    請求項７記載の負荷制御方法。
13. 請求項１乃至６のいずれか１項に記載の負荷制御装置を構成する各手段としてコンピュータを機能させる負荷制御プログラム。

Images