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

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

WicketのCPU負荷〜その２〜

java

昨日は、DEVELOPMENTモードでの実行だったので、今日はDEPLOYMENTモードでやりなおしてみました。

Wicketはデバッグ情報の構築や、詳細なエラーメッセージを表示するDevelopmentモードと、これらを省いてパフォーマンスやセキュリティーを優先するDeploymentモードがあります。

これは、web.xmlに以下のように書くことで切り替えることができます、

	<context-param>
		<param-name>configuration</param-name>
		<param-value>deployment</param-value>
	</context-param>

今日は、ついでに、客観的なデータを取るために、Jakarta JMeter (http://jakarta.apache.org/jmeter/)を使用しました。

まずは、JMeterを設定

1秒間に100アクセスを処理してみます。

とりあえず、Topページ

そして結果：

グラフ

統計

１ページ処理するのに、10〜20秒かかってしまいました。

結果の一部

CPU負荷

CPU負荷90%に上っています。（Core2Duo E4600 2.4GHz）
実験が終了後は、何事もなかったように、CPU使用率0%に戻りました。

実際、実験中にブラウザでアクセスすると、10秒くらう待たされてから結果が返りました。


これは問題です！

通常、DBサーバの負荷を気にします。
そのために接続コネクション数を制限して、ない場合は
「ただいま混雑しています。後で」
というメッセージを表示します。

しかし、APサーバが高負荷の場合は、
そもそもメッセージを表示できない
わけです。

たしかに、APを冗長化するという手もあります。
APの冗長化は仕組み上はDBよりも簡単です。
ただしコストがかかります。

なので、
「今までは、１サーバで複数のクライアントをホスティングすることも平気で行ってたじゃん！」
と上から怒られてしまいます。

ECサイトは、ものにもよりますが、一般的には高負荷なシステムです。
アクセスがあっても、実際に購入につながる確率は低いので、（それをいかに上げるかという問題もありますが、）SEOなどでいかに母集団を上げるか頑張るわけです。
アクセスが集中することは、お客様としては（DOS攻撃でない場合）歓迎すべきことなのですね。

従って、ECシステムでは、一度に大量のアクセスをふつうに処理できることが必要条件となります。


僕がWicketを選択した理由は、テンプレートをHTMLで書けるからです。
ECはデザインが命です。
毎回デザインをプロの方に作ってもらっています。
ところが、今までは、せっかくベースのシステムがあっても、そのデザイナさんのHTMLを、「JSP組み込み」と呼ばれる大変な作業で、組み込み直す必要がありました。

この作業は、どんなに熟練したプログラマーでも、だいたい同じような時間がかかってしまいます。

さらに、実際に作業をする僕らプログラマーはこの作業を嫌います。
だって、
HTMLタグがちょっとずれただけで、ページがガタガタ崩れてくるわけですよ。
すっかり、HTML嫌いになる人続出です。

プログラマーが好きなのは、アーキテクチャーをいじったり、SQLを発行したりロジックを書いたりする、創造性の高いことです。なのに、何が悲しくてJSPの組み込み職人にならなきゃならないのかと思うでしょう。

そこでです！

Wicketを使うことで、デザインの組み込みコストが極小化できることを期待しました。
Wicketはそのままブラウザでプレビュー表示ができるようなテンプレートを使うことができます。
また、Ajax対応などもしているため、先進的なデザインをどんどん取り入れられることを期待しました。

実際、Wicketによる開発は楽しかったです。
まだ、どうやって使いこなしたらいいのか、わからない部分も多いですが、

もう、今までのServletには戻したくないです(>_<)。

もうちょっと頑張って、この負荷問題をどうにかしたいと思います。


その後（追記）

画像もCSSも使用しないページで同様の実験をやったところ、ほとんど負荷がないことがわかりました。

どうも、リソースストリームが足を引っ張っているんじゃないかと思ってきました。

Wicketは外部からは直接参照できないクラスパスに、通常HTMLや画像などのリソースを配置します。
これは、コンポーネントを.jarファイルとして固めて配布できる点で便利な仕組みです。

でも、何でもかんでもすべてのリソースをクラスパスに含めてしまうと、毎画面生成するたびに、リソースストリームを処理しなければいけなくなると言うことでしょうか？

通常のリクエストの場合でも、IOが必要なので、理論上は同じような負荷のはずですが、負荷がかかっていなかったのは、F5連打の時はブラウザがキャッシュをしていたからかもしれませんね。JMeterの時は、JMeterは取得したIMGタグを処理して画像をリクエストしなかったのかもしれません。

確定ではないので、要調査ですが、この辺が解決の糸口かもしれないので継続調査してみます。