JP3737560B2 - ネットワークにおける分散処理方法及びそのシステム - Google Patents
ネットワークにおける分散処理方法及びそのシステム Download PDFInfo
- Publication number
- JP3737560B2 JP3737560B2 JP09817496A JP9817496A JP3737560B2 JP 3737560 B2 JP3737560 B2 JP 3737560B2 JP 09817496 A JP09817496 A JP 09817496A JP 9817496 A JP9817496 A JP 9817496A JP 3737560 B2 JP3737560 B2 JP 3737560B2
- Authority
- JP
- Japan
- Prior art keywords
- client
- server
- time
- specific task
- task
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Computer And Data Communications (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、クライアントとサーバからなる分散処理方法及びそのシステムに関し、特に、タスク処理のターンアラウンド時間を短縮するための分散処理方式に関する。
【０００２】
【従来の技術】
近年、インタネット等に代表されるネットワーク通信技術の発達及びワークステーション等に代表される端末装置の高機能化に伴い、クライアント・サーバ形式による分散処理システムが一般化してきた。
クライアント・サーバ形式の分散処理システムを実現する第１の従来方式として、遠隔手続き呼出しによる方式（Remote Procedure Call、以下「ＲＰＣ方式」という。）がある。例えば、"Concurrent Systems"，Addison-Wesley,1992 に記載されている。ここで、クライアントとは、ある特定のタスク（以下、「特定タスク」という。）の処理を依頼するネットワーク上の端末をいい、サーバとは、その依頼を受けたネットワーク上の端末をいうが、ここでは必ずしもサーバがその特定タスクの処理を実行するとは限らないとする。
【０００３】
図９（ａ）はＲＰＣ方式におけるクライアントとサーバとの通信のやりとりを示す説明図であり、図９（ｂ）はそのシーケンス図である。
この方式は、大きく３つの手順からなる。即ち、（１）クライアントは、特定タスクの処理を依頼するためにサーバに処理依頼メッセージを送る。（２）サーバは、依頼されたその特定タスクを実行する。（３）実行し終えると、サーバは、その結果を通知するためにクライアントにリプライメッセージを返す。
【０００４】
例えば、クライアントがサーバに対して、サーバが持つデータベースに検索処理およびその結果をグラフイメージで返す処理を依頼し、その生成されたイメージ情報をクライアントが受け取る場合が該当する。この方式の長所は、比較的低価格の端末と通信手段によってシステム全体としては高度な処理が実行される点にある。
【０００５】
クライアント・サーバ形式の分散処理システムを実現する第２の従来方式として、タスク移動（マイグレーション）による方式がある。例えば、SUN microsystems社が提唱しているJAVA（"Hooked on Java",Addison-Wesley,1995 に記載）やNetscape社で提案されているもの等（以下、この方式を「ＪＡＶＡ方式」という。）がそうである。
【０００６】
図１０（ａ）はＪＡＶＡ方式におけるクライアントとサーバとの通信のやりとりを示す説明図であり、図１０（ｂ）はそのシーケンス図である。
この方式も、大きく３つの手順からなる。即ち、（１）クライアントは、特定タスクの処理を依頼するためにサーバに処理依頼メッセージを送る。（２）サーバは、処理手続きと必要データをパッケージした特定タスクの移動を行う。即ち、特定タスク本体をメッセージとして構築し、リプライメッセージとしてクライアントに返信する。（３）その特定タスクを受け取ったクライアントは、自らその特定タスクを実行する。
【０００７】
この方式の長所は、クライアントにタスク処理を行わせることにより、処理が集中しがちなサーバでの負荷を軽減させることができ、これによってシステム全体における負荷分散が図れるという点にある。
【０００８】
【発明が解決しようとする課題】
しかしながら、上記の従来方式では、クライアントやサーバでの負荷の変動に伴い、必ずしも、ターンアラウンド時間、即ち、処理の依頼が発生してからその処理結果を利用できる状態になるまでの時間が最小になるとは限らないという問題点がある。
【０００９】
図１１は、その問題点を説明するためのシステム構成を示すモデル図である。本図に示されるように、いま、システムの処理性能やデータ転送速度、負荷状況をモデル化することにより、以下の通り、各分散処理方式におけるターンアラウンド時間を評価する。
まず、各端末装置ごとに、現在処理されているタスクに新たに１個のタスクが加わった場合に、各タスクが処理される速度、即ち、実効処理速度を定義する。
【００１０】
クライアントの処理速度の最大値をＲcmax（仕事単位／秒）、クライアントで並行処理しているタスク数をＮc（個）とすると、クライアントの実効処理速度Ｒc（仕事単位／秒・タスク）は、
Ｒc＝Ｒcmax／（Ｎc＋１） ・・・ （式１）
で表されるものとし、同様に、
サーバの処理速度の最大値をＲsmax（仕事単位／秒）、サーバで並行処理しているタスク数をＮs（個）とすると、サーバの実効処理速度Ｒs（仕事単位／秒・タスク）は、
Ｒs＝Ｒsmax／（Ｎs＋１） ・・・ （式２）
で表されるものとする。
【００１１】
ここで、最大処理速度Ｒcmax、Ｒsmaxとは、各端末装置固有の処理能力を示す単位であり、各装置が有するＣＰＵのSPECmark等に相当し、仕事単位とは、タスクの処理サイズを表す単位であり、実効処理速度が１仕事単位／秒である装置が１秒間に処理できる正規化された演算量に相当する。
さらに、特定タスクの仕事量をＭtask（仕事単位）、通信路の通信速度をＲt（通信単位／秒）、依頼メッセージの通信量をＭcall（通信単位）、リプライメッセージの通信量をＭrep（通信単位）、タスク移動に伴う特定タスクの通信量をＭmig（通信単位）と定義する。
【００１２】
すると、ＲＰＣ方式におけるターンアラウンド時間Ｔrpc（秒）は、上述の３つの手順に対応する時間の合計になるので、
Ｔrpc＝Ｍcall／Ｒt＋Ｍtask／Ｒs＋Ｍrep／Ｒt ・・・ （式３）
と表され、
一方、ＪＡＶＡ方式におけるターンアラウンド時間Ｔjava（秒）も、上述の３つの手順に対応する時間の合計になるので、
Ｔjava＝Ｍcall／Ｒt＋Ｍmig／Ｒt＋Ｍtask／Ｒc ・・・ （式４）
と表される。
【００１３】
具体的な数値を用いて両方式でのターンアラウンド時間を評価すると、以下の通りである。
今、システムの性能として、クライアントの処理速度の最大値Ｒcmaxが４０、サーバの処理速度の最大値Ｒsmaxが１００、通信路の通信速度Ｒtが５であり、各通信量・仕事量として、特定タスクの仕事量Ｍtaskが２００、依頼メッセージの通信量Ｍcallが５、リプライメッセージの通信量Ｍrepが５、タスク移動に伴う特定タスクの通信量Ｍmigが１００であるとする。
【００１４】
そして、第１の負荷状況として、クライアントで並行処理しているタスク数Ｎcが１、サーバで並行処理しているタスク数Ｎsが１９の場合を考える。
式１及び式２より、クライアント及びサーバの実効処理速度Ｒc及びＲsは、
Ｒc＝４０／（１＋１）＝２０
Ｒs＝１００／（１９＋１）＝５
となるので、式３及び式４より、ＲＰＣ方式及びＪＡＶＡ方式におけるターンアラウンド時間Ｔrpc及びＴjavaは、
Ｔrpc＝５／５＋２００／５＋５／５＝４２（秒）
Ｔjava＝５／５＋１００／５＋２００／２０＝３１（秒）
となる。図１２は、この結果をタイムチャートで示したものである。
【００１５】
以上より、この第１の負荷状況においては、ＪＡＶＡ方式による場合の方がＲＰＣ方式に比べてターンアラウンド時間が小さくなるので、ＪＡＶＡ方式がより好ましい分散処理方式と言える。
続いて、サーバで並行処理しているタスク数Ｎsがそれまでの１９から９に減少した第２の負荷状況を考える。
【００１６】
第１の負荷状況の場合と同様に算出すると、クライアントの実効処理速度Ｒcは２０のまま変動しないが、サーバの実効処理速度Ｒsは、
Ｒs＝１００／（９＋１）＝１０
と増加するので、ＲＰＣ方式におけるターンアラウンド時間Ｔrpcは、
Ｔrpc＝５／５＋２００／１０＋５／５＝２２（秒）
と減少する。一方、ＪＡＶＡ方式におけるターンアラウンド時間Ｔjavaは３１秒のまま変動しない。図１３は、この結果をタイムチャートで示したものである。
【００１７】
以上より、この第２の負荷状況においては、第１の負荷状況の場合と異なり、ＲＰＣ方式による場合の方がＪＡＶＡ方式に比べてターンアラウンド時間が小さくなるので、ＲＰＣ方式がより好ましい分散処理方式と言える。
このように、システムの負荷状況の変動に伴い、両方式におけるターンアラウンド時間の大小関係が反転するが、従来のいずれの方式であっても、負荷の変動には依存しない固定的な方式であるために、必ずしも他方の方式よりも小さいターンアラウンド時間が提供されるとは言えない。即ち、負荷の状況によっては、急激にそのパフォーマンスが落ちるという問題点がある。
【００１８】
そこで、本発明は、上記問題点を解決するためになされたものであり、システムの負荷状況が変動する場合であっても最小のターンアラウンド時間が得られる効率的な分散処理方法及びそのシステムを提供することを目的とする。
【００１９】
【課題を解決するための手段】
上記目的を達成するために、本発明に係る分散処理方法及びシステムによれば、クライアントがサーバに備えられた特定タスクの処理結果を利用したい旨の要求を発すると、先ず、前記特定タスクに係るターンアラウンド時間を小さくするためにはサーバ又はクライアントのいずれがその特定タスクを処理すべきかが判断され、次に、サーバが処理すべきと判断された場合にはその特定タスクはサーバによって処理された後にその結果が前記クライアントに報告され、一方、前記クライアントが処理すべきと判断された場合にはその特定タスクはサーバからクライアントに移動された後にその特定タスクはクライアントによって処理される。
【００２０】
これにより、クライアントからの処理要求が発生する度に、その処理に要するターンアラウンド時間をより小さくするための処理方式が採用されるので、サーバ又はクライアントのいずれかによって固定的に処理されていた従来方式に比べ、そのターンアラウンド時間が短縮され、システムの負荷状況の変動に対応した効率的な分散処理システムが実現される。
【００２１】
【発明の実施の形態】
以下、本発明の実施の形態について図面を用いて詳細に説明する。
（実施の形態１）
図１は、実施の形態１に係る分散処理システムのハードウェア構成を示すブロック図であり、ネットワークシステム全体の中の関連する２台の端末装置１、１１のみを示している。
【００２２】
本システムは、通信路２０を介して接続されたクライアント１とサーバ１１から構成される。クライアント１及びサーバ１１は、それぞれプロセッサ２、１２、メモリ３、１３及び通信部４、１４から構成される。
プロセッサ２、１２は、ＣＰＵ等であり、装置全体を制御したり複数のタスクを並列処理したりする。
【００２３】
メモリ３、１３は、ＲＯＭ、ＲＡＭ及びハードディスク等からなり、後述する制御プログラム、システム性能パラメータ、タスク等を予め保持し、また、処理されるタスクの作業域としても用いられる。
通信部４、１４は、イーサネット用のインタフェースカード等であり、通信路２０と装置１、１１との中継をする。
【００２４】
なお、クライアント１及びサーバ１１は、汎用のワークステーション等の端末装置のハードウェア構成と同じであるが、メモリ３、１３に本実施形態を実現する固有の制御プログラム等を保持している点で汎用の端末装置と異なる。
以上のように構成された分散処理システムにおける動作について説明する。
ここで、従来技術での説明と同様の状況を考える。即ち、クライアント１は、サーバ１１のメモリ１３に保持されている特定タスクの処理結果を得たいとする。この場合における分散処理方式を説明する。
【００２５】
図２は、本実施形態の分散処理方式におけるクライアント１とサーバ１１との通信のやりとりを示すシーケンス図であり、従来の図９（ｂ）及び図１０（ｂ）に対応する。このシーケンス図は、２つの異なる場合における流れを同時に示している。即ち、以下の手順１〜３、４ａ、５ａからなる場合と、手順１〜３、４ｂ、５ｂからなる２つの場合である。
（手順１）
まず、クライアント１は、特定タスクの処理の依頼に先立ち、自らの実効処理速度を算出する。
【００２６】
具体的には、プロセッサ２は、自らの処理負荷、即ち、メモリ３にロードされ並列処理されているタスクの数Ｎcを検出し、さらに、メモリ３に格納されている最大処理速度Ｒcmaxを読み出し、式１に従って、実効処理速度Ｒcを算出する。
（手順２）
続いて、クライアント１は、算出した実効処理速度Ｒcとサーバ１１が保持する特定タスクの処理結果を利用したい旨とを一つのメッセージＭ'callにしてサーバ１１に送信する。
【００２７】
具体的には、プロセッサ２は、送信元、即ち、クライアント１のネットワークアドレス、サーバが有する特定タスクを識別する情報等を通信部４を介してサーバ１１に送信する。
（手順３）
メッセージＭ'callを受信したサーバ１１は、その特定タスクに係るターンアラウンド時間を短縮するには、その特定タスクを自ら処理すべきかクライアント１が処理すべきかを判断する。
【００２８】
具体的には、プロセッサ１２は、通信部１４を介して受信したメッセージＭ'callにより特定された特定タスクが保持されたメモリ１３を参照することにより、この特定タスクの仕事量Ｍtask、タスク移動に伴う通信量Ｍmig及びリプライメッセージの通信量Ｍrepを決定すると共に、そのメッセージＭ'callに含まれるクライアント１の実効処理速度Ｒcを抽出する。
【００２９】
続いて、プロセッサ１２は、通信部１４による定期的な通信路２０の観察に基づいて、現在における通信路２０の平均通信速度Ｒtを検出する。
そして、プロセッサ１２は、クライアント１の場合と同様にして、自らの処理負荷、即ち、実効処理速度Ｒsを算出する。
以上の値に基づいて、プロセッサ１２は、式３及び式４のそれぞれの第２項及び第３項からなる以下の２種類の時間Ｔ1、Ｔ2を算出し比較する。
【００３０】
Ｔ1＝Ｍtask／Ｒs＋Ｍrep／Ｒt ・・・ （式５）
Ｔ2＝Ｍmig／Ｒt＋Ｍtask／Ｒc ・・・ （式６）
なお、式５で表されるＴ1と式６で表されるＴ2との大小関係は、式３で表されるＲＰＣ方式によるターンアラウンド時間Ｔrpcと式４で表されるＪＡＶＡ方式によるターンアラウンド時間Ｔjavaとの大小関係と同じになる。なぜなら、式３と式４のそれぞれの第１項は共通だからである。
【００３１】
比較の結果、Ｔ1＜Ｔ2の場合には、サーバ１１は、サーバ自らこの特定タスクを処理すべきと判断し、以下の手順４ａ、５ａを実行する。
（手順４ａ）
サーバ１１は、特定タスクを処理する。
具体的には、プロセッサ１２は、クライアント１から依頼された特定タスクをメモリ１３の保持部から作業用領域に移し、既に実行しているタスクに加えてタイムシェアリングにより実行する。
（手順５ａ）
特定タスクの処理を終えると、サーバ１１は、その処理によって得られた結果をリプライメッセージとしてクライアント１に返信する。
【００３２】
具体的には、プロセッサ１２は、クライアント１からの要求に対する返答として、その特定タスクの実行により得られたデータを通信部１４を介してクライアント１に送信する。
以上の手順１〜３、４ａ、５ａにより、クライアント１から依頼された特定タスクはサーバ１１によって処理されるので、結果的に従来のＲＰＣ方式と同様の分散処理方式が行われたことになる。
【００３３】
一方、手順３での比較において、Ｔ1≧Ｔ2の場合には、サーバ１１は、サーバ１１自らではなくクライアント１が特定タスクを処理すべきと判断し、上記手順４ａ、５ａに代えて以下の手順４ｂ、５ｂを実行する。
（手順４ｂ）
サーバ１１は、特定タスクをクライアント１に移動する。
【００３４】
具体的には、プロセッサ１２は、クライアント１から依頼された特定タスクをメモリ１３の保持部から読み出し、通信部１４を介してクライアント１に転送する。なお、ここで転送される情報には、特定タスク自体、即ち、処理手続き及び必要な関連データだけでなく、手順２によるクライアント１からの要求に対する返答としてタスク移動が行われた旨のメッセージ等も含まれる。
（手順５ｂ）
その特定タスクを受信したクライアント１は、自らその特定タスクを処理する。
【００３５】
具体的には、プロセッサ２は、通信部４を介してメモリ３の作業領域にロードした特定タスクを、既に実行しているタスクに加えてタイムシェアリングにより実行する。
以上の手順１〜３、４ｂ、５ｂにより、クライアント１から依頼された特定タスクはクライアント１自らによって処理されるので、結果的に従来のＪＡＶＡ方式と同様の分散処理方式が行われたことになる。
【００３６】
このように、本方式によれば、システムにおける処理負荷の状況、即ち、クライアント１及びサーバ１１において並列処理されているタスク数を考慮することにより、Ｔ1＜Ｔ2、即ち、Ｔrpc＜Ｔjavaと判断された場合には、従来のＲＰＣ方式によるタスク処理が行われ、一方、Ｔ1≧Ｔ2、即ち、Ｔrpc≧Ｔjavaと判断された場合には、従来のＪＡＶＡ方式によるタスク処理が行われる。
【００３７】
これによって、システムの処理負荷の状況に応じ、ＲＰＣ方式又はＪＡＶＡ方式のうち、より小さいターンアラウンド時間が得られる方式が動的に決定されたことになる。
図３は、以上のシーケンスにおけるサーバ１１のみの動作を示すフローチャートである。
【００３８】
サーバ１１は、クライアント１から送られてきた処理要求メッセージＭ'callを受信した後（ステップＳ３１）、通信部１４で通信路２０の通信速度Ｒtを検出する（ステップＳ３２）。そして、受信したメッセージＭ'callから、実行すべき特定タスクの内容を決定し、クライアント１の実効処理速度Ｒcを抽出する（ステップＳ３３）。
【００３９】
さらに、サーバ１１の実効処理速度Ｒsを求め（ステップＳ３４）、タスク移動に伴うタスクの通信量Ｍmig、処理に必要となる演算数Ｍtaskおよびタスク処理の終了時にリプライに必要となるメッセージの通信量Ｍrepを求める（ステップＳ３５）。
以上の情報を用い、式５で表されるＴ1と式６で表されるＴ2とを比較し（ステップＳ３６）、前者が小さい場合は、サーバ１１内でタスク処理を行なった後に（ステップＳ３７）その結果をクライアント１にリプライし（ステップＳ３８）、そうでない場合は、クライアント１にタスク本体を移動してクライアント１内でその特定タスクの処理を行なうようにする（ステップＳ３９）。
【００４０】
図４は、図２に示されたシーケンスにおけるクライアント１のみの動作を示すフローチャートである。
まず、クライアント１は、実効処理速度Ｒcを求め（ステップＳ４１）、それを処理依頼メッセージＭ'callに付加してサーバ１１に送信する（ステップＳ４２）。
【００４１】
続いて、サーバ１１からのリプライを受信し（ステップＳ４３）、それが特定タスク本体であれば（ステップＳ４４）、クライアント１内でその特定タスクを実行し（ステップＳ４５）、そうでなければ、そのリプライを特定タスクの処理結果として利用する。
以上のシーケンスについて、従来技術での説明と同様の具体的な数値を用いてその流れを説明する。
【００４２】
即ち、システムの性能として、Ｒcmax＝４０、Ｒsmax＝１００、Ｒt＝５であり、通信量・仕事量として、Ｍtask＝２００、Ｍ'call＝５、Ｍrep＝５、Ｍmig＝１００であり、第１の負荷状況として、Ｎc＝１、Ｎs＝１９の場合を考える。
すると、
Ｒc＝４０／（１＋１）＝２０
Ｒs＝１００／（１９＋１）＝５
より、
Ｔ1＝２００／５＋５／５＝４１
Ｔ2＝１００／５＋２００／２０＝３０
となるので、上記手順３においては、Ｔ1≧Ｔ2と判断され、クライアント１が特定タスクを処理すべきと判断されるので、その後、上記手順４ｂ、５ｂ、即ち、従来のＪＡＶＡ方式が採られる。
【００４３】
図５は、この第１の負荷状況における本方式のタイムチャートを、従来の固定的なＲＰＣ方式との比較において示す図である。式３及び式４より、本方式により得られるターンアラウンド時間（３１秒）は、従来方式の場合（４２秒）よりも小さい。
続いて、Ｎs＝９に減少した第２の負荷状況を考える。
【００４４】
Ｒs＝１００／（９＋１）＝１０
に増加するので、
Ｔ1＝２００／１０＋５／５＝２１
と減少するが、Ｔ2はそのまま（３０）であるので、上記手順３においては、Ｔ1＜Ｔ2と判断され、クライアント１が特定タスクを処理すべきと判断されるので、その後、上記手順４ａ、５ａ、即ち、従来のＲＰＣ方式が採られる。
【００４５】
図６は、この第２の負荷状況における本方式のタイムチャートを、従来の固定的なＪＡＶＡ方式との比較において示す図である。式３及び式４より、本方式により得られるターンアラウンド時間（２２秒）は、従来方式の場合（３１秒）よりも小さい。
以上のように、本方式によれば、タスク処理の要求が発生した時点におけるシステムでの処理負荷の状況が考慮されるので、ＲＰＣ方式又はＪＡＶＡ方式のうち、より小さいターンアラウンド時間が得られる分散処理方式が動的に決定される。
（実施の形態２）
次に、本発明の実施の形態２に係る分散処理システムを説明する。
【００４６】
本実施形態は、クライアントからの処理依頼が発生してからその処理をすべき装置を決定するまでの手順が実施形態１と異なり、他の点においては実施形態１と同じである。従って、ここでは、実施形態１と異なる点のみ説明する。
図７は、本実施形態の分散処理方式におけるクライアント１とサーバ１１との通信のやりとりを示すシーケンス図である。実施形態１における図２と比較して判るように、本実施形態では、実施形態１の手順１、２に代えて異なる手順１〜４を採用し、それ以降の手順は同一である。
（手順１）
まず、クライアント１は、サーバ１１に対して、サーバ１１が保持する特定タスクの処理結果を利用したい旨のメッセージのみを送信する。ここでは、実施形態１と相違し、このメッセージにはクライアント１の実効処理速度Ｒcの情報は含まれない。
（手順２）
そのメッセージを受信したサーバ１１は、自らの処理負荷が軽くなった頃等を見計らって、クライアント１に実効処理速度Ｒcを問い合わせる。
（手順３）
問い合わせを受けたクライアント１は、実施形態１の場合と同様の方法により現時点での自らの実効処理速度Ｒcを算出する。
（手順４）
そして、クライアント１は、その実効処理速度Ｒcをサーバ１１に送信する。
（手順５、６ａ、７ａ、６ｂ、７ｂ）
これらのクライアント１及びサーバ１１での動作は、それぞれ実施形態１の手順３、４ａ、５ａ、４ｂ、５ｂと同一である。
【００４７】
なお、図８は、以上のシーケンスにおけるサーバ１１のみの動作を示すフローチャートであり、実施形態１における図３に対応する。
以上のように、本実施形態は、実施形態１と比較し、手順５におけるサーバ１１での判断のために必要とされる情報の準備方法（手順１〜４）が異なるだけで、手順５における判断内容やその結果による以降の流れは同一であるので、実施形態１と同様に、システムでの処理負荷の状況を考慮した最適な分散処理方式が動的に行われるのは言うまでもない。
【００４８】
また、クライアント１は、処理依頼メッセージを発行する毎に実効処理速度Ｒcを計算するのではなくサーバから問い合わせられた時のみ計算するので、クライアント１の負荷は小さくなる。
さらに、サーバ１１は、自分にとって都合のよいタイミングでクライアント１の実効処理速度Ｒcを獲得できるので、手順６ａ又は７ｂにおいて実際に特定タスクが処理される時刻に近い時刻において手順５での判断を行うことが可能となり、刻々と変化する負荷状況にあっても、より精度の高い処理方式が決定される。
【００４９】
以上、本発明に係る分散処理システムについて、実施形態に基づいて説明したが、本発明はこれら実施形態に限られないことは勿論である。即ち、
（１）上記実施形態においては、プロセッサの処理能力が処理対象となる各タスクに均等に分配されることを前提に、各端末装置の実効処理速度は式１及び式２で表されるとしたが、この実効処理速度は、これらの式で表されるものに限定されない。例えば、優先順位を伴う重み付けされたスケジューリングが行われる端末装置であれば、その重み付けを考慮した式となる。
（２）本分散処理方式における処理装置の決定は、サーバ１１によって行われたが、この装置に限定されるものではなく、例えば、クライアント１や第３の端末装置によって行われるとするシステムとすることも考えられる。
【００５０】
【発明の効果】
以上の説明から明らかなように、本発明に係る分散処理方法及びシステムによれば、クライアントがサーバに備えられた特定タスクの処理結果を利用したい旨の要求を発すると、先ず、前記特定タスクに係るターンアラウンド時間を小さくするためにはサーバ又はクライアントのいずれがその特定タスクを処理すべきかが判断され（第１ステップ）、次に、サーバが処理すべきと判断された場合にはその特定タスクはサーバによって処理された後にその結果が前記クライアントに報告され、一方、前記クライアントが処理すべきと判断された場合にはその特定タスクはサーバからクライアントに移動された後にその特定タスクはクライアントによって処理される（第２ステップ）。
【００５１】
これにより、クライアントからの処理要求が発生する度に、その処理に要するターンアラウンド時間をより小さくするための処理方式が行われるので、サーバ又はクライアントのいずれかによって固定的に処理されていた従来方式に比べ、システムの負荷状況の変動に対応した効率的な分散処理方法及びシステムが実現されるという効果がある。
【００５２】
ここで、サーバ又はクライアントのいずれが処理すべきかを決定する方法として、先ず、その時点におけるサーバ及びクライアントの実効処理速度を検出し、次に、その実効処理速度に基づいて、サーバが特定タスクを処理しその結果を前記クライアントに報告した場合に要する第１の時間と、サーバからクライアントに特定タスクを移動しそのクライアントがその特定タスクを処理した場合に要する第２の時間とを求めて比較することにより行うことができる。
【００５３】
また、サーバ及びクライアントの実効処理速度Ｒs、Ｒcは、並行処理されているそれぞれのタスク数Ｎs、Ｎcを検出し、それぞれの最大処理速度Ｒsmax、Ｒcmaxを用いて、式
Ｒs＝Ｒsmax／（Ｎs＋１） 及び
Ｒc＝Ｒcmax／（Ｎc＋１）
により決定し、第１の時間Ｔ1及び第２の時間Ｔ2は、特定タスクの処理に伴う仕事量をＭtask、通信路の通信速度をＲt、報告に伴う通信量をＭrep、タスク移動に伴う通信量をＭmigとすると、式
Ｔ1＝Ｍtask／Ｒs＋Ｍrep／Ｒt 及び
Ｔ2＝Ｍmig／Ｒt＋Ｍtask／Ｒc
により算出することもできる。
【００５４】
これにより、刻々と変化する両装置での処理能力を考慮した柔軟で精度の高いな分散処理方式が可能となる。
また、前記第１ステップは、クライアントが現時点における自らの実効処理速度を算出し、その実効処理速度を示す情報を前記要求と同時にサーバに通知し、サーバが前記判断を行うとすることもできる。
【００５５】
これによって、クライアントからの処理要求と共にクライアントの処理能力がサーバに同時に通知されるので、この分散処理のための通信トラフィックの増加を最小限に抑えることができる。
また、前記第１ステップは、前記要求を受けたサーバがクライアントに問い合わせ、クライアントが現時点における自らの実効処理速度を算出して返答し、サーバが前記判断を行うとすることもできる。
【００５６】
これによって、サーバは、自らの都合のよいタイミングでクライアントの処理能力を知ることができるので、処理すべき装置をより的確に決定することができるという効果がある。
【図面の簡単な説明】
【図１】本発明の実施の形態１及び２に係る分散処理システムのハードウェア構成を示すブロック図である。
【図２】実施形態１の分散処理方式におけるクライアント１とサーバ１１との通信のやりとりを示すシーケンス図である。
【図３】図２のシーケンスにおけるサーバ１１のみの動作を示すフローチャートである。
【図４】図２のシーケンスにおけるクライアント１のみの動作を示すフローチャートである。
【図５】実施形態１の第１の負荷状況におけるタイムチャートを、従来の固定的なＲＰＣ方式との比較において示す図である。
【図６】実施形態１の第２の負荷状況におけるタイムチャートを、従来の固定的なＪＡＶＡ方式との比較において示す図である。
【図７】実施形態２の分散処理方式におけるクライアント１とサーバ１１との通信のやりとりを示すシーケンス図である。
【図８】図７のシーケンスにおけるサーバ１１のみの動作を示すフローチャートである。
【図９】図９（ａ）は従来のＲＰＣ方式におけるクライアントとサーバとの通信のやりとりを示す説明図であり、図９（ｂ）はそのシーケンス図である。
【図１０】図１０（ａ）は従来のＪＡＶＡ方式におけるクライアントとサーバとの通信のやりとりを示す説明図であり、図１０（ｂ）はそのシーケンス図である。
【図１１】各分散処理方式におけるターンアラウンド時間を評価するためのシステム構成のモデル図である。
【図１２】ＪＡＶＡ方式による場合の方がＲＰＣ方式に比べてターンアラウンド時間が小さくなる場合の従来例のタイムチャートである。
【図１３】ＲＰＣ方式による場合の方がＪＡＶＡ方式に比べてターンアラウンド時間が小さくなる場合の従来例のタイムチャートである。
【符号の説明】
１ クライアント
２ プロセッサ
３ メモリ
４ 通信部
１１ サーバ
１２ プロセッサ
１３ メモリ
１４ 通信部
２０ 通信路
【発明の属する技術分野】
本発明は、クライアントとサーバからなる分散処理方法及びそのシステムに関し、特に、タスク処理のターンアラウンド時間を短縮するための分散処理方式に関する。
【０００２】
【従来の技術】
近年、インタネット等に代表されるネットワーク通信技術の発達及びワークステーション等に代表される端末装置の高機能化に伴い、クライアント・サーバ形式による分散処理システムが一般化してきた。
クライアント・サーバ形式の分散処理システムを実現する第１の従来方式として、遠隔手続き呼出しによる方式（Remote Procedure Call、以下「ＲＰＣ方式」という。）がある。例えば、"Concurrent Systems"，Addison-Wesley,1992 に記載されている。ここで、クライアントとは、ある特定のタスク（以下、「特定タスク」という。）の処理を依頼するネットワーク上の端末をいい、サーバとは、その依頼を受けたネットワーク上の端末をいうが、ここでは必ずしもサーバがその特定タスクの処理を実行するとは限らないとする。
【０００３】
図９（ａ）はＲＰＣ方式におけるクライアントとサーバとの通信のやりとりを示す説明図であり、図９（ｂ）はそのシーケンス図である。
この方式は、大きく３つの手順からなる。即ち、（１）クライアントは、特定タスクの処理を依頼するためにサーバに処理依頼メッセージを送る。（２）サーバは、依頼されたその特定タスクを実行する。（３）実行し終えると、サーバは、その結果を通知するためにクライアントにリプライメッセージを返す。
【０００４】
例えば、クライアントがサーバに対して、サーバが持つデータベースに検索処理およびその結果をグラフイメージで返す処理を依頼し、その生成されたイメージ情報をクライアントが受け取る場合が該当する。この方式の長所は、比較的低価格の端末と通信手段によってシステム全体としては高度な処理が実行される点にある。
【０００５】
クライアント・サーバ形式の分散処理システムを実現する第２の従来方式として、タスク移動（マイグレーション）による方式がある。例えば、SUN microsystems社が提唱しているJAVA（"Hooked on Java",Addison-Wesley,1995 に記載）やNetscape社で提案されているもの等（以下、この方式を「ＪＡＶＡ方式」という。）がそうである。
【０００６】
図１０（ａ）はＪＡＶＡ方式におけるクライアントとサーバとの通信のやりとりを示す説明図であり、図１０（ｂ）はそのシーケンス図である。
この方式も、大きく３つの手順からなる。即ち、（１）クライアントは、特定タスクの処理を依頼するためにサーバに処理依頼メッセージを送る。（２）サーバは、処理手続きと必要データをパッケージした特定タスクの移動を行う。即ち、特定タスク本体をメッセージとして構築し、リプライメッセージとしてクライアントに返信する。（３）その特定タスクを受け取ったクライアントは、自らその特定タスクを実行する。
【０００７】
この方式の長所は、クライアントにタスク処理を行わせることにより、処理が集中しがちなサーバでの負荷を軽減させることができ、これによってシステム全体における負荷分散が図れるという点にある。
【０００８】
【発明が解決しようとする課題】
しかしながら、上記の従来方式では、クライアントやサーバでの負荷の変動に伴い、必ずしも、ターンアラウンド時間、即ち、処理の依頼が発生してからその処理結果を利用できる状態になるまでの時間が最小になるとは限らないという問題点がある。
【０００９】
図１１は、その問題点を説明するためのシステム構成を示すモデル図である。本図に示されるように、いま、システムの処理性能やデータ転送速度、負荷状況をモデル化することにより、以下の通り、各分散処理方式におけるターンアラウンド時間を評価する。
まず、各端末装置ごとに、現在処理されているタスクに新たに１個のタスクが加わった場合に、各タスクが処理される速度、即ち、実効処理速度を定義する。
【００１０】
クライアントの処理速度の最大値をＲcmax（仕事単位／秒）、クライアントで並行処理しているタスク数をＮc（個）とすると、クライアントの実効処理速度Ｒc（仕事単位／秒・タスク）は、
Ｒc＝Ｒcmax／（Ｎc＋１） ・・・ （式１）
で表されるものとし、同様に、
サーバの処理速度の最大値をＲsmax（仕事単位／秒）、サーバで並行処理しているタスク数をＮs（個）とすると、サーバの実効処理速度Ｒs（仕事単位／秒・タスク）は、
Ｒs＝Ｒsmax／（Ｎs＋１） ・・・ （式２）
で表されるものとする。
【００１１】
ここで、最大処理速度Ｒcmax、Ｒsmaxとは、各端末装置固有の処理能力を示す単位であり、各装置が有するＣＰＵのSPECmark等に相当し、仕事単位とは、タスクの処理サイズを表す単位であり、実効処理速度が１仕事単位／秒である装置が１秒間に処理できる正規化された演算量に相当する。
さらに、特定タスクの仕事量をＭtask（仕事単位）、通信路の通信速度をＲt（通信単位／秒）、依頼メッセージの通信量をＭcall（通信単位）、リプライメッセージの通信量をＭrep（通信単位）、タスク移動に伴う特定タスクの通信量をＭmig（通信単位）と定義する。
【００１２】
すると、ＲＰＣ方式におけるターンアラウンド時間Ｔrpc（秒）は、上述の３つの手順に対応する時間の合計になるので、
Ｔrpc＝Ｍcall／Ｒt＋Ｍtask／Ｒs＋Ｍrep／Ｒt ・・・ （式３）
と表され、
一方、ＪＡＶＡ方式におけるターンアラウンド時間Ｔjava（秒）も、上述の３つの手順に対応する時間の合計になるので、
Ｔjava＝Ｍcall／Ｒt＋Ｍmig／Ｒt＋Ｍtask／Ｒc ・・・ （式４）
と表される。
【００１３】
具体的な数値を用いて両方式でのターンアラウンド時間を評価すると、以下の通りである。
今、システムの性能として、クライアントの処理速度の最大値Ｒcmaxが４０、サーバの処理速度の最大値Ｒsmaxが１００、通信路の通信速度Ｒtが５であり、各通信量・仕事量として、特定タスクの仕事量Ｍtaskが２００、依頼メッセージの通信量Ｍcallが５、リプライメッセージの通信量Ｍrepが５、タスク移動に伴う特定タスクの通信量Ｍmigが１００であるとする。
【００１４】
そして、第１の負荷状況として、クライアントで並行処理しているタスク数Ｎcが１、サーバで並行処理しているタスク数Ｎsが１９の場合を考える。
式１及び式２より、クライアント及びサーバの実効処理速度Ｒc及びＲsは、
Ｒc＝４０／（１＋１）＝２０
Ｒs＝１００／（１９＋１）＝５
となるので、式３及び式４より、ＲＰＣ方式及びＪＡＶＡ方式におけるターンアラウンド時間Ｔrpc及びＴjavaは、
Ｔrpc＝５／５＋２００／５＋５／５＝４２（秒）
Ｔjava＝５／５＋１００／５＋２００／２０＝３１（秒）
となる。図１２は、この結果をタイムチャートで示したものである。
【００１５】
以上より、この第１の負荷状況においては、ＪＡＶＡ方式による場合の方がＲＰＣ方式に比べてターンアラウンド時間が小さくなるので、ＪＡＶＡ方式がより好ましい分散処理方式と言える。
続いて、サーバで並行処理しているタスク数Ｎsがそれまでの１９から９に減少した第２の負荷状況を考える。
【００１６】
第１の負荷状況の場合と同様に算出すると、クライアントの実効処理速度Ｒcは２０のまま変動しないが、サーバの実効処理速度Ｒsは、
Ｒs＝１００／（９＋１）＝１０
と増加するので、ＲＰＣ方式におけるターンアラウンド時間Ｔrpcは、
Ｔrpc＝５／５＋２００／１０＋５／５＝２２（秒）
と減少する。一方、ＪＡＶＡ方式におけるターンアラウンド時間Ｔjavaは３１秒のまま変動しない。図１３は、この結果をタイムチャートで示したものである。
【００１７】
以上より、この第２の負荷状況においては、第１の負荷状況の場合と異なり、ＲＰＣ方式による場合の方がＪＡＶＡ方式に比べてターンアラウンド時間が小さくなるので、ＲＰＣ方式がより好ましい分散処理方式と言える。
このように、システムの負荷状況の変動に伴い、両方式におけるターンアラウンド時間の大小関係が反転するが、従来のいずれの方式であっても、負荷の変動には依存しない固定的な方式であるために、必ずしも他方の方式よりも小さいターンアラウンド時間が提供されるとは言えない。即ち、負荷の状況によっては、急激にそのパフォーマンスが落ちるという問題点がある。
【００１８】
そこで、本発明は、上記問題点を解決するためになされたものであり、システムの負荷状況が変動する場合であっても最小のターンアラウンド時間が得られる効率的な分散処理方法及びそのシステムを提供することを目的とする。
【００１９】
【課題を解決するための手段】
上記目的を達成するために、本発明に係る分散処理方法及びシステムによれば、クライアントがサーバに備えられた特定タスクの処理結果を利用したい旨の要求を発すると、先ず、前記特定タスクに係るターンアラウンド時間を小さくするためにはサーバ又はクライアントのいずれがその特定タスクを処理すべきかが判断され、次に、サーバが処理すべきと判断された場合にはその特定タスクはサーバによって処理された後にその結果が前記クライアントに報告され、一方、前記クライアントが処理すべきと判断された場合にはその特定タスクはサーバからクライアントに移動された後にその特定タスクはクライアントによって処理される。
【００２０】
これにより、クライアントからの処理要求が発生する度に、その処理に要するターンアラウンド時間をより小さくするための処理方式が採用されるので、サーバ又はクライアントのいずれかによって固定的に処理されていた従来方式に比べ、そのターンアラウンド時間が短縮され、システムの負荷状況の変動に対応した効率的な分散処理システムが実現される。
【００２１】
【発明の実施の形態】
以下、本発明の実施の形態について図面を用いて詳細に説明する。
（実施の形態１）
図１は、実施の形態１に係る分散処理システムのハードウェア構成を示すブロック図であり、ネットワークシステム全体の中の関連する２台の端末装置１、１１のみを示している。
【００２２】
本システムは、通信路２０を介して接続されたクライアント１とサーバ１１から構成される。クライアント１及びサーバ１１は、それぞれプロセッサ２、１２、メモリ３、１３及び通信部４、１４から構成される。
プロセッサ２、１２は、ＣＰＵ等であり、装置全体を制御したり複数のタスクを並列処理したりする。
【００２３】
メモリ３、１３は、ＲＯＭ、ＲＡＭ及びハードディスク等からなり、後述する制御プログラム、システム性能パラメータ、タスク等を予め保持し、また、処理されるタスクの作業域としても用いられる。
通信部４、１４は、イーサネット用のインタフェースカード等であり、通信路２０と装置１、１１との中継をする。
【００２４】
なお、クライアント１及びサーバ１１は、汎用のワークステーション等の端末装置のハードウェア構成と同じであるが、メモリ３、１３に本実施形態を実現する固有の制御プログラム等を保持している点で汎用の端末装置と異なる。
以上のように構成された分散処理システムにおける動作について説明する。
ここで、従来技術での説明と同様の状況を考える。即ち、クライアント１は、サーバ１１のメモリ１３に保持されている特定タスクの処理結果を得たいとする。この場合における分散処理方式を説明する。
【００２５】
図２は、本実施形態の分散処理方式におけるクライアント１とサーバ１１との通信のやりとりを示すシーケンス図であり、従来の図９（ｂ）及び図１０（ｂ）に対応する。このシーケンス図は、２つの異なる場合における流れを同時に示している。即ち、以下の手順１〜３、４ａ、５ａからなる場合と、手順１〜３、４ｂ、５ｂからなる２つの場合である。
（手順１）
まず、クライアント１は、特定タスクの処理の依頼に先立ち、自らの実効処理速度を算出する。
【００２６】
具体的には、プロセッサ２は、自らの処理負荷、即ち、メモリ３にロードされ並列処理されているタスクの数Ｎcを検出し、さらに、メモリ３に格納されている最大処理速度Ｒcmaxを読み出し、式１に従って、実効処理速度Ｒcを算出する。
（手順２）
続いて、クライアント１は、算出した実効処理速度Ｒcとサーバ１１が保持する特定タスクの処理結果を利用したい旨とを一つのメッセージＭ'callにしてサーバ１１に送信する。
【００２７】
具体的には、プロセッサ２は、送信元、即ち、クライアント１のネットワークアドレス、サーバが有する特定タスクを識別する情報等を通信部４を介してサーバ１１に送信する。
（手順３）
メッセージＭ'callを受信したサーバ１１は、その特定タスクに係るターンアラウンド時間を短縮するには、その特定タスクを自ら処理すべきかクライアント１が処理すべきかを判断する。
【００２８】
具体的には、プロセッサ１２は、通信部１４を介して受信したメッセージＭ'callにより特定された特定タスクが保持されたメモリ１３を参照することにより、この特定タスクの仕事量Ｍtask、タスク移動に伴う通信量Ｍmig及びリプライメッセージの通信量Ｍrepを決定すると共に、そのメッセージＭ'callに含まれるクライアント１の実効処理速度Ｒcを抽出する。
【００２９】
続いて、プロセッサ１２は、通信部１４による定期的な通信路２０の観察に基づいて、現在における通信路２０の平均通信速度Ｒtを検出する。
そして、プロセッサ１２は、クライアント１の場合と同様にして、自らの処理負荷、即ち、実効処理速度Ｒsを算出する。
以上の値に基づいて、プロセッサ１２は、式３及び式４のそれぞれの第２項及び第３項からなる以下の２種類の時間Ｔ1、Ｔ2を算出し比較する。
【００３０】
Ｔ1＝Ｍtask／Ｒs＋Ｍrep／Ｒt ・・・ （式５）
Ｔ2＝Ｍmig／Ｒt＋Ｍtask／Ｒc ・・・ （式６）
なお、式５で表されるＴ1と式６で表されるＴ2との大小関係は、式３で表されるＲＰＣ方式によるターンアラウンド時間Ｔrpcと式４で表されるＪＡＶＡ方式によるターンアラウンド時間Ｔjavaとの大小関係と同じになる。なぜなら、式３と式４のそれぞれの第１項は共通だからである。
【００３１】
比較の結果、Ｔ1＜Ｔ2の場合には、サーバ１１は、サーバ自らこの特定タスクを処理すべきと判断し、以下の手順４ａ、５ａを実行する。
（手順４ａ）
サーバ１１は、特定タスクを処理する。
具体的には、プロセッサ１２は、クライアント１から依頼された特定タスクをメモリ１３の保持部から作業用領域に移し、既に実行しているタスクに加えてタイムシェアリングにより実行する。
（手順５ａ）
特定タスクの処理を終えると、サーバ１１は、その処理によって得られた結果をリプライメッセージとしてクライアント１に返信する。
【００３２】
具体的には、プロセッサ１２は、クライアント１からの要求に対する返答として、その特定タスクの実行により得られたデータを通信部１４を介してクライアント１に送信する。
以上の手順１〜３、４ａ、５ａにより、クライアント１から依頼された特定タスクはサーバ１１によって処理されるので、結果的に従来のＲＰＣ方式と同様の分散処理方式が行われたことになる。
【００３３】
一方、手順３での比較において、Ｔ1≧Ｔ2の場合には、サーバ１１は、サーバ１１自らではなくクライアント１が特定タスクを処理すべきと判断し、上記手順４ａ、５ａに代えて以下の手順４ｂ、５ｂを実行する。
（手順４ｂ）
サーバ１１は、特定タスクをクライアント１に移動する。
【００３４】
具体的には、プロセッサ１２は、クライアント１から依頼された特定タスクをメモリ１３の保持部から読み出し、通信部１４を介してクライアント１に転送する。なお、ここで転送される情報には、特定タスク自体、即ち、処理手続き及び必要な関連データだけでなく、手順２によるクライアント１からの要求に対する返答としてタスク移動が行われた旨のメッセージ等も含まれる。
（手順５ｂ）
その特定タスクを受信したクライアント１は、自らその特定タスクを処理する。
【００３５】
具体的には、プロセッサ２は、通信部４を介してメモリ３の作業領域にロードした特定タスクを、既に実行しているタスクに加えてタイムシェアリングにより実行する。
以上の手順１〜３、４ｂ、５ｂにより、クライアント１から依頼された特定タスクはクライアント１自らによって処理されるので、結果的に従来のＪＡＶＡ方式と同様の分散処理方式が行われたことになる。
【００３６】
このように、本方式によれば、システムにおける処理負荷の状況、即ち、クライアント１及びサーバ１１において並列処理されているタスク数を考慮することにより、Ｔ1＜Ｔ2、即ち、Ｔrpc＜Ｔjavaと判断された場合には、従来のＲＰＣ方式によるタスク処理が行われ、一方、Ｔ1≧Ｔ2、即ち、Ｔrpc≧Ｔjavaと判断された場合には、従来のＪＡＶＡ方式によるタスク処理が行われる。
【００３７】
これによって、システムの処理負荷の状況に応じ、ＲＰＣ方式又はＪＡＶＡ方式のうち、より小さいターンアラウンド時間が得られる方式が動的に決定されたことになる。
図３は、以上のシーケンスにおけるサーバ１１のみの動作を示すフローチャートである。
【００３８】
サーバ１１は、クライアント１から送られてきた処理要求メッセージＭ'callを受信した後（ステップＳ３１）、通信部１４で通信路２０の通信速度Ｒtを検出する（ステップＳ３２）。そして、受信したメッセージＭ'callから、実行すべき特定タスクの内容を決定し、クライアント１の実効処理速度Ｒcを抽出する（ステップＳ３３）。
【００３９】
さらに、サーバ１１の実効処理速度Ｒsを求め（ステップＳ３４）、タスク移動に伴うタスクの通信量Ｍmig、処理に必要となる演算数Ｍtaskおよびタスク処理の終了時にリプライに必要となるメッセージの通信量Ｍrepを求める（ステップＳ３５）。
以上の情報を用い、式５で表されるＴ1と式６で表されるＴ2とを比較し（ステップＳ３６）、前者が小さい場合は、サーバ１１内でタスク処理を行なった後に（ステップＳ３７）その結果をクライアント１にリプライし（ステップＳ３８）、そうでない場合は、クライアント１にタスク本体を移動してクライアント１内でその特定タスクの処理を行なうようにする（ステップＳ３９）。
【００４０】
図４は、図２に示されたシーケンスにおけるクライアント１のみの動作を示すフローチャートである。
まず、クライアント１は、実効処理速度Ｒcを求め（ステップＳ４１）、それを処理依頼メッセージＭ'callに付加してサーバ１１に送信する（ステップＳ４２）。
【００４１】
続いて、サーバ１１からのリプライを受信し（ステップＳ４３）、それが特定タスク本体であれば（ステップＳ４４）、クライアント１内でその特定タスクを実行し（ステップＳ４５）、そうでなければ、そのリプライを特定タスクの処理結果として利用する。
以上のシーケンスについて、従来技術での説明と同様の具体的な数値を用いてその流れを説明する。
【００４２】
即ち、システムの性能として、Ｒcmax＝４０、Ｒsmax＝１００、Ｒt＝５であり、通信量・仕事量として、Ｍtask＝２００、Ｍ'call＝５、Ｍrep＝５、Ｍmig＝１００であり、第１の負荷状況として、Ｎc＝１、Ｎs＝１９の場合を考える。
すると、
Ｒc＝４０／（１＋１）＝２０
Ｒs＝１００／（１９＋１）＝５
より、
Ｔ1＝２００／５＋５／５＝４１
Ｔ2＝１００／５＋２００／２０＝３０
となるので、上記手順３においては、Ｔ1≧Ｔ2と判断され、クライアント１が特定タスクを処理すべきと判断されるので、その後、上記手順４ｂ、５ｂ、即ち、従来のＪＡＶＡ方式が採られる。
【００４３】
図５は、この第１の負荷状況における本方式のタイムチャートを、従来の固定的なＲＰＣ方式との比較において示す図である。式３及び式４より、本方式により得られるターンアラウンド時間（３１秒）は、従来方式の場合（４２秒）よりも小さい。
続いて、Ｎs＝９に減少した第２の負荷状況を考える。
【００４４】
Ｒs＝１００／（９＋１）＝１０
に増加するので、
Ｔ1＝２００／１０＋５／５＝２１
と減少するが、Ｔ2はそのまま（３０）であるので、上記手順３においては、Ｔ1＜Ｔ2と判断され、クライアント１が特定タスクを処理すべきと判断されるので、その後、上記手順４ａ、５ａ、即ち、従来のＲＰＣ方式が採られる。
【００４５】
図６は、この第２の負荷状況における本方式のタイムチャートを、従来の固定的なＪＡＶＡ方式との比較において示す図である。式３及び式４より、本方式により得られるターンアラウンド時間（２２秒）は、従来方式の場合（３１秒）よりも小さい。
以上のように、本方式によれば、タスク処理の要求が発生した時点におけるシステムでの処理負荷の状況が考慮されるので、ＲＰＣ方式又はＪＡＶＡ方式のうち、より小さいターンアラウンド時間が得られる分散処理方式が動的に決定される。
（実施の形態２）
次に、本発明の実施の形態２に係る分散処理システムを説明する。
【００４６】
本実施形態は、クライアントからの処理依頼が発生してからその処理をすべき装置を決定するまでの手順が実施形態１と異なり、他の点においては実施形態１と同じである。従って、ここでは、実施形態１と異なる点のみ説明する。
図７は、本実施形態の分散処理方式におけるクライアント１とサーバ１１との通信のやりとりを示すシーケンス図である。実施形態１における図２と比較して判るように、本実施形態では、実施形態１の手順１、２に代えて異なる手順１〜４を採用し、それ以降の手順は同一である。
（手順１）
まず、クライアント１は、サーバ１１に対して、サーバ１１が保持する特定タスクの処理結果を利用したい旨のメッセージのみを送信する。ここでは、実施形態１と相違し、このメッセージにはクライアント１の実効処理速度Ｒcの情報は含まれない。
（手順２）
そのメッセージを受信したサーバ１１は、自らの処理負荷が軽くなった頃等を見計らって、クライアント１に実効処理速度Ｒcを問い合わせる。
（手順３）
問い合わせを受けたクライアント１は、実施形態１の場合と同様の方法により現時点での自らの実効処理速度Ｒcを算出する。
（手順４）
そして、クライアント１は、その実効処理速度Ｒcをサーバ１１に送信する。
（手順５、６ａ、７ａ、６ｂ、７ｂ）
これらのクライアント１及びサーバ１１での動作は、それぞれ実施形態１の手順３、４ａ、５ａ、４ｂ、５ｂと同一である。
【００４７】
なお、図８は、以上のシーケンスにおけるサーバ１１のみの動作を示すフローチャートであり、実施形態１における図３に対応する。
以上のように、本実施形態は、実施形態１と比較し、手順５におけるサーバ１１での判断のために必要とされる情報の準備方法（手順１〜４）が異なるだけで、手順５における判断内容やその結果による以降の流れは同一であるので、実施形態１と同様に、システムでの処理負荷の状況を考慮した最適な分散処理方式が動的に行われるのは言うまでもない。
【００４８】
また、クライアント１は、処理依頼メッセージを発行する毎に実効処理速度Ｒcを計算するのではなくサーバから問い合わせられた時のみ計算するので、クライアント１の負荷は小さくなる。
さらに、サーバ１１は、自分にとって都合のよいタイミングでクライアント１の実効処理速度Ｒcを獲得できるので、手順６ａ又は７ｂにおいて実際に特定タスクが処理される時刻に近い時刻において手順５での判断を行うことが可能となり、刻々と変化する負荷状況にあっても、より精度の高い処理方式が決定される。
【００４９】
以上、本発明に係る分散処理システムについて、実施形態に基づいて説明したが、本発明はこれら実施形態に限られないことは勿論である。即ち、
（１）上記実施形態においては、プロセッサの処理能力が処理対象となる各タスクに均等に分配されることを前提に、各端末装置の実効処理速度は式１及び式２で表されるとしたが、この実効処理速度は、これらの式で表されるものに限定されない。例えば、優先順位を伴う重み付けされたスケジューリングが行われる端末装置であれば、その重み付けを考慮した式となる。
（２）本分散処理方式における処理装置の決定は、サーバ１１によって行われたが、この装置に限定されるものではなく、例えば、クライアント１や第３の端末装置によって行われるとするシステムとすることも考えられる。
【００５０】
【発明の効果】
以上の説明から明らかなように、本発明に係る分散処理方法及びシステムによれば、クライアントがサーバに備えられた特定タスクの処理結果を利用したい旨の要求を発すると、先ず、前記特定タスクに係るターンアラウンド時間を小さくするためにはサーバ又はクライアントのいずれがその特定タスクを処理すべきかが判断され（第１ステップ）、次に、サーバが処理すべきと判断された場合にはその特定タスクはサーバによって処理された後にその結果が前記クライアントに報告され、一方、前記クライアントが処理すべきと判断された場合にはその特定タスクはサーバからクライアントに移動された後にその特定タスクはクライアントによって処理される（第２ステップ）。
【００５１】
これにより、クライアントからの処理要求が発生する度に、その処理に要するターンアラウンド時間をより小さくするための処理方式が行われるので、サーバ又はクライアントのいずれかによって固定的に処理されていた従来方式に比べ、システムの負荷状況の変動に対応した効率的な分散処理方法及びシステムが実現されるという効果がある。
【００５２】
ここで、サーバ又はクライアントのいずれが処理すべきかを決定する方法として、先ず、その時点におけるサーバ及びクライアントの実効処理速度を検出し、次に、その実効処理速度に基づいて、サーバが特定タスクを処理しその結果を前記クライアントに報告した場合に要する第１の時間と、サーバからクライアントに特定タスクを移動しそのクライアントがその特定タスクを処理した場合に要する第２の時間とを求めて比較することにより行うことができる。
【００５３】
また、サーバ及びクライアントの実効処理速度Ｒs、Ｒcは、並行処理されているそれぞれのタスク数Ｎs、Ｎcを検出し、それぞれの最大処理速度Ｒsmax、Ｒcmaxを用いて、式
Ｒs＝Ｒsmax／（Ｎs＋１） 及び
Ｒc＝Ｒcmax／（Ｎc＋１）
により決定し、第１の時間Ｔ1及び第２の時間Ｔ2は、特定タスクの処理に伴う仕事量をＭtask、通信路の通信速度をＲt、報告に伴う通信量をＭrep、タスク移動に伴う通信量をＭmigとすると、式
Ｔ1＝Ｍtask／Ｒs＋Ｍrep／Ｒt 及び
Ｔ2＝Ｍmig／Ｒt＋Ｍtask／Ｒc
により算出することもできる。
【００５４】
これにより、刻々と変化する両装置での処理能力を考慮した柔軟で精度の高いな分散処理方式が可能となる。
また、前記第１ステップは、クライアントが現時点における自らの実効処理速度を算出し、その実効処理速度を示す情報を前記要求と同時にサーバに通知し、サーバが前記判断を行うとすることもできる。
【００５５】
これによって、クライアントからの処理要求と共にクライアントの処理能力がサーバに同時に通知されるので、この分散処理のための通信トラフィックの増加を最小限に抑えることができる。
また、前記第１ステップは、前記要求を受けたサーバがクライアントに問い合わせ、クライアントが現時点における自らの実効処理速度を算出して返答し、サーバが前記判断を行うとすることもできる。
【００５６】
これによって、サーバは、自らの都合のよいタイミングでクライアントの処理能力を知ることができるので、処理すべき装置をより的確に決定することができるという効果がある。
【図面の簡単な説明】
【図１】本発明の実施の形態１及び２に係る分散処理システムのハードウェア構成を示すブロック図である。
【図２】実施形態１の分散処理方式におけるクライアント１とサーバ１１との通信のやりとりを示すシーケンス図である。
【図３】図２のシーケンスにおけるサーバ１１のみの動作を示すフローチャートである。
【図４】図２のシーケンスにおけるクライアント１のみの動作を示すフローチャートである。
【図５】実施形態１の第１の負荷状況におけるタイムチャートを、従来の固定的なＲＰＣ方式との比較において示す図である。
【図６】実施形態１の第２の負荷状況におけるタイムチャートを、従来の固定的なＪＡＶＡ方式との比較において示す図である。
【図７】実施形態２の分散処理方式におけるクライアント１とサーバ１１との通信のやりとりを示すシーケンス図である。
【図８】図７のシーケンスにおけるサーバ１１のみの動作を示すフローチャートである。
【図９】図９（ａ）は従来のＲＰＣ方式におけるクライアントとサーバとの通信のやりとりを示す説明図であり、図９（ｂ）はそのシーケンス図である。
【図１０】図１０（ａ）は従来のＪＡＶＡ方式におけるクライアントとサーバとの通信のやりとりを示す説明図であり、図１０（ｂ）はそのシーケンス図である。
【図１１】各分散処理方式におけるターンアラウンド時間を評価するためのシステム構成のモデル図である。
【図１２】ＪＡＶＡ方式による場合の方がＲＰＣ方式に比べてターンアラウンド時間が小さくなる場合の従来例のタイムチャートである。
【図１３】ＲＰＣ方式による場合の方がＪＡＶＡ方式に比べてターンアラウンド時間が小さくなる場合の従来例のタイムチャートである。
【符号の説明】
１ クライアント
２ プロセッサ
３ メモリ
４ 通信部
１１ サーバ
１２ プロセッサ
１３ メモリ
１４ 通信部
２０ 通信路
Claims (7)
- 複数のタスクを並行処理し得る複数の端末装置が通信路に接続されたネットワークにおいて、一の端末装置（クライアント）が他の一の端末装置（サーバ）に備えられた特定タスクの処理結果を利用したい場合における分散処理方法であって、
前記クライアントが前記結果を利用したい旨の要求を発すると、前記特定タスクに係るターンアラウンド時間を小さくするためにはサーバ又は前記クライアントのいずれがその特定タスクを処理すべきかを判断する第１ステップと、
サーバが処理すべきと判断した場合には、そのサーバは前記特定タスクを処理しその結果を前記クライアントに報告し、一方、前記クライアントが処理すべきと判断した場合には、前記サーバは前記特定タスクを前記クライアントに移動しそのクライアントがその特定タスクを処理する第２ステップとからなる
ことを特徴とする分散処理方法。 - 前記第１ステップは、
前記サーバにより行われ、
現時点における前記サーバ及び前記クライアントの実効処理速度を決定する決定ステップと、
決定した実効処理速度に基づいて、前記サーバが前記特定タスクを処理しその結果を前記クライアントに報告した場合に要する第１の時間と、前記サーバから前記クライアントに前記特定タスクを移動しそのクライアントがその特定タスクを処理した場合に要する第２の時間とを求めて比較することにより前記判断をする判断ステップとからなる
ことを特徴とする請求項１記載の分散処理方法。 - 前記決定ステップにおいては、前記サーバ及び前記クライアントの実効処理速度Ｒs、Ｒcは、並行処理されているそれぞれのタスク数Ｎs、Ｎcを検出し、それぞれの最大処理速度Ｒsmax、Ｒcmaxを用いて、式
Ｒs＝Ｒsmax／（Ｎs＋１） 及び
Ｒc＝Ｒcmax／（Ｎc＋１）
により決定し、
前記判断ステップにおいては、前記第１の時間Ｔ1及び第２の時間Ｔ2は、前記特定タスクの処理に伴う仕事量をＭtask、前記通信路の通信速度をＲt、前記報告に伴う通信量をＭrep、前記タスク移動に伴う通信量をＭmigとすると、式
Ｔ1＝Ｍtask／Ｒs＋Ｍrep／Ｒt 及び
Ｔ2＝Ｍmig／Ｒt＋Ｍtask／Ｒc
により算出することを特徴とする請求項２記載の分散処理方法。 - 前記決定ステップにおける前記クライアントの実効処理速度の決定は、そのクライアントが現時点における自らの実効処理速度を算出し、その実効処理速度を示す情報を前記要求と同時に前記サーバに通知し、その通知を受けた前記サーバにより行われることを特徴とする請求項２記載の分散処理方法。
- 前記検出ステップにおける前記クライアントの実効処理速度の決定は、前記要求を受けた前記サーバが前記クライアントに問い合わせ、そのクライアントが現時点における自らの実効処理速度を算出して返答し、その返答を受けた前記サーバにより行われることを特徴とする請求項２記載の分散処理方法。
- 特定タスクを有するサーバとその特定タスクの処理結果を利用するクライアントとが通信路を介して接続された分散処理システムであって、
前記クライアントは、
前記サーバに前記結果を利用したい旨の要求をする手段と、
現時点における自らの実効処理速度を算出して前記サーバに通知する第１算出手段と、
前記サーバから前記特定タスクが移動されてきた場合には、その特定タスクを処理する手段とを備え、
前記サーバは、
現時点における自らの実効処理速度を算出する第２算出手段と、
前記要求を受けると、前記クライアント及び前記サーバで算出された実効処理速度に基づいて、サーバ自らが前記特定タスクを処理しその結果を前記クライアントに報告した場合に要する第１の時間と、前記特定タスクを前記クライアントに移動しそのクライアントがその特定タスクを処理した場合に要する第２の時間とを求めて比較する比較手段と、
前記第１の時間が小さい場合には、サーバ自らが前記特定タスクを処理しその結果を前記クライアントに報告し、一方、前記第２の時間が小さい場合には、前記特定タスクを前記クライアントに移動する手段とを備える
ことを特徴とする分散処理システム。 - 前記第１算出手段は、
前記クライアントの最大処理速度Ｒcmaxを予め記憶する第１記憶手段と、
現時点において並行処理しているタスク数Ｎcを検出する第１検出手段と、
前記第１記憶手段から読み出した最大処理速度Ｒcmaxと前記第１検出手段により検出されたタスク数Ｎcとから、前記実効処理速度Ｒcを、式
Ｒc＝Ｒcmax／（Ｎc＋１）
により算出する第１速度算出手段とからなり、
前記第２算出手段は、
前記サーバの最大処理速度Ｒsmaxを予め記憶している第２記憶手段と、
現時点において並行処理しているタスク数Ｎsを検出する第２検出手段と、
前記記憶手段から読み出した最大処理速度Ｒsmaxと前記検出手段により検出されたタスク数Ｎcとから、前記実効処理速度Ｒsを、式
Ｒs＝Ｒsmax／（Ｎs＋１）
により算出する第２速度算出手段とからなり、
前記比較手段は、
前記特定タスクの処理に伴う仕事量Ｍtask、前記通信路の通信速度Ｒt、前記報告に伴う通信量Ｍrep及び前記タスク移動に伴う通信量Ｍmigを予め記憶している第３記憶手段と、
前記要求を受けると、前記第３記憶手段から読み出した値並びに前記第１速度算出手段及び前記第２速度算出手段により算出された実効処理速度Ｒc、Ｒsを用いて、前記第１の時間Ｔ1及び第２の時間Ｔ2を、式
Ｔ1＝Ｍtask／Ｒs＋Ｍrep／Ｒt 及び
Ｔ2＝Ｍmig／Ｒt＋Ｍtask／Ｒc
により算出する時間算出手段と、
前記時間算出手段により算出された第１の時間Ｔ1及び第２の時間Ｔ2を比較する手段とからなる
ことを特徴とする請求項６記載の分散処理システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP09817496A JP3737560B2 (ja) | 1996-04-19 | 1996-04-19 | ネットワークにおける分散処理方法及びそのシステム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP09817496A JP3737560B2 (ja) | 1996-04-19 | 1996-04-19 | ネットワークにおける分散処理方法及びそのシステム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH09288648A JPH09288648A (ja) | 1997-11-04 |
| JP3737560B2 true JP3737560B2 (ja) | 2006-01-18 |
Family
ID=14212687
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP09817496A Expired - Fee Related JP3737560B2 (ja) | 1996-04-19 | 1996-04-19 | ネットワークにおける分散処理方法及びそのシステム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3737560B2 (ja) |
Families Citing this family (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3558887B2 (ja) * | 1998-08-28 | 2004-08-25 | 株式会社東芝 | 分散システム、その制御方法、および記憶媒体 |
| JP2000172657A (ja) * | 1998-12-08 | 2000-06-23 | Fujitsu Ltd | 分散処理システム、分散処理方法、その方法をコンピュータに実行させるプログラムを記録したコンピュータ読み取り可能な記録媒体、サーバ装置およびクライアント装置 |
| JP2001134519A (ja) * | 1999-11-05 | 2001-05-18 | Toshiba Corp | クライアント・サーバーシステム及び業務支援システム |
| JP2002197356A (ja) * | 2000-12-26 | 2002-07-12 | Toshiba Corp | コマーシャルメッセージ提供方法およびシステム、ならびに記憶媒体 |
| JP2002259353A (ja) * | 2001-03-01 | 2002-09-13 | Nippon Telegr & Teleph Corp <Ntt> | 広域クラスタ通信の設定方法、クラスタノードマネージャ装置、クラスタ装置および広域クラスタネットワーク |
| JP2004192052A (ja) | 2002-12-06 | 2004-07-08 | Matsushita Electric Ind Co Ltd | ソフトウェア処理方法およびソフトウェア処理システム |
| JP2008065729A (ja) * | 2006-09-11 | 2008-03-21 | Toshiba Corp | 情報処理装置 |
| US8504999B2 (en) * | 2006-10-05 | 2013-08-06 | Palo Alto Research Center Incorporated | System and method for transferring code to a data producer |
| JP2009064211A (ja) * | 2007-09-06 | 2009-03-26 | Nec Corp | 分散システム |
| EP2479699B1 (en) | 2009-09-18 | 2018-01-10 | Fujitsu Limited | Biometric authentication system and control method |
| JP5036791B2 (ja) * | 2009-11-19 | 2012-09-26 | Ｎｅｃアクセステクニカ株式会社 | データ処理システム、データ処理方法およびデータ処理プログラム |
| WO2011080809A1 (ja) * | 2009-12-29 | 2011-07-07 | 株式会社 東芝 | サーバ |
| JP5823919B2 (ja) * | 2012-06-13 | 2015-11-25 | 日本電信電話株式会社 | 分散実行システム、方法、装置およびプログラム |
| JP5987738B2 (ja) * | 2013-03-22 | 2016-09-07 | 富士ゼロックス株式会社 | 情報処理装置、システム及びプログラム |
| JP5945637B2 (ja) | 2014-04-22 | 2016-07-05 | オリンパス株式会社 | データ処理システム及びデータ処理方法 |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH05134959A (ja) * | 1991-11-14 | 1993-06-01 | Matsushita Electric Ind Co Ltd | 遠隔サービス実行制御システム |
| JP3241214B2 (ja) * | 1994-09-07 | 2001-12-25 | 株式会社東芝 | 分散処理装置及びプロセス実行方法 |
-
1996
- 1996-04-19 JP JP09817496A patent/JP3737560B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH09288648A (ja) | 1997-11-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3737560B2 (ja) | ネットワークにおける分散処理方法及びそのシステム | |
| US20190108069A1 (en) | Distributed resource allocation method, allocation node, and access node | |
| US7904759B2 (en) | System and method for service availability management | |
| Balasangameshwara et al. | Performance-driven load balancing with a primary-backup approach for computational grids with low communication cost and replication cost | |
| CN110383764B (zh) | 无服务器系统中使用历史数据处理事件的系统和方法 | |
| US20010034752A1 (en) | Method and system for symmetrically distributed adaptive matching of partners of mutual interest in a computer network | |
| CN105099989A (zh) | 用于处理业务请求及获取业务处理结果的方法、装置和系统 | |
| Evans et al. | Dynamic load balancing using task-transfer probabilities | |
| CN109117306A (zh) | 一种基于对象读写时延调整数据恢复速度的方法及装置 | |
| US20210232440A1 (en) | Execution of functions by clusters of computing nodes | |
| WO2018114740A1 (en) | A local sdn controller and corresponding method of performing network control and management functions | |
| CN111488373A (zh) | 用于处理请求的方法和系统 | |
| KR101196605B1 (ko) | 멀티 에이전트 시스템에서의 동적 로드 밸런싱 방법 | |
| CN111724262B (zh) | 一种应用服务器后续包查询系统及其工作方法 | |
| Melliar-Smith et al. | The Realize middleware for replication and resource management | |
| JP2000047890A (ja) | 分散オブジェクト管理システムとそのオブジェクト選択方法およびその処理プログラムを記録した記録媒体 | |
| CN110941404B (zh) | 激光打印机的共享打印方法及系统 | |
| US8549537B2 (en) | Middleware bridge system and method | |
| Lu et al. | Adaptive consistency guarantees for large-scale replicated services | |
| US6801933B1 (en) | System and method for proactive caching employing graphical usage description | |
| CN116599965B (zh) | 通信方法、通信装置、电子设备和可读存储介质 | |
| CN113271265B (zh) | 一种请求队列动态调整方法与相关设备 | |
| CN115622988B (zh) | web接口的调用响应方法、装置、电子设备和存储介质 | |
| US20040267898A1 (en) | Status information for software used to perform a service | |
| JP2675026B2 (ja) | 計算機システムにおけるファイルの実行方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20051025 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20051027 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091104 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091104 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101104 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |