2016-07-28 13 views
0

ここの文書http://www.ibm.com/support/knowledgecenter/SS7JFU_7.0.0/com.ibm.websphere.express.doc/info/exp/ae/rejb_ecnt.htmlには、デフォルトでejbごとに最低50個のインスタンスと最大500個のインスタンスが作成されていると記載されています。Websphere ejb pool

特定の時点で、クライアントがサービスを使用しようとしているとします。ここから、いつでも500インスタンスがあることを意味しますか?または、一定期間後にクライアントが入ってこない場合、サーバーはインスタンスを破棄しますか?

さらに読んだところで、指定された最大数のインスタンスを作成しないようにコンテナに指示するハード限界Hという名前がありました。

それでは、私は50500の場合に理解することはインスタンス(500)の最大数が存在することになる任意の時点で

  1. です。
  2. さらに多くのクライアントが接続しようとすると、サーバーはクライアントごとに新しいインスタンス(501,502,503 ....)を作成し、クライアントにサービスを提供した後にそのインスタンスを破棄します。

私は正しいか誰にでも教えていただけますか?

答えて

1

プールするEJBインスタンスを使用すると、システムリソースを節約できます。ある時点で100インスタンスのEJBが必要であるとします。豆を初期化し、ロジックを処理して破棄します。その後100インスタンスを追加する必要がある場合は、これをもう一度やり直す必要があります。これはシステムリソースに負担をかける。

EJBインスタンスをプールすると、EJBインスタンスはプールされ、EJBコンテナによって維持されます。アクティブなインスタンスは着信要求を処理し、受動的なインスタンスはプールに残ります。プールのサイズを制御するには、プール内のインスタンス数の上限と下限が必要です。

デフォルト設定を考慮してください:最小は50インスタンス、最大は500インスタンスです。サーバーが起動すると、サーバー上にEJBのインスタンスは存在しません。アプリケーションが同時リクエスト/ヒットを取得すると、プールサイズが増加します。 30の同時ヒットがあるとしましょう。プール・サイズは30のままです。WebSphereは、プール・サイズを最小値に維持するために、追加のインスタンスを作成しません。この時点で、WebSphereは追加の25個のEJBインスタンスを破棄し、プール・サイズを50に維持します。ここで、下限を 'H50'と定義すると(ハード・リミット)、WebSphereはサーバー/アプリケーションの起動時に50のEJBインスタンスを作成するためにリソースを消費します。したがって、プール・サイズは決して50を下回ることはありません。

ここで、上限は500です。同時ヒット数が増加すると、プール・サイズは増加し、500を超えます。この制限を超えると、WebSphereはEJBインスタンスが非アクティブ(プールに戻る)になるとすぐに破棄して、プール・サイズを小さくします。ただし、EJBインスタンスはこの制限を超えて拡張し続けることができます。 600の同時リクエストがある場合、600のEJBインスタンスが存在します。それが540に下がると、追加の60の豆が破壊されます。ハードリミット( 'H500')は、このオーバーフローが起こらないことを保証します。最大500の同時リクエストは、プールの最大サイズで処理できます。追加の要求は、EJBインスタンスが非アクティブになる(つまりプールに戻る)まで待機する必要があります。

関連する問題