負荷テスト結果

ここから先が数字です。
補足や雑感をダラダラ書いたりもしています。

Requests per secondの数字は大きい方が、スループットが高く、より速いという事になります。
又、No.は、補足説明をする際に使用する項番です。
尚、スクリプトを見れば分るとおり、5回に渡って負荷をかけています。
それぞれの結果の中から、最も端的に結果を確認できる「Requests per second」を一覧化してみました。

No.
(1) Struts + S2.4 + Kuina-Dao + JPA(Hibernate) 1075.44 [#/sec] 1107.79 [#/sec] 1105.82 [#/sec] 1108.95 [#/sec] 1188.89 [#/sec]
(2) Struts + Spring2 + JPA(Hibernate) 974.94 [#/sec] 980.48 [#/sec] 1034.45 [#/sec] 1051.38 [#/sec] 1017.52 [#/sec]
(3) Teeda + S2.4 + Kuina-Dao + JPA(Hibernate) 311.94 [#/sec] 331.42 [#/sec] 332.59 [#/sec] 329.71 [#/sec] 330.91 [#/sec]
(4) MyFaces + Spring2 + JPA(Hibernate) 372.28 [#/sec] 400.88 [#/sec] 397.69 [#/sec] 400.94 [#/sec] 396.31 [#/sec]

Viewレイヤについて

まず、Viewのテクノロジが、JSFStrutsかで、200%〜300%程度の差があります。
尚、(3)のTeeda以外は、全て画面のテンプレートとしてJSPを使用しています。
(1)と(3)ないし、(2)と(4)では、差分はStrutsJSFかのみですが、ご覧の結果です。
つまり、この結果を鑑みるに、「StrutsJSFに比べると圧倒的に速い」と言う事になります。


フレームワークとして持っている機能の量に明らかなる差がある事を考えれば、当たり前と言えば当たり前ですが、
このパフォーマンス上の差は、簡単に看過出来る様なレベルでは無いと個人的には感じますので、
パフォーマンスの差分を埋められるだけJSF実装の方が優れているのかは、一考の価値があると思います。


(1)と(2)の比較においては、Kuina-Dao分のオーバヘッドが、
差分として出てきてもおかしくないとは思うものの、結果的にはSeasar2側の方がハイパフォーマンスです。*1


(3)と(4)の比較においては、20%〜30%程度の差が出ています。
これに関しては、TeedaMyFacesの間に厳然たるパフォーマンスの差があると考えるのが妥当でしょう。
原因としては、2byte文字に対する考慮の差が、結果に大きく寄与している可能性が高いと思います。

永続化レイヤについて

永続化レイヤとしては、全てJPAを使用しており、その実装はHibernateで統一しています。
Seasar2側には、Kuina-Daoがレイヤとしては1つ多い*2ので、
パフォーマンス的には若干不利な感がありますが、その部分によって大きく差が出ている様には見受けられません。
それでも、Kuina-Daoがその機能を無コストで実現していると考えるのは無理がありますが…


そもそも、Hibernate自体が永続化レイヤで使用するフレームワークとして十分に速いとは言い難いので、
Hibernate程に高機能な永続化フレームワークを必要としない場合には、
永続化レイヤとして、S2DaoiBatisを使用する事で、パフォーマンスを大きく改善出来る余地があると思います。

DIコンテナについて

今回の様な負荷テストで、DIコンテナ単体のパフォーマンスを比較する事は非常に難しいのですが、
id:arumaniさんのパフォーマンステストによると、
単純にSpringとSeasar2のみで比較した場合には、Seasar2の方が速い様です。

最後に。

パフォーマンスだけが、フレームワークを選定する基準になる訳ではありませんが、
フレームワークを選ばなければならない人のお役に少しでも立てればイイなぁと思います。

*1:S2Containerは、先週かなりチューニングされています。

*2:Spring2では、JpaDaoSupportを使用しています。