ここまでやってなんでWicketがないんだと思われた方もいると思うのでWicketも試す。
環境作るのが面倒だったのでサンプルアプリケーションをデプロイしただけ。
ソースを見るとHelloWorldは以下のようになっている。
public class HelloWorld extends WicketExamplePage { public HelloWorld() { add(new Label("message", "Hello World!")); } }
結果
おおむねStrutsを一回り重くしたという感じかな。
Strutsは50msくらいの悪い値がたまに出るのに対してWicketは60msから70msがたまにでる感じ。それ以外の普段の値も15msを切ることはほとんどないため、13msがふつうにでてくるStrutsより1割くらい重いと思われる。
200回の平均値で順位をつけると
| 順位 | フレームワーク | DIコンテナ | ms |
|---|---|---|---|
| 1 | Spring MVC 2.5 | Spring Framework 2.5 | 10 |
| 2 | JSF 1.2 | EJB 3.1 | 11 |
| 3 | Struts 1.2 | なし | 18 |
| 4 | Wicket 1.4RC | なし | 22 |
| 5 | Cubby 1.1 | Seasar 2.4 | 92 |
| 6 | T2Framework 0.5 | lucy 0.5 | 195 |
という感じ。
それぞれ構造や得意なところが大きく違うし、DIコンテナを含んでいるものと含んでいないものもあるので参考程度に。
あとT2とCubbyが遅い値がたまに（T2の場合たまにどころではないが）出現するのはこの２つだけNetBeansでログ表示してると遅いという現象が完全に改善してないのかもしれない。でも他のフレームワークもログは出してるし、wicketだってLog4Jとか利用してるし、この2つだけ他のフレームワークと違い何か特殊なことをしてるのかもしれない。
T2はアダプタを変えることによって多少遅い数値が出るタイミングが軽減される場合もあるが遅い値が出るのはかわらず。
というわけでV2で試す
T2FrameworkをV2で試したところ遅い数値は表れなかった。ロギングの実装を変更しても完全には改善されてないということかな。たぶん、Cubbyも遅いパターンは現れないと予想。
あ、Cubbyも改善した。
V3はログファイルのローテート処理がないから遅い…とも考えたけどそれなら他のフレームワークも遅い数値が現れないと納得がいかないし、Glassfish V3のログファイルそんなに大きくなかった。まったくの謎。
ちなみに数値が小さいと1msがあまりにも単位が大きすぎてJMeterがレスポンスを比較する目的に使えないことがわかった。ミリ秒より小さい単位が扱えるJ2SE5.0で書き直して欲しい…。
ああ、ここまでやってきて結局レスポンスの比較にはJMeterが使えないのがわかったというのがあほすぎる。orz
まぁわかっただけまだいいか。
とりあえずGlassfish V3とNetBeansとT2Framework & Cubbyはやっぱり結局相性が悪いということに。かといってNetBeansでアタッチしておかないとログがリアルタイムで見れないのでいろいろと試すとき面倒だし。他のフレームワークで遅くなってないというのは何があるんだろうか。アノテーションによる自動登録系？
というわけでSpring MVCのサンプルをアノテーションで登録するようにしてV3で実行みた。実行すると確かに遅くなってるが、すさまじい遅さが現れることはなかった。でも、確かに重い。平均値で2倍とStrutsと同等、もしくはそれ以上に重くなった。Wicketに近い。生産性を取るか、実行時のスピードをとるかは結構意識しないといけないかもしれない。
V2でまた計測しなおしをしたいとは思っているが、JMeterのコードを修正する気力も体力もないのでレスポンスのテスト用に専用で1から検証用コード書くことにしよう。JAX-RSのRIであるJerseyのクライアントあたりを使えばよいかな?
明日までにはすべて検証しなおして出す。
