Webエンジニア susumuis の技術ブログ

このブログの内容は個人の見解であり、所属する組織の公式見解ではありません

WicketのCPU負荷〜その6〜まとめ

今日はこれまでのまとめをします。

なお、私の使っているWicketのバージョンは1.3.5です。

1. WicketのAutoLink機能

Wicketでは、通常、デザインを設定するマークアップファイル(HTMLテンプレート)を、クラスパス上に配置します。


ところが、もしそこに画像などへの相対リンクがあると、実行時にそれが表示されなくなってしまいます。
それは、クラスパスへはWebからアクセスできないためです。


クラスパス上にあるリソースをレスポンスするには、リソース・ストリームを使用することができます。
しかし、その場合、すべての画像ファイルに対して、Imageコンポーネントなどを配置する必要があり、とても面倒です。


そこで、WicketにはAutoLinkという機構があります。

<wicket:link></wicket:link>

で囲うか、Applicationクラスのinit()に

getMarkupSettings().setAutomaticLinking(true);

と記述すると、有効になるこの機能を使うと、Wicketが自動でコンポーネント追加などを行って、相対参照だったリンクを、リソース・ストリーム経由のリンクに変更してくれます。


AutoLinkを使えば、ローカルでプレビューしたときのように、相対参照先の画像やCSSを取得できて、思った通りの表示を得ることができます。

2. AutoLinkの負荷

ところが、そのようにして作成したページに対してF5を連打するなどすると、急激にサーバのCPU負荷が高まってしまいます。


これは、Wicketがページのリクエスト時に画像をロードするためだと思われます。
Wicketは「戻る」ボタン対応のために、ページの状態が変わるたびにそれをセッション(?)に保存し、各々に固有のURLを振っています。
この機能をページのバージョン管理と言います。


また、Wicketのファイル・リソース・ストリームは、非同期IO(NIO)ではない、ブロッキングIOを使っているため、ファイルがロードされるまでの間、処理待ちが発生します。


ここで疑問1

Wicketがローカルファイルの更新日付をチェックして変わっていなかったら適当な過去の履歴から取ってくるようにすれば早いのではないでしょうか?

3. ブラウザキャッシュの問題

通常のWebアプリケーションでは、画像は外部からアクセスできる場所に配置するでしょう。
その場合も、同じ画像をリクエストし続ければ当然サーバの負荷が高まってしまいます。
しかし、Webサーバとブラウザの間では、Expiredや304 Last-Modifiedなどのヘッダ情報をやりとりして、巧みにキャッシュを利用することで無駄な通信・IOを押さえることができます。

ここで疑問2

Wicketがこの処理をやってくれてもいいはずなのに働いてくれないのはどうしてなのでしょう。


と、ここまで書いたところで、
Wicket-jaの矢野先生が以下のようにまとめてくださっていることに気がつきました。
http://d.hatena.ne.jp/t_yano/20090502/1241277070
まだ全文読んでいないのですが、感謝感激です!