JP4722150B2 - クライアントサーバシステム - Google Patents

Description

この発明は、主にＬＡＮやＷＡＮなどのネットワークを介してクライアント及びサーバを用いて情報処理を行うクライアントサーバシステムに関するものである。

ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）やＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）などのネットワークを介して、複数の利用者が同じデータ・サービスの提供を受ける必要がある場合、クライアントサーバシステムを構築するのが一般的である。ここでは、複数のクライアントからの要求をリアルタイムに処理し、結果を返信する専用のサーバを用意することで、データやサービスなどの一元管理を行うことができ、無駄を省くことができる。現在では、クライアント、サーバ間は、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）、ＦＴＰ（ｆｉｌｅ ｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌ）、ＨＴＴＰ（ｈｙｐｅｒ ｔｅｘｔ ｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌ）などのプロトコルが多く採用されており、Ｗｅｂサーバ、プリンタサーバ、メールサーバなどの様々な用途のサーバが構築されている。
クライアント、サーバは、共に汎用コンピュータで構築され、各々の装置内にはＣＰＵ（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）、メモリ、ＨＤＤ（ｈａｒｄ ｄｉｓｋ ｄｒｉｖｅ）、ネットワークカードなどを備える。また、クライアントに比べ、サーバは負荷が集中しやすいことから、サーバにはよりハイスペックなＣＰＵ、メモリ、ＨＤＤ、ネットワークカードを持つコンピュータを選定するのが一般的である。
現在、クライアントサーバシステムは、ＬＡＮネットワークのように閉じられたエリアのシステムだけでなく、ＷＡＮなどの公開されたシステムなど、様々な環境で採用されている。

一方で、ユーザ数、対象データ量、各種サービスの増加に伴い、サーバ側のアクセス、トラフィックが増加し、レスポンスの悪化やサーバダウン時の対策が必要となっている。
上記対策として、ある機能を複数のサーバで分担することで、耐障害性の向上や高負荷時のレスポンス向上に対応したり、機能単位でサーバを用意することで負荷分散を行う方法などがある。
さらに高度なサーバの負荷分散の方法としては、ドメイン名の問合せに対して、同一機能を持つ複数のサーバのうちで、最も負荷が軽いと推定できるＩＰアドレスを応答することで負荷分散を行うＤＮＳラウンドロビン、複数のサーバのＩＰをまとめ１つの仮想ＩＰアドレスへの問合せに対して、サーバを振り分けることで、負荷分散を行う負荷分散装置（ロードバランサ）、プロトコルヘッダ内のポート番号やシーケンス番号を書き換えることで、負荷分散を行うＬ４スイッチの使用などが挙げられる。
また、特許文献１には、サーバのＣＰＵ使用率を含むリソース使用率を取得し、上限値以上の場合に他のサーバに業務を分散することで、負荷分散する技術が記載されている。

特開２００５−１８２６４１号公報（第５〜８頁、図１）

クライアントサーバシステムでは、多数のクライアントからの要求が同時に発生した場合、ネットワークやサーバのＣＰＵなどがボトルネックとなり、応答時間が遅延することによりリアルタイム性が確保できないという問題がある。そこで、背景技術に示すように負荷を分散させる様々な方法が考えられ、実装されている。
リアルタイム性を必要とする処理が、同時期に集中するような場合、コマンドに優先度をつけ、優先順位の高いコマンドから実行することで、優先度の高いコマンドへの応答時間を改善する工夫がなされる。しかし、この場合でも、優先順位が高いコマンドが連続してある場合には、リアルタイム性を確保できないという問題が生じる。
また、特許文献１のものでは、コマンドによって消費するリソースは様々であり、これに対応していないという問題がある。コマンドによって消費するリソースは様々であり、どのリソースがボトルネックになるかを判断して、それを回避するようなスケジューリングを行う必要がある。

この発明は、上述のような課題を解決するためになされたものであり、各コマンドのリソース使用率を考慮した効率的な負荷分散を行うことができるクライアントサーバシステムを得ることを目的にしている。

