ベンチマークを更新しました - あるまに
SpringFramework 2.0.4で、ちょうどベンチマークに関係する部分のパフォーマンスチューニングを行ったとの事なので（詳しくは次のエントリ参照）、再度ベンチマークを行いました。Seasar2も最新版に入れ替えた上で、セットアップ処理コードを一部変更しています。 計測内容 バージョンは、Spring 2.0.4 / Guice 1.0 / Seasar2 2.4.12 インスタンス取得はAOP有りとAOP無しの両方を計測（前回は有りのみでしたが、今回は無しも計測しました） 全てプロトタイプ（毎回新しいインスタンスを取得） 取得したインスタンスの実行時間は、AOP有りのみ計測（AOP無しは変わらないはずなので） 留意して欲しい事項は前回の前置きにあります ベンチマーク結果 - get instance (NO AOP)- Spring: 24,336 creations/s Gui
負荷テスト結果 - 設計と実装の狭間で。
ここから先が数字です。 補足や雑感をダラダラ書いたりもしています。 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 [#/
負荷テストスクリプトについて。 - 設計と実装の狭間で。
どの様な負荷をかける事によって得られた結果なのかについて、それなりに書いておきます。 負荷テストは、負荷のかけ方によって、180度違った結果が出る事があります。 今回は、Seasar2とSpring2の比較をしていますが、 僕がSeasar2寄りなモノの考え方をしているのは事実であり、その一点のみにおいて、Spring側は不利です。 例えば、Seasar2では、HotDeployと言う、パフォーマンスを犠牲にして開発効率を優先する機能がありますが、 当然の事ながら、この負荷テストを行うにあたって、当該機能はOFFになっています。 又、非常に単純な方法で負荷をかけていますので、現実の案件でやるべき負荷テストとは、 テストとしての品質において非常に劣っていると言わざるをえません。*1 基本的には、これから負荷テスト的な事をやりたいと思っている人の参考に少しでもなれればイイなぁ…と、思います。
負荷テストの環境について。 - 設計と実装の狭間で。
今回の負荷テストを行ったハードウェア及び一部のミドルウェアについてです。 CPU vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU 5160 @ 3.00GHz stepping : 6 cpu MHz : 3000.274 cache size : 4096 KBXeon 3GHz デュアルコアのCPUが2つのってるサーバです。 結局、コアは4個って訳です。 メモリ MemTotal: 2074780 kBんーと、つまり、2GBですな。 OS Linux version 2.6.9-34.ELsmp (bhcompile@hs20-bc1-7.build.redhat.com) (gcc version 3.4.5 20051201 (Red Hat 3.4.5-2))
(その8) Seasar2をAOPパフォーマンス比較対象に追加 - あるまに
id:koichikさんに「S2も比較に追加して」というコメントを頂いたので、言われた通りの方法で追加して試しました。Seasar2のテストコードはま!さんのSeasar2用コードにkoichikさんの記述を追加しただけのものです。Seasar2は触った事がないのでシングルトンかどうか分からなかったのですが、デバッグしながら見たらinjectされたオブジェクトのIDが呼び出しのたびに異なっていたので、毎回インスタンス化しているのだろう（＝条件は同じだろう）と判断しました。また、上記Springの訂正も含まれています。 最初の3回の結果は以下です。Springにとってはちょっと…. Spring: 1,734 creations/s Guice: 35,161 creations/s S2: 18,395 creations/s Spring: 1,776 creations/s Guice
Google Guice（その6） AOP使用時のパフォーマンス比較 - あるまに
※下記はコードが間違っていて訂正したので、その8をご参照下さい。 その5でid:shot6さんにコメントを頂いた事もあり、AOP使用時のパフォーマンスを比較してみます。 使うのは、Guice付属のパフォーマンス比較コードにAOP設定とAOPを挟んだメソッドの呼び出しを追加したものです。 SpringのAOPはとりあえずノーマルなProxyで。 // 設定 RootBeanDefinition proxy = new RootBeanDefinition(ProxyFactoryBean.class); MutablePropertyValues proxyValues = new MutablePropertyValues(); proxyValues.addPropertyValue("target", new RuntimeBeanReference("barImpl")); prox
[ThinkIT] 第4回：AOP機能のパフォーマンス比較 (1/4)
今回はAOP処理のパフォーマンスを見ていきましょう。AOPはDIコンテナと一見関係なさそうですが、Seasar2とSpringのどちらのコンテナもAOP機能を提供しています。また実案件でAOP機能を利用しないことはあまり考えられません。 AOPもDIと同様に内部処理が見えづらい処理です。そこでまずAOPについて簡単に解説します。
[ThinkIT] 第3回：DI処理のパフォーマンス比較 (1/4)
<components> <component name="component00000A" class="xxx.Bean00000AImpl" autoBinding="none"> <property name="bean00000B">component00000B</property> </component> <component name="component00000B" class="xxx.Bean00000BImpl" autoBinding="none"/> <component name="component00001A" class="xxx.Bean00001AImpl" autoBinding="none"> <property name="bean00001B">component00001B</property> </component> <compon
[ThinkIT] 第3回：DI処理のパフォーマンス比較 (1/4)
<components> <component name="component00000A" class="xxx.Bean00000AImpl" autoBinding="none"> <property name="bean00000B">component00000B</property> </component> <component name="component00000B" class="xxx.Bean00000BImpl" autoBinding="none"/> <component name="component00001A" class="xxx.Bean00001AImpl" autoBinding="none"> <property name="bean00001B">component00001B</property> </component> <compon
[ThinkIT] 第1回：どっちが速いSeasar2 VS Spring (1/4)
Seasar2が登場して2年が経ち、今では実際の開発でDIxAOPコンテナを使用することは珍しいことではなくなりました。 DIxAOPコンテナを導入するにあたって、他のDIxAOPコンテナとの速度比較やDIxAOPコンテナが行う処理の中でどこに時間がかかっているかについて評価されていることと思いますが、なかなかそのすべてを把握されていないのではないでしょうか。 そこで本連載では、DIxAOPコンテナの生成やコンポーネント取得といったベーシックな機能についてパフォーマンスを測定して、以下にあげた点について明らかにしていきます。 DIxAOPコンテナ（Seasar2、Spring）の実装によって、どれくらいパフォーマンスが異なるのか DIxAOPコンテナが行う処理の中で、どこに時間がかかるのか また結果として速度が遅くなった箇所については、その原因を考察して実案件で役立てていただけましたらと思
2006-03-30
Seasar VS Springのパフォーマンス比較の結果は､オープンソース & Linux テクノロジー・フォーラム 2.0で詳しく報告します。是非ご参加くださーい。 第四弾として､AOPのパフォーマンスを測定してみました。Helloという文字列を返すInterceptorが仕掛けられたメソッドを10,000,000回呼び出すものです。Seasar2のバージョンは､2.3.7、Springは1.2.6です。これは、この後最新版でも比較します。 結果(の平均)は､Seasar2が1000ms、Springが4000ms。4倍くらいSeasar2が速い。Springは、JDKのProxyとcglibを使うバージョンを試してみましたが､結果はほとんど一緒でした。 そういえば、DynaAOPはSpringより4倍以上高速という記事がありましたね。Seasar2もバージョン2.1までは、AOPのラ
パフォーマンス比較3 - ひがやすを技術ブログ
第三弾として､2000個のオブジェクトを登録して､1000回DIを型による自動(autowiring=byType)で行うやつを測定してみました。Seasar2のバージョンは､2.3.7、Springは1.2.6です。これは、この後最新版でも比較します。 結果(の平均)は､Seasar2が150ms、Springが8000ms。約53倍くらいですね。前回のautowiringなしの結果と比較すると､Seasar2は変化なし､Springは2倍遅くなっています。Springは、autowiringで対象となるオブジェクトを探しに行くときに､コンテナに登録されている全オブジェクトを毎回見に行く(ように見える)ので、遅くなるのは想定されていたことです。Seasar2は、コンポーネントの登録時に、アクセスされる可能性のあるキーはあらかじめMapに登録します。そのため、autowiringでも、全件
ひがやすを blog - パフォーマンス比較2
Seasar2.4 beta 1をリリースしました。 http://s2container.seasar.org/ja/ http://s2container.seasar.org/en/ 変更点 EJB3の実装を追加しました。 InterTypeを追加しました。 Servlet用のjarファイルがなくても稼動できるようにしました。 第二弾として､2000個のオブジェクトを登録して､1000回DIをマニュアル(autowireなし)で行うやつを測定してみました。Seasarのバージョンは､2.3.7、Springは1.2.6です。これは、この後最新版でも比較します。 結果(の平均)は､Seasar2が150ms、Springが4000ms。約26倍くらいですね。前回は､10000個でやったんですけど､Eclipseが不安定になったりしたので､今回は数を減らしています。今回のほうが､コンポー
2006-03-20
http://www.nikkeibp.co.jp/information/newsrelease/newsrelease20060317.html 「産業や社会に大きなインパクトをもたらす優れた技術」としてSeasar2が認められたことをうれしく思います。これも、Seasar2にかかわる多くの皆様のおかげです。どうもありがとうございます。 今の日本のIT業界はあまり人気がないと聞いています。その理由の1つには、IT業界に夢をもてないということがあるのでしょう。しかし、ITは社会を発展させるためになくてはならないものです。 一人でも多くの人がIT業界に夢を持てるように、今後も努力しつづけたいと思います。 第一弾として､1万個のオブジェクトを登録して､なんのDIも行わず､単に取り出すやつを測定してみました。Seasarのバージョンは､2.3.7、Springは1.2.6です。これは、この後最
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[ThinkIT] 第2回：init処理とprototype (1/3)
[ThinkIT] 第2回：init処理とprototype (1/3)