現在の世の中のWebサーバーとブラウザは静的なHTMLはキャッシュするものの、CGI の出力がキャッシュされることは無い。
しかし開発者が頭を痛めている問題は静的なコンテンツの応答速度ではなくCGI による
出力である。静的なHTMLよりCGI を起動させるほうがはるかに時間がかかる。CGIの動作こそ
速くなるように考慮すべきなのである。
EnterpriseServer ではこの点に注目した。

Alaska Ver 2.0 では2つのキャッシュ・サービスが利用可能になった。

• クライアント・キャッシュ と
• サーバー・キャッシュ

である。

まずクライアント・キャッシュはCGI の出力結果をブラウザにキャッシュさせることができる。これは IBM FRCA も含めて世界中のHTTP サーバーには無かった機能である。
またサーバー･キャッシュも CGI の出力結果をサーバー側つまりiSeries400 内部にキャッシュ
として保存する。
そのシナリオは最初に誰かが iSeries400 にアクセスするとする。
するとCGI が起動されてその出力結果はiSeries400内部とブラウザの両方にキャッシュされる。
その同じユーザーが再びアクセスすると結果はローカルPCのキャッシュが優先されて使用される
のでローカル･キャッシュであることから断然速くなる。
次に別のユーザーが同じ URL でアクセスするとサーバー側のキャッシュが利用されるのでCGI は全く起動されることなくキャッシュが静的コンテンツとして戻される。
静的コンテンツの戻りであるのでCGI を起動するよりは圧倒的に速くなる。

Alaka Ver2.0 ではサーバー/クライアントの両方にキャッシュされる。

それではデータ・ベースの変更はどのように反映されるのであろうか？
幸い iSeries400では*PGMから、その使用オブジェクトを参照できる機能がある。
Alaska は CGI の参照オブジェクトを動的にその場で調べて参照オブジェクトの更新日付・
時刻を調査する。これによってキャッシュ日付を判定しているのである。
この手法によってユーザーは FRCA のときのようにトリガーを開発して設定する必要が無い。
しかもサーバー・サイドだけではなくクライアント・サイドにもキャッシュされるので応答は他の
サーバーより速くなる。

つまりユーザーが使用するであろう操作をキャッシュしておけば

• 最初にアクセスしたときも速い。(サーバー・キャッシュ)
• 2回目以降は更に速い。(クライアント・キャッシュ)

という結果を得ることができる。

繰り返すが CGI の結果がブラウザにキャッシュされるという機能は Apache や他の世界中の
HTTPサーバーでも無かった画期的な方法である。
これによってあなたの iSeries400 は快適な Web サーバーに変身するであろう。
iSeries400 が UNIX や Linux の Web サーバーより進化したサーバーに生まれ変わるとは
何と小気味の良いことではないだろうか？