Alaska Ver3.0 のロード・バランス機能について紹介しよう。
本来、HTTPサーバーの機能と CGI との関係は

[処理の流れ]

1. ブラウザから HTTPサーバーへ要求が送られる。
2. HTTPサーバーは CGI へ実行を要求する。
3. CGI が結果の HTMLを HTTPサーバーに戻す。
4. HTTPサーバーは CGI からのHTMLをブラウザへ送信する。

という処理が実行される。
一般のHTTPサーバーでは CGI のHTML出力は｢標準出力｣といって早い話が、
印刷待ち行列 ( OUTQ ) への印刷出力である。
( OS400 V3 ではCGI の出力は実際にスプールに出力されていたためにパフォーマンスが
かなり悪かったのである。）

この流れが一般的でありApache や現在のIBM HTTPサーバー, IISにおいても同じである。
古典的なこの手法で何か気づいた点はないだろうか？
この手法は HTTPサーバーだけがブラウザとの送受信を行っているのである。
これでは HTTPサーバーだけに極度に入出力が集中することは避けられない。
同時に数千クライントからの要求が集中したときのことを想像してみてほしい。
HTTPサーバーは同時に数千のスレッドが入出力を実行するのである。
HTTPサーバーは ｢マルチスレッド ｣ として確かに同時並行処理を実行するが
マルチスレッドはリソースは低減されるが同じ数のプロセス ( JOB ) の同時実行に比べると
決して速くないどころか、かなり遅くなってしまう。
これはPC上でも同じである。

そこで Alaska Ver3.0 では、これらの処理は次のように改訂された。

�@ と �A までは同じであるが �B として CGI が直接、ブラウザへ結果のHTMLを
送信するのである。
つまり Alaska はほとんどブラウザからの要求の受信しか行わないので
非常に負荷 ( ロード ） が低減されて軽く動作するようになっている。
一方、CGI も直接ブラウザへ結果を戻すのでパフォーマンスも非常に速くなるのである。
CGI は再コンパイルの必要もない。
これによって ブラウザへの応答は驚くほど速くなった。
これが Alaska Ver3.0 のロード・バランサーである。
他の標準出力で CGI の処理を行っている HTTPサーバーであっても
この手法を採用できるのであるが誰も気づいていないのであろうか？
たったこれだけのことであるがユーザーからは体感的にもかなり速くなった！
との多くの評価を得ている。
表には見えないが Alaska は確実に進歩しているのである。