複数の運用サーバによる処理の負荷分散を行う

 XCuteは運用サーバ機を最大 ２５台まで増設し処理を分散することができます。
プロジェクトの増加やユーザーの増加により、結果を表示するまでの時間が掛かるなど１台のサーバ機でリソースが枯渇するような場合に運用サーバ機を増設し て対処します。

　上の図はProwebXとProWebSの2台の実行サーバを使い負荷分散を行っている例です。
各実行サーバのXCuteインストールフォルダに存在するproles.iniのProWebA2ZをXやSな ど重複しない値に設定します。
[CGI]セクションの他の値は、２つのコンピュータで同じ値を保持するようにします。
特にCGI_PATH 項が各実行サーバ機共に同一のprocgiフォルダを参照す るようにしてください。また、CGIに対するコンフィグレーションは、各ProWebごとのproles.ini ファ イルで共通化する必要があります。
これは、最後に立ち上がったProWebがCGI用のパラメータを上書きするためです。共通パラメータについては、proles.ini ファイルの設定に、負荷分散時の共通パラメータとして記載があります。
ProWebA2Zの値はリクエストの割り振りに使用され、アルファベットの逆順に優先度が高くなりますので、高スペック のコンピュータをZ側に割り当てると効率的です。

　動作メカニズムは、以下のようになります。まず、ProWeb.exeが起動する際、proles.iniのProWebA2Zを読み取り自分はXマシンと 理解し、Loginプロジェクトを起動すると共にHTTPサーバマシンのC:\InetPub\procgi（バージョン番号) \procgi\alive フォルダーにLogin_x.alv ファイルを作成します。alvファイルはXCuteが起動中であることを意味します。

　HTTPサーバは、ブラウザからのリクエストを受け取ると、procgi.exe を起動しクエ リーストリングを知らせます。起動されたprocgi.exe は、クエリーストリングを解析し P=Loginを見つけ出すとともに、C:\InetPub\procgi（バージョン番号)\procgi\alive フォ ルダーのLogin_x.alv ファイルの存在からXマ シンが生きていることを知り、C:\InetPub\procgi（バージョン番号)\procgi\temp フォ ルダーにこのクエリーストリングでLogin_ｘ1234567890123.srt などのsrtファ イルを作ります。ここで、1234567890123は、１３桁の重複しない固有番号です。

　ProWebXマシンは、C:\InetPub\procgi（バージョン番号)\procgi\temp  フォルダーにLogin_X*.srtファイルを見つけると、LoginプロジェクトのProLes.exeにsrtファ イルがあることを連絡します。LoginプロジェクトのProLes.exeは、srtファイルを読み取って、パラメータ を解析し、データベースにアクセスするなどしてExcelシートを作り、これをHTMLファイルに変換します。具体的には、C:\InetPub \procgi（バージョン番号)\procgi\temp フォルダーに、HTMLファイルLogin_z1234567890123.htmpと同 名のendファイルを作成します。

　procgi.exe は、C:\InetPub\procgi（バー ジョン番号)\procgi\temp フォルダーにLogin_z1234567890123.htmpを 見つけると、これを読み取ってHTTPサーバへ返しsrtファイルを削除し、ブラウザからのリクエストに応答した１サイク ルの処理を終えます。endファイルはProWeb.exeにより削除されこの処理が正常終了と見なされます。

　なお、ｓｒｔファイルが作られ、ProLes.exe側がproles.iniの TimeOut時間内にendファイルを作り損ねると、ProWeb.exeの 実行欄は赤色に変わり「Abnormal End」（異常終了）となり、ProWeb.exeによりalvファ イルは削除されます。
「Abnormal End」が発生しても、ProLes.exe側がendファ イルの作成に成功すると、ProWeb.exeによりalvファイ ルは再び作成され、この「Abnormal End」は自動的に解除されサービスは続行されます。

複数の運用サーバによる処理の負荷分散

　運用サーバを複数使うと、通常版より高度な負荷分散を行うこ とができます。
この時は、proles.iniファイルの[Proweb]セクションのScalableを１にします。

Scalable=1 の効果）
　上図でXマシンが、Httpサーバとのネットワークの通信障害や、XあるいはSマシンのダウンが発生した際、リクエストはダウンしたマシンに送信さ れず、生きているマシンにのみ送信されます。
さらに、ネットワーク通信が回復した時、XCuteも自動復旧します。

　なお、「Scalable=1」でない場合は、Httpサーバとのネットワークの通信障害が発生しても、procgi.exeよりｓｒｔファイルは送られ てしまい、ダウンしているマシンにもリクエストが要求されてしまいます。

通信障害発生時のXCuteの動作の詳細）
　alvファ イルの作成や削除はProWeb.exeの役割です。しかし、通信障害が発生したらProWeb.exeは この役割を行えません。このため、　「Scalable=1」の時に限り、procgi.exeはｓｒｔファ イルを作成した後にTimeOutが発生したなら、すなわち時間内にhtmlファイルが作られなかったら、alvファ イルを削除することにしています。すなわち、通信障害が発生したことをprocgi.exeが 検知し、障害発生先のサーバにはsrtファイルを送らない仕組みを成り立たせています。

　下記は、通信障害が発生した時の最初のブラウザ画面で、「Scalable=1」が設定されているなら、この画面でprocgi.exeは 障害を検知しalvファイルを削除し、通信が復旧するまで当該マシンへsrtファイルを依頼することはなくなります。な お、「Scalable=1」以外の場合は、障害マシンへsrtファイルを依頼してしまいます。

下記は、この時のProWeb.exeがログで、通信障害（パスがみつからない）の発生と、その後の 通信障害の復旧（Err Recovered) のログです。
-----
20/07/07 16:15:50 [3037] ネットワーク パスが見つかりません。
 Err=57
 Fatal Disk Err Occured.
20/07/07 16:17:02 [3036]  Err=57
 Fatal Disk Err  Recovered.
-----

ProWeb.exeは、「Scalable=1」とは関係なく常に、procgi.exeと の通信を監視して通信障害が復旧すると、alvファイルを再度作成して、XCuteの自動復旧に貢献しています。