EJB 3.2のパフォーマンス低下

Question

現在、EJBプロジェクトをバージョン2.0からバージョン3.2（すべてステートフル）にアップグレードしています。ビジネスロジックは変わりませんが、EJBパーツが変更されるだけです（記述子ファイルを注釈で置き換えたり、従来のルックアップの代わりに注入ポイントを使用するなど）。 要求処理の観点からは、すべてが正常に動作しているようですが、問題はパフォーマンスです。 1つの接続されたクライアントでは、すべての要求に約300msかかります。 2番目のクライアントを追加すると、平均時間は700ミリ秒にジャンプします。第3のクライアントでは、平均は1秒を超えています。 EJB 2.0バージョンでは、クライアントが増えても処理時間はわずかに（50〜100ms）増加しますが、心配はありません。

劣化はかなり明白で、私は理由を理解できません。

私は、EJBのタイムアウト、トランザクションタイプなどで遊んだことがありますが、運がありません。私はまた、JMCを介してサーバーのプロファイリングを試みましたが、疑わしいものは見つかりませんでした。

これは、すべての要求が順番に処理され、同時に処理されない場合と同じです。

考えられる原因についていくつかヒントを挙げることはできますか？私は行方不明の設定はありますか？

注：問題はWebSphere 9とGlassFish 4.1.1の両方で発生するため、アプリケーションの問題であることは明らかです。

EDIT＃1

アプリケーションのログをチェックした後、私は要求が、何の並行処理を順番に処理されていないことを確認することができます。

マイケルの提案に続いて、私はスレッドダンプを見て、与えられた瞬間に、そこにあった。

• 27（オブジェクトモニター上）RUNNABLE
• 18 TIMED_WAITING
• 6 TIMED_WAITING（パーキング）
• 16 TIMED_WAITING（睡眠）（オブジェクトモニタ上）
• 23 WAITING
• 40 WAITING（パーキング）

ブロックされたスレッドの兆候はありません。

Answer 1

これはどのようにテストしていますか？

これは、複数のクライアントが同じステートフルセッションBeanインスタンスを取得しているように思います。

コンテナは、同じSFSBインスタンスへの呼び出しをシリアル化します。これを行うことになっています。それ以前に起きていない場合は、この動作を無効にするプラットフォーム依存のデプロイメント記述子がありました。

しかし、テストフレームワークを使用していて、すべてのクライアントが同じセッションを取得している場合は、問題があるように見えます。

§4.3。EJB仕様の13「シリアライズセッションBeanのメソッドは、」言う：

コンテナは各ステートフルとステートレスセッション Beanインスタンスの呼び出しをシリアル化します。ほとんどのコンテナは、同時に実行される セッションBeanの多くのインスタンスをサポートします。ただし、各インスタンスはメソッド呼び出しのシリアル化されたシーケンス のみを参照します。したがって、ステートフルまたは のステートレスセッションBeanは、リエントラントとしてコード化する必要はありません。

すべてのクライアント間で1つのSFSBインスタンスを共有する場合は、@Statefulから@Singletonに変更することが適切な場合があります。シングルトンEJBは、@ConcurrencyManagementおよび@Lockアノテーションを使用して明示的なリエントラント制御を行います。あなたはEJBのスレッドの安全性と完全に満足しているなら、あなたはとあなたの豆をマークアップして逃げることがあります。

@Singleton 
@ConcurrencyManagement(ConcurrencyManagementType.BEAN) 
public class MyStatefulSessionBeanMasqueradingAsASingleton { 
    ... 
}