私はJava EE 6 Webアプリケーションを作成しています。オブジェクトを直接作成して使用する場合に比べて、パフォーマンスに大きな影響を与えています。オーバヘッドは、メソッド呼び出しごとに50〜60msのオーダーであるように見えます。CDIを使用した場合のパフォーマンスへの影響
たとえば、注入されていない150のメソッド呼び出しを使用すると約500msかかりますが、注入されたオブジェクト150のメソッド呼び出しを使用すると12,000-13,000msかかります。大きさの違いの順序といくつか。
これは通常ですか？
私はCDIを処理するためにWeldを使用するJBoss AS 7.1.1 finalで動作しています。
注入オブジェクトは、（javax.ejb.Singletonアノテーションを介して）シングルトンBeanとして定義されます。これは問題の一部を引き起こす可能性がありますか？それとも、スローダウンを引き起こすWeldプロキシですか？
私がいることを発見した優れた溶接のフォーラムからいくつかの助け後：デフォルトでは
を、シングルトンセッションBeanがトランザクションです（EJB 3.1仕様のセクション13.3.7 ）との排他的 の取得が必要ですビジネスメソッド呼び出しごとにロック（セクション4.8.5.4および 4.8.5.5）。対照的に、javax.inject.Singletonはトランザクションではなく、コンテナ管理の同時実行性をサポートしていません（結果的に、 コンテナによってロックスキームが実装されていないというメジャー ）。
あなたは @TransactionAttribute（NOT_SUPPORTED）と@Lock（READ）を使用してシングルトンセッションBeanに注釈を付ける場合は、まだいくつか のオーバーヘッドがあるかもしれませんが、あなたは、 有意に優れた性能を確認する必要があります。 EJB機能が必要ない場合は、 @ApplicationScoped（javax.inject.SingletonはCDIで定義されていないため、 のセマンティクスはその仕様に準拠していません）。でも@TransactionAttribute（NOT_SUPPORTED）と@Lock（READ）の性能はまだ非常に不良であった（オリジナルのポストからタイミングを参照）と私のEJBシングルトンに注釈を付けた後、悲しいことに
https://community.jboss.org/thread/213684?tstart=0
。
したがって、take homeメッセージは、発生する可能性のあるパフォーマンスオーバーヘッドを絶対に必要とし、それから認識していない限り、EJB SingletonセッションBeanを注入しません。まれにしか呼び出されないメソッドについては、無視できるものですが、私たちのケースでは、頻繁に使用されるメソッドであれば、小さなオーバーヘッドが急速に蓄積されます。
EJBの機能は必要なく、注入されたBeanに呼び出された特定のメソッドのパフォーマンスがApplicationScopedで大幅に向上しました。
パフォーマンスがそれほど気になる人は、まずはJava EEを使用しています。私はプロキシのインターセプタがあなたのコードのボトルネックになることを真剣に疑っています。つまり、インターセプトされたメソッド呼び出しの中にデバッガにブレークポイントを設定して、通過する必要があるプロキシのレイヤ数を調べることです。過剰な量が適用されるような構成上の問題がある可能性があります。 – millimoose
@Singletonではなく、注入されたオブジェクトをApplicationScopedに変更すると、処理が大幅に向上しました。なぜ誰かがこれについてのフィードバックを持っているなら、私は考えていないし、興味があります。 – Troup
それは...奇妙です。私はまだコールチェーンの違いが何であるかを見るためにデバッガでそれを突き詰めていました。さもなければ私達は1つの漠然とした症状の原因を推測することに固執している。一般的に私はこのオーバーヘッドの原因がAOPであるべきだと考えていますが、それは何よりも推測です。 – millimoose