この発明に係わるクライアントサーバシステムにおいては、サーバ及び複数のクライアントによって構成され、クライアントからサーバにコマンドを送信し、サーバがコマンドを実行してクライアントに応答を行うクライアントサーバシステムにおいて、コマンド及び応答を中継するよう構成され、予めサーバのコマンドごとのリソース使用率を取得しておくとともに、サーバのリソース使用率をモニタし、現在のリソース使用率及びこの現在のリソース使用率に応じるように各リソースを重み付けした重み係数及びコマンドごとのリソース使用率をリソースごとに乗算し、乗算結果を合計した値を優先度として、クライアントから送信されるコマンドについて優先度を算出し、この算出した優先度の小さい順にコマンドをサーバへ送信するコマンド解析／リソース監視サーバを備えたものである。

この発明は、以上説明したように、サーバ及び複数のクライアントによって構成され、クライアントからサーバにコマンドを送信し、サーバがコマンドを実行してクライアントに応答を行うクライアントサーバシステムにおいて、コマンド及び応答を中継するよう構成され、予めサーバのコマンドごとのリソース使用率を取得しておくとともに、サーバのリソース使用率をモニタし、現在のリソース使用率及びこの現在のリソース使用率に応じるように各リソースを重み付けした重み係数及びコマンドごとのリソース使用率をリソースごとに乗算し、乗算結果を合計した値を優先度として、クライアントから送信されるコマンドについて優先度を算出し、この算出した優先度の小さい順にコマンドをサーバへ送信するコマンド解析／リソース監視サーバを備えたので、同じリソースばかりを消費してボトルネックとなるケースを軽減することで、サーバの応答時間を改善することができる。

実施の形態１．
図１は、この発明の実施の形態１によるクライアントサーバシステムを示す構成図である。
図１において、ＬＡＮ１０９に接続されたクライアント（クライアント端末）１０５〜１０７から、ＬＡＮ１０８に接続されたサーバ１０１〜１０３への、ＬＡＮ／ＷＡＮ１１０などを介するコマンド発行と、サーバ１０１〜１０３からクライアント１０５〜１０７への応答の際、常にコマンド解析／リソース監視サーバ１０４を経由するようなシステムを構成する。
ここでサーバ１０１〜１０３は、それぞれ異なる機能を実装したサーバであっても、負荷分散のために同じ機能を持つサーバであっても構わない。
コマンド解析／リソース監視サーバ１０４は、複数のクライアントから同時にコマンドを受信した際、コマンド受信バッファにコマンドを蓄積する。
そして、各コマンドのリソース使用率を、運用開始前に、各コマンド実行時のサーバのリソース使用率および応答データ処理時のクライアントのリソース使用率を取得し、予めデータベース（以下、リソース使用率ＤＢ）化しておく。

図２は、この発明の実施の形態１によるクライアントサーバシステムのコマンド解析／リソース監視サーバを示す構成図である。
図２において、リソース使用率取得手段１３は、サーバ及びクライアントのリソース使用率を取得する。リソース使用率ＤＢ作成手段１１は、リソース使用率取得手段１３によって取得されたリソース使用率に基づき、予めリソース使用率ＤＢ１２を作成する。受信処理手段１４は、受信したコマンドについて、リアルタイム性を判断して、リアルタイム性のあるものをリアルタイムコマンド受信バッファ１５に蓄積し、リアルタイム性のないものを非リアルタイムコマンド受信バッファ１６に蓄積する。
コマンドリソース使用率対応表作成手段１７は、リアルタイムコマンド受信バッファ１５に蓄積されたコマンドについて、そのコマンドが必要とするリソースをリソース使用率ＤＢ１２から取得し、コマンドリソース使用率対応表を作成する。優先度算出手段１８は、コマンドリソース使用率対応表と現在のサーバのリソース使用率に基づき、リアルタイムコマンド受信バッファ１５に蓄積されたコマンドについてそれぞれ優先度を算出する。そして、送信処理手段１９は、優先度にもとづき、リアルタイムコマンド受信バッファ１５に蓄積されたコマンドを順次、送信する。
なお、上述の説明では、クライアントからの受信コマンドについてはサーバのリソース使用率を取得して優先度を算出するものとして説明したが、サーバからのコマンド応答についても、同様にしてクライアントのリソース使用率を取得して優先度を算出する。

図３は、この発明の実施の形態１によるクライアントサーバシステムのコマンド解析／リソース監視サーバのリソース使用率ＤＢ作成フローを示すフローチャートである。

図４は、この発明の実施の形態１によるクライアントサーバシステムのコマンド解析／リソース監視サーバの受信コマンドのリソース使用率対応表を示す図である。
図４において、サーバごと、かつ受信コマンドごとに、サーバのＣＰＵ使用率、メモリ使用率、ＨＤＤ使用率、ネットワーク使用率を示している。

図５は、この発明の実施の形態１によるクライアントサーバシステムのコマンド解析／リソース監視サーバのコマンド応答のリソース使用率対応表を示す図である。
図５において、クライアントごと、かつコマンド応答ごとに、クライアントのＣＰＵ使用率、メモリ使用率、ＨＤＤ使用率、ネットワーク使用率を示している。

図６は、この発明の実施の形態１によるクライアントサーバシステムのコマンド解析／リソース監視サーバの処理フローを示すフローチャートである。

図７は、この発明の実施の形態１によるクライアントサーバシステムの重み係数と現在のリソース使用率との関係を示す図である。
図７において、縦軸を重み係数、横軸を現在のリソース使用率として、重み係数と現在のリソース使用率との指数関数的な関係を示している。

次に、動作について説明する。
コマンド解析／リソース監視サーバ１０４は、各サーバ１０１〜１０３のＣＰＵ、メモリ、ＨＤＤ、ネットワークなどのリソース使用状況をリアルタイムで監視し、各コマンドがどのリソースをどれだけ使用するかを図３のフローに従い、事前にリソース使用率ＤＢに登録しておく。
そして、受信バッファにあるコマンドのうち、どのコマンドから先に実行するかをスケジューリングすることで、ボトルネックを回避する。つまり、特定のリソースばかりを消費しないようにコマンド実行順序を決定する。

次に、図３により、コマンド解析／リソース監視サーバ１０４のリソース使用率ＤＢ作成フローについて説明する。
まず、システムをアイドル状態にする（Ｓ１）。次に、アイドル時のＣＰＵ使用率、メモリ使用率をＯＳ提供の情報から取得する（Ｓ２）。次に、メモリをクリアする（Ｓ３）。次 いで、ＨＤＤ使用率測定用ファイルの読み込み時間を測定し、使用率を算出する（Ｓ４）。メモリをクリアする（Ｓ５）。Ｐｉｎｇを発行して、レスポンス時間を測定し、ネットワーク使用率を算出する（Ｓ６）。
Ｓ１〜Ｓ６は、コマンドごとのリソース使用率の取得のための準備段階であり、システムがアイドル状態でのリソース使用率を、すべてのサーバとクライアントについて取得しておく。

次いで、単発コマンドを発行する（Ｓ７）。サーバからの応答を受信するまで、定周期でサーバのＣＰＵ、メモリ、ＨＤＤ、ネットワーク使用率を取得する（Ｓ８）。取得したＣＰＵ、メモリ、ＨＤＤ、ネットワーク使用率の平均値を算出する（Ｓ９）。アイドル状態でのリソース使用率を基準にして、実行したコマンドのリソース使用率をリソース使用率ＤＢ１２へ登録する（Ｓ１０）。
クライアントへの応答データ送信時、定周期でクライアントのＣＰＵ、メモリ、ＨＤＤ、ネットワーク使用率を取得する（Ｓ１１）。取得したＣＰＵ、メモリ、ＨＤＤ、ネットワーク使用率の平均値を算出する（Ｓ１２）。アイドル状態でのリソース使用率を基準にして、応答データ処理時のリソース使用率をリソース使用率ＤＢ１２へ登録する（Ｓ１３）。
このようにして、予めリソース使用率ＤＢ１２を作成する。

次に、コマンド受信時のコマンド解析／リソース監視サーバ１０４の処理フローについて、図６により説明する。
コマンド受信（Ｓ２１）時、リアルタイム性が必要なＧＵＩ等からのコマンドと、クローンやバッチ処理などの定期的に実行される非リアルタイムコマンドかを判断し（Ｓ２２）、それぞれ異なる蓄積バッファを用意する。すなわち、リアルタイムコマンドの場合には、リアルタイムコマンド受信バッファに蓄積し（Ｓ２３）、非リアルタイムコマンドの場合には、非リアルタイムコマンド受信バッファに蓄積する（Ｓ２４）。
次に、複数のリアルタイムコマンドがバッファに蓄積されているかどうかを判断し（Ｓ２５）、リアルタイム性が必要なコマンドを複数受信していない場合は、リアルタイムコマンド、非リアルタイムコマンドの順にコマンドを実行する（Ｓ２６）。
また、リアルタイムコマンドを複数受信している場合は、受信バッファに蓄積した各コマンドのリソース使用率をリソース使用率ＤＢから取得する（Ｓ２７）。次いで、現在のサーバ、クライアントのＣＰＵ、メモリ、ＨＤＤ、ネットワーク使用率を取得する（Ｓ２８）。次いで、各コマンドのリソース使用率と重み係数からコマンド実行優先度を算出する（Ｓ２９）。優先度の高いコマンドから順番にサーバに送信する（Ｓ３０）。
なお、上記は受信コマンドについて説明したが、コマンド応答についても同様に処理する。

