2.7.3 RPC種別による動作の違い
- 〈この項の構成〉
(1) リモートAPI機能を組み合わせた場合
ノード間負荷バランス機能とリモートAPI機能を使用した場合，サーバ側の判断で負荷分散を行います。
(2) スケジューラダイレクト機能を組み合わせた場合
スケジューラダイレクト機能を使用したRPCでは，スケジュールを依頼するOpenTP1ノードが複数ある場合（<tp1Server>要素を複数指定した場合），<tp1Server>要素を指定した順番にスケジュールを依頼します。
RPCごとにサービス要求先スケジューラをラウンドロビン方式で分散させる場合は，Client .NET構成定義<scheduleService>要素のhostChange属性にtrueを指定します。
最初のRPCでのサービス要求時に，サービス要求先スケジューラをランダムに選択するには，Client .NET構成定義<scheduleService>要素のrandomSelect属性にtrueを指定します。
(3) ネームサービスを使用したRPCを組み合わせた場合
ネームサービスを使用したRPCでは，窓口となるTP1/Serverのネームサービスにサービス情報を問い合わせ，ネームサービスからの応答メッセージを基にサービス要求先スケジューラを決定します。
RPCごとにサービス要求先スケジューラを分散させる場合は，Client .NET構成定義<nameService>要素のloadBalance属性にtrueを指定します。これによって，Client .NETは，ネームサーバから複数のサービス要求先スケジューラの情報を取得し，負荷レベルが最も低いサービス要求先スケジューラの情報をキャッシュに格納します。
キャッシュに格納されるサービス要求先スケジューラの情報は，1つだけではなく，複数の場合もあります。
キャッシュに格納されたサービス要求先スケジューラの情報が複数ある場合，最初のサービス要求先スケジューラは，ランダムに選択されます。RPCでのサービス要求が2度目以降の場合は，サービス要求先スケジューラの情報を取得するためにキャッシュを参照し，RPCごとにラウンドロビン方式でサービス要求先スケジューラを切り替え，分散させます。
クライアントからのRPC実行時に，このキャッシュ領域中に該当するサービス情報が存在する場合には，窓口となるTP1/Serverのネームサービスに対してサービス情報の問い合わせを行いません。クライアントではLRU（Least Recently Used）方式でキャッシュを管理しているため，キャッシュ領域が不足した場合には参照されていないサービス情報から順に削除します。また，Client .NET構成定義<nameService>要素のcacheTime属性に指定した有効時間が過ぎたサービス情報は，RPC実行時にキャッシュ領域から削除され，ネームサービスに対してサービス情報を問い合わせます。
- 注意事項
-
-
Client .NET構成定義<nameService>要素のcacheCapacity属性の指定値を大きくすると，多くのサービス情報を格納でき，窓口となるTP1/Serverのネームサービスとの通信回数を削減できます。ただし，多くのキャッシュ領域中からサービス情報を検索するのでオーバヘッドが掛かります。
-
Client .NET構成定義<nameService>要素のcacheTime属性の指定値を小さくすると，古いサービス情報はただちに削除され，窓口となるTP1/Serverのネームサービスに新しいサービス情報を問い合わせます。この場合，常に最新のサービス情報をキャッシュ領域に保持できるため，サーバの負荷に応じてRPC要求を振り分けられます。ただし，ネームサービスとの通信回数が増え，また，キャッシュ領域の書き換え処理にもオーバヘッドが掛かります。
-
Client .NET構成定義<nameService>要素のcacheTime属性の指定値を大きくすると，窓口となるTP1/Serverのネームサービスとの通信回数を削減できます。ただし，SPPの状態変化への対応が遅れるため，SPPが停止したノードのスケジューラに対してRPC要求を実行してしまうことがあります。
-
(4) 通信先を指定したRPCを組み合わせた場合
通信先を指定したRPCを使用した場合，ノード間負荷バランス機能は使用できません。