[ThinkIT] 第4回：AOP機能のパフォーマンス比較 (4/4)

TOP＞システム開発＞ AOP自動登録

パフォーマンス徹底比較!! Seasar2 VS Spring

第４回：AOP機能のパフォーマンス比較
著者：株式会社電通国際情報サービス  比嘉康雄
         株式会社アークシステム  本間宏崇
         日本ヒューレット・パッカード株式会社   2006/7/6

前のページ 1 2 3 4

AOP自動登録

   それでは今回の最後に、AOPを複数のコンポーネントへまとめて仕掛ける処理の時間を見てみましょう。

   実案件では複数のコンポーネントへAOPをかけることが多いので、AOPメソッド実行の項で設定したように、個々のコンポーネントへAOP設定を行うのはかなりの手間がかかります。

   そのため両コンテナとも複数のクラスへまとめてAOPを仕掛ける仕組みを提供しています。Seasar2ではAspectAutoRegister、SpringではAutoProxyCreatorです。

測定プログラム

それぞれの設定ファイルは以下のようになります。

設定ファイル（Seasar2）


			<components>

			   <component name="greetInterceptor" class="xxx.GreetInterceptor" />

			   <component

			      class="org.seasar.framework.container.autoregister.AspectAutoRegister"

			   >

			      <property name="pointcut">"toString"</property>

			      <property name="interceptor">greetInterceptor</property>

			      <initMethod name="addClassPattern">

			         <arg>"xxx"</arg>

			         <arg>"nullBean[0-9]{5}"</arg>

			      </initMethod>

			   </component>


			   <component name="nullBean00000" class="xxx.NullBean00000" />

			   <component name="nullBean00001" class="xxx.NullBean00001" />

			   :

設定ファイル（Spring）


			<beans>

			   <bean id="debugAdvisor" class="org.springframework.aop.
support.RegexpMethodPointcutAdvisor">

			      <property name="pattern"><value>.
*toString</value></property>

			      <property name="advice">

			         <bean name="greetInterceptor" class="xxx.GreetInterceptor" />

			      </property>

			   </bean>

			   <bean 

			      name="proxyCreator" 

			      class="org.springframework.aop.framework.
autoproxy.DefaultAdvisorAutoProxyCreator"

			   >

			      <property name="proxyTargetClass"><value>true</value></property>

			   </bean>

			   <bean name="nullBean00000" class="xxx.NullBean00000" />

			   <bean name="nullBean00001" class="xxx.NullBean00001" />

			   :

Seasar2とSpringのどちらのコンテナも、正規表現でAOP対象を指定しています。ここでは登録されているすべてのコンポーネントのtoStringメソッドをAOPでのカスタマイズ対象としています。インスタンスモードはsingletonです。

結果

図4にコンテナ生成、図5にコンポーネント取得の結果を示します。

図4：AOP自動登録でのコンテナ生成

図5：AOP自動登録でのコンポーネント取得

図4のコンテナ生成にかかる差は15〜60倍ほどで、実際の時間ではコンポーネント1,000個の場合に15秒と、先ほどの結果よりもさらに大きな値です。また図5の1度目のコンポーネント取得は、ほぼ同じ結果となりました。

理由

まずコンテナ生成時に発生する差についてですが、これは今まで述べたことの積み重ねであるといえます。特に大きいのはこの2点と考えられます。

リフレクション情報キャッシュの性能差
AOP weavingの性能差

表2：コンテナ生成時の差の理由

次にコンポーネント取得時の結果がほぼ同じになったのは、コンテナ生成時にAOPのweaving処理やコンポーネント生成までが完了しており、コンポーネントを返しているだけだからと考えられます。

終わりに

   今回の測定結果でweavingは時間がかかる処理ということがわかりました。前回のDI処理も重い部類ではありましたが、weavingの方がより重い結果となっています。

   ただし重い処理とはいってもweavingを行うのは1コンポーネントにつき1回ですから、システム利用者がアクセスするタイミングでweaving処理が走らないようにすればよいと考えます。

   幸い両コンテナともにコンテナ生成時にweavingしているため、この点に関しては特に手を動かす必要がないのは嬉しいところです。

   さて、4回にわたってDIコンテナの基本的な機能についてのパフォーマンスを比較考察してきましたがいかがでしょうか。

   筆者にはSeasar2とSpringで、同じDIを扱うライブラリでありながら「速度差がでたこと」「AOPのweavingには思った以上に時間がかかること」の2点が新鮮でした。

   最後に、気づいた点をあげておきます。

   コンポーネント数が少ない場合はどちらのコンテナでも性能差はそう目立たないでしょう。またSeasar2に比べて、Springはコンテナ生成が遅い傾向にあります。表3にコンテナ生成時に実行されるロジックの性能差があらわれる点をあげます。

リフレクション情報のキャッシュ処理（第1回）
SingletonコンポーネントのDI対象を探す処理（第3回）
AOPのweaving（第4回）

表3：コンテナ生成時の性能差

Springでは、prototypeコンポーネントへDIする場合に、コンテナに登録されているコンポーネント数に比例して遅くなります。この処理はコンポーネントが必要になったとき、つまり利用者がアクセスしたタイミングで行われるので、意識しておく必要があるでしょう（第3回）。

本連載が皆さんのお役に立てば幸いです。

前のページ 1 2 3 4

著者プロフィール
株式会社電通国際情報サービス比嘉康雄
1992年、電通国際情報サービス入社。1996年にOracleに触れたことでソフトウェアの魅力に開眼。その後、日本産オープンソース「Seasar」の開発を中心になって行い、2004年5月に「Seasar2」をリリース。
http://www.isid.co.jp/
http://d.hatena.ne.jp/higayasuo/

著者プロフィール
株式会社アークシステム本間宏崇
プログラマ。2004年より(株)アークシステムに所属。最近の興味はペアプログラミング・テスト駆動開発・プロジェクト自動化など。現在はWebアプリケーションフレームワーク「Teeda
（http://teeda.seasar.org/ja/）」の開発に携わっている。

著者プロフィール
日本ヒューレット・パッカード株式会社
今回、Seasar2とSpringのパフォーマンスの検証を行う際の環境を提供しています。

INDEX
第4回：AOP機能のパフォーマンス比較
	はじめに
	AOPメソッド実行の処理
	AOPのweaving処理
	AOP自動登録