コマンド解析／リソース監視サーバ１０４における受信コマンドのリソース使用率対応表を図４に示す。図４で、サーバＡに着目すると、コマンドａ１〜ａ５の５つのコマンドを受信している。各コマンドのリソース使用率は、リソース使用率ＤＢを参照することで取得する。同様に、サーバからクライアントへのコマンド応答時のリソース使用率対応表を図５に示す。

ここで、現時点のサーバＡのＣＰＵ使用率ＮＣＲ、メモリ使用率ＮＭＲ、ＨＤＤ使用率ＮＨＲ、ネットワーク使用率ＮＮＲの算出情報について説明する。
リソース使用率の算出方法は、ＣＰＵ、メモリ使用率については、ＯＳの機能で実装されている場合が多く、容易に取得可能である。ＨＤＤ使用率については、特定ファイルへの読み書き時間の増減により使用率を算出し、ネットワーク使用率は、ＰＩＮＧ応答時間により使用率を算出する。

実行するコマンドのスケジューリングを行うには、コマンド優先度を算出する必要がある。コマンド優先度を算出するには、現時点のリソース使用率および各コマンドのリソース使用率、それぞれのリソースが影響を及ぼす度合いを示すための重み係数が必要となる。この重み係数は、現在のリソース使用率と図７に示すように指数関数的な関係を持ち、システム構成、運用方法などから決定、調整が必要となるパラメータである。
ここで、ＣＰＵ重み係数ＷＣ、メモリ重み係数ＷＭ、ＨＤＤ重み係数ＨＷ、ネットワーク重み係数ＮＷとすると、図４からコマンドａ１の優先度ａ１＿ｐは、式（１）により算出される。
ａ１＿ｐ ＝０．１＊ＮＣＲ＊ＷＣ＋０．０３＊ＮＭＲ＊ＷＭ＋０．０６＊ＮＨＲ＊ＷＨ＋０．０８＊ＮＮＲ＊ＷＮ ・・・（１）
同様にコマンドａ２〜ａ５の優先度ａ２＿ｐ〜ａ５＿ｐを求めることができる。コマンド優先度の値が小さいコマンドの優先度が高くなる。優先度の高いコマンドから順に実行することで、ボトルネックを回避できる。
同様の手法で、サーバからクライアントへの応答データ送信時の優先度も求められ、優先度の高い応答の順に実行することで、システム全体のボトルネックを回避することができる。

実施の形態１によれば、同じリソースばかりを消費してボトルネックとなるケースを軽減することで、サーバの応答時間を改善する。
また、同様の処理をサーバからクライアントへの応答時に適応することで、クライアント側のボトルネックを回避できる。
これにより、サーバ、クライアント共に、特定のリソース消費によるボトルネックを回避し、システム全体の効率化を図ることができる。

実施の形態２．
実施の形態１では、コマンド解析／リソース監視サーバは、独立したものとして説明したが、このコマンド解析／リソース監視サーバは、いずれかのサーバに組み込むことも可能である。
実施の形態２は、この場合についてのものである。すなわち、コマンド解析／リソース監視サーバは、通常のサーバの機能を有しているので、コマンド解析／リソース監視サーバのリソースにより処理できるコマンドについては、コマンド解析／リソース監視サーバでコマンドを実行し、クライアントに対して応答を行う。
この応答に際しては、クライアントのリソース使用率に基づいて、応答の優先度を算出し、算出した優先度にしたがって行うようにする。

実施の形態２によれば、コマンド解析／リソース監視サーバで実行できるコマンドについては、他のサーバに振り分ける必要がないので、より早いレスポンスを行うことができる。

実施の形態３．
実施の形態１では、コマンド解析／リソース監視サーバは、独立したものとして説明したが、このコマンド解析／リソース監視サーバを、すべてのサーバに組み込んだ場合が実施の形態３である。
実施の形態３では、すべてのサーバがコマンド解析／リソース監視サーバの機能を有している。各サーバは、自サーバのリソース使用率を把握しておき、これに基づいて、同時に受信したコマンドの優先度を求め、この優先度にしたがって、コマンドを実行して応答する。

実施の形態３によれば、コマンド解析／リソース監視サーバを設置する必要がなく、自サーバの受け付けたコマンドについて優先度順に実行することができる。

実施の形態４．
図８は、この発明の実施の形態４によるクライアントサーバシステムを示す構成図である。
図８において、１０１〜１０９は図１におけるものと同一のものである。図８では、データ／コマンド用ＬＡＮと別に設けられたリソース監視用ＬＡＮ１１１を介してコマンド解析／リソース監視サーバ１０４が監視を行うようになっている。コマンド解析／リソース監視サーバ１０４で、サーバ及びクライアントのリソース使用率を取得しておき、クライアントがコマンドの送信時、及びサーバがコマンド応答の送信時に、コマンド解析／リソース監視サーバ１０４からサーバまたはクライアントのリソース使用率を取得して、これに基づき、コマンドまたはコマンド応答を送信するようにした。

実施の形態４は、コマンド送信および応答用のネットワークと、リソース監視用のネットワークとの２種類のネットワークを用いている。
コマンド送信および応答用のネットワークは、通常の運用で使用しているネットワークであり、それとは別にリソース監視用のネットワークであるリソース監視用ＬＡＮ１１１を構築する。
すべてのサーバ、クライアントは、この２種類のネットワークに接続されている。一方、コマンド解析／リソース監視サーバ１０４は、リソース監視用ＬＡＮ１１１にだけ接続されており、サーバ／クライアントのリソース使用率をリアルタイムで監視する。
このような構成をとることで、ネットワークの負荷を軽減し、さらにはコマンド解析／リソース監視サーバ１０４の負荷を軽減できる。
この実施の形態４では、クライアントはコマンド解析／リソース監視サーバ１０４へ、リソース使用率を問い合わせることで、各サーバのリソース使用率を把握できる。この情報を元にして、コマンドを発行するサーバを切り替える、またはコマンド発行を遅らせる等のスケジューリングを実施することで、サーバの負荷を分散することができる。
サーバのコマンド応答も同様にして行われる。

実施の形態４によれば、リソース監視用のネットワークを別途設けたので、サーバ／クライアントのリソース使用率をリアルタイムで監視することができるとともに、ネットワークの負荷を軽減し、さらにはコマンド解析／リソース監視サーバ１０４の負荷を軽減できる。

この発明の実施の形態１によるクライアントサーバシステムを示す構成図である。 この発明の実施の形態１によるクライアントサーバシステムのコマンド解析／リソース監視サーバを示す構成図である。 この発明の実施の形態１によるクライアントサーバシステムのコマンド解析／リソース監視サーバのリソース使用率ＤＢ作成フローを示すフローチャートである。 この発明の実施の形態１によるクライアントサーバシステムのコマンド解析／リソース監視サーバの受信コマンドのリソース使用率対応表を示す図である。 この発明の実施の形態１によるクライアントサーバシステムのコマンド解析／リソース監視サーバのコマンド応答のリソース使用率対応表を示す図である。 この発明の実施の形態１によるクライアントサーバシステムのコマンド解析／リソース監視サーバの処理フローを示すフローチャートである。 この発明の実施の形態１によるクライアントサーバシステムの重み係数と現在のリソース使用率との関係を示す図である。 この発明の実施の形態４によるクライアントサーバシステムを示す構成図である。

符号の説明

１１ リソース使用率ＤＢ作成手段、１２ リソース使用率ＤＢ、
１３ リソース使用率取得手段、１４ 受信処理手段、
１５ リアルタイムコマンド受信バッファ、１６ 非リアルタイムコマンド受信バッファ、
１７ コマンドリソース使用率対応表作成手段、１８ 優先度算出手段、
１９ 送信処理手段、
１０１ サーバＡ、１０２ サーバＢ、１０３ サーバＣ、
１０４ コマンド解析／リソース監視サーバ、
１０５ クライアントＡ、１０６ クライアントＢ、１０７ クライアントＣ、
１０８ ＬＡＮ、１０９ ＬＡＮ、１１０ ＬＡＮ／ＷＡＮ、
１１１ リソース監視用ＬＡＮ。

Claims (5)

1. サーバ及び複数のクライアントによって構成され、上記クライアントから上記サーバにコマンドを送信し、上記サーバが上記コマンドを実行して上記クライアントに応答を行うクライアントサーバシステムにおいて、
   上記コマンド及び上記応答を中継するよう構成され、予め上記サーバのコマンドごとのリソース使用率を取得しておくとともに、上記サーバのリソース使用率をモニタし、現在のリソース使用率及びこの現在のリソース使用率に応じるように各リソースを重み付けした重み係数及び上記コマンドごとのリソース使用率をリソースごとに乗算し、乗算結果を合計した値を優先度として、上記クライアントから送信されるコマンドについて上記優先度を算出し、この算出した優先度の小さい順に上記コマンドを上記サーバへ送信するコマンド解析／リソース監視サーバを備えたことを特徴とするクライアントサーバシステム。
2. 上記コマンド解析／リソース監視サーバの上記リソース利用率データベースには、上記各クライアントの上記応答データ処理時のリソース使用率が応答ごとに予め格納され、
   上記コマンド解析／リソース監視サーバは、上記各クライアントのリソース使用率をモニタし、現在のリソース使用率及びこの現在のリソース使用率に応じるように各リソースを重み付けした重み係数及び上記リソース利用率データベースの上記応答ごとのリソース使用率をリソースごとに乗算し、乗算結果を合計した値を優先度として、上記サーバから送信される応答について上記優先度を算出し、この算出した優先度の小さい順に上記応答を上記クライアントへ送信することを特徴とする請求項１記載のクライアントサーバシステム。
3. サーバ及び複数のクライアントによって構成され、上記クライアントから上記サーバにコマンドを送信し、上記サーバが上記コマンドを実行して上記クライアントに応答を行うクライアントサーバシステムにおいて、
   上記サーバは、予め自サーバのコマンドごとのリソース使用率を取得しておくとともに、自サーバのリソース使用率をモニタし、現在のリソース使用率及び及びこの現在のリソース使用率に応じるように各リソースを重み付けした重み係数及び上記コマンドごとのリソース使用率をリソースごとに乗算し、乗算結果を合計した値を優先度として、上記クライアントから送信されるコマンドについて上記優先度を算出するコマンド解析／リソース監視サーバ機能を備え、
   上記コマンド解析／リソース監視サーバ機能によって算出された優先度の小さい順に上記コマンドを実行することを特徴とするクライアントサーバシステム。
4. サーバ及び複数のクライアントによって構成され、上記クライアントから上記サーバにコマンドを送信し、上記サーバが上記コマンドを実行して上記クライアントに応答を行うクライアントサーバシステムにおいて、
   予め各々の上記クライアントのコマンドごとのリソース使用率及び上記サーバの応答ごとのリソース使用率を取得しておくとともに、上記サーバ及び各々の上記クライアントのリソース使用率をモニタし、各々の上記クライアントまたは上記サーバからの問い合わせに応じて、現在のリソース使用率及び予め取得した上記サーバの応答ごとのリソース使用率または予め取得した各々の上記クライアントのコマンドごとのリソース使用率を回答するコマンド解析／リソース監視サーバを備え、
   各々の上記クライアントは、上記コマンド解析／リソース監視サーバから回答された上記現在のリソース使用率及び予め取得した上記サーバの応答ごとのリソース使用率に基づき、各々の上記クライアントが上記サーバに送信するコマンドをスケジューリングし、
   上記サーバは、上記コマンド解析／リソース監視サーバから回答された上記現在のリソース使用率及び予め取得した各々の上記クライアントのコマンドごとのリソース使用率に基づき、上記サーバが各々の上記クライアントに送信する応答をスケジューリングすることを特徴とするクライアントサーバシステム。
5. 上記コマンド解析／リソース監視サーバが、上記サーバ及びクライアントのリソース使用率をモニタするためのネットワークを、上記コマンド及びその応答を伝送するためのネットワークとは別に設けたことを特徴とする請求項４記載のクライアントサーバシステム。