[Seasar-user:4629] Re: S2ContainerImpl#internalGetComponentDef のsynchronizedについて

[Amatatsu Tetsurou]

天辰と申します。

遅くなりましたが、Seasar-user:4592の件の続きです。
前回は赤羽から質問させていただきましたが、
負荷テストは私が担当しておりますので続きは私からさせていただきます。

1.
>どのようなテストをなされているでしょうか。
>単純に複数のスレッドでgetComponent()するだけだと
>たしかに待ち状態になると思いますが、

＜環境＞
ＡＰサーバ：8CPU16コア、(javaには4GBのヒープ）
ＤＢサーバ：12CPU24コア、Oracleは11GBメモリ割り当て
ネットワークは1000Bbps

  同時ユーザ数を増やしながら、当方のアプリケーションのログイン処理＋
ログイン後のページ表示を行いながら、テストを行っています。
  internalGetComponentDefがネックになっているという判断は、
上記でユーザー数を増やしながらテストを実施していると、
CPU,メモリ,ネットワーク,ディスクI/Oなどのリソースがかなり余っている
状態でレスポンス時間が悪化していくため、その状態のTomcatのスレッドダンプを
取得したところ、上記部分待ち状態になっているスレッドが多数表示されためです。
  またCPU数を2CPU(4コア)に減らして同様のテストを行っても上記部分がネックに
なっていることを確認しました。
また、下記のとおりより明確にするための検証も行い確信にいたりました。

2.
>通常は、DBへの処理だとかがはるかに時間を食うので
>本当にinternalGetComponentDefのsynchronizedで
>問題になることはないのではないかと思っています。
  単一スレッドの処理で見れば、該当箇所がＤＢへの処理より
  重いと言うことは無いはずですが、今回はマルチスレッド環境で
　実施し確かに該当箇所のsynchronizedで多数の待ちが発生していることを
　確認しました。

よりはっきりさせるために、以下の２つの検証を行いました。
検証1：s2-framework-2.3.7.jarからs2-framework-2.3.11.jarへのバージョンアップを行う。
　※internalGetComponentDefのパフォーマンスが向上する改修がなされている事が
　　分かっているためこのようにしました。
検証2：s2-framework-2.3.11.jarにバージョンアップ後に、S2ContainerImplクラス内に
　宣言されているsynchronizedを全て削除したソースを作成して適用する。

結果：
検証1の実施結果
　処理実行時のレスポンスタイムは大幅に改善しましたが、
　CPUリソースを使い切らずにレスポンスが悪化する問題及び、
　CPU数を増やしても状況が改善しない問題は解決しませんでした。
　ソースコードの変更内容を確認させていただきましたが、
　synchronizedを外す対応ではなくsynchronized時間を短縮させる
　対応であるように見受けられました。
検証2の実施結果
　CPUリソースを使い切らずにレスポンスが悪化する問題及び、
　CPU数を増やしても状況が改善しない問題いずれも
　「解決しました。」

3.
>昔のS2Strutsは動的にコンポーネントを登録していたので、
>登録と取得がぶつかるケースがあり、synchronizedの処理を
>入れていました。
動的にコンポーネントを登録するためにsynchronizedを
行っているのであれば、
動的な登録は出来ない代わりにsynchronizedによるパフォーマンス低下
が発生しないオプションを付けるなど根本的な解決を希望します。

以上


> 赤羽と申します。
> 
> 　現在、Seasar2を利用したアプリケーションにおいて
> 負荷テストを実施してるのですが、以下の部分に
> ついてsynchronized宣言されているため
> 各スレッドが待ち状態で詰まってしまっているようです。
> 
> 【箇所】
> 　S2ContainerImpl#internalGetComponentDef　メソッド
> 
> 【環境】
> 　java version "1.5.0_07"
> 　s2-framework-2.3.7.jar
> 　s2-struts-1.2.2.jar
> 　s2-dao-1.0.32.jar
> 　s2-extension-2.3.7.jar
>