EJBコンテナをチューニングするときに考慮するポイントを以下に示します。
同時処理数は、1プロセスあたりの実行多重度です。IJServerで同時に処理できるクライアントのリクエスト数は、同時処理数で決まります。例えば同時処理数を16に設定すると、16処理が同時に処理できます。クライアントからのリクエストが、処理できるリクエスト数を超えた場合は、キューイングされます。
同時処理数には以下のように最小値と最大値の設定ができます。
通常は省略値で運用することを推奨しています。
定義項目 | 省略値 | 説明 |
---|---|---|
最小値 | 16 | IJServer起動直後から、EJBコンテナで同時処理可能なスレッド数です。クライアントのリクエスト数が最小値を超えた場合は、自動的に拡張して動作します。 |
最大値 | 64 | 拡張可能な同時処理数の最大値です。クライアントのリクエスト数が最大値を超えた場合は、リクエストはキューイングされます。 |
注意
同時処理数を変更することで、1プロセスあたりの実行多重度を増やすことができますが、同時処理数が増えることによる使用資源(CPU使用率、メモリ量など)の増加により、効果が見られない場合があります。
資源が不足している場合には、後から実行されたリクエストをキューイングすることにより、レスポンスの安定を図ります。
リソースを効果的に利用するために、Session Beanにおいては以下の設定を行います。
■STATEFULとSTATELESSの選択
STATELESS Session Beanを使用することで、メモリ資源やオブジェクトの生成回数が抑止されるため、処理性能が向上します。
STATEFULとSTATELESSには以下の違いがあるので、用途に合わせて使い分けてください。
| STATEFUL | STATELESS |
---|---|---|
対話状態 | createからremoveまで同一のオブジェクトにアクセスするため、クライアントとの対話状態を保持することができる。 | クライアントと対話状態でないため、クライアントが情報を保持する必要がある。 |
トランザクション | Session Beanのsynchronization機能を使って、トランザクションとの同期が可能。 | 1メソッド内でトランザクションを完了させる必要がある。 |
性能 | クライアントごとにEJB objectを生成するため、STATELESSに比べてメモリ使用量が多い。 | インスタンスやEJB objectを使い回すため、メモリ使用量を抑止することができる。また、オブジェクトの生成回数が抑止される。 |
■STATEFUL Session Beanの無通信監視
createメソッドで作成したオブジェクトに対してremoveメソッドを実行せずに終了した場合、残存するオブジェクトを自動的に消去するため、不要なメモリの増加を防ぐことができます。
省略値は、30(分)です。
■STATEFUL Session Beanのcreateメソッド実行数の上限
createメソッド実行数を高負荷の実行環境に合わせて変更できます。
以下の計算式で算出された値が、省略値の1024を超過する場合には、Session Beanのcreateメソッド実行数の上限値を変更してください。
(クライアントアプリケーションのプロセス数)×(1プロセス数あたりの実行スレッド数の平均)
なお、createメソッド実行数は、Interstage管理コンソールの[Interstage Application Server] > [システム] > [ワークユニット] > “IJServer名” > “モジュール名” > “EJBアプリケーション名” > [アプリケーション環境定義] のInterstage拡張情報のStateful bean 同時接続数で設定します。
注意
createメソッドで作成したオブジェクトをremoveメソッドで削除しなかった場合、無通信監視機能でタイムアウトが発生するまでオブジェクトが残存するため、メモリの使用量が多くなる可能性があります。create数の上限値は適切な値に設定してください。
【設定範囲】
種類 | 設定値 |
---|---|
初期設定値 | 1024 |
最小値 | 1 |
最大値 | 2147483647 |
■Entity Bean 呼出しの注意
Entity Beanは、レコードの情報を取得するためにメソッドを頻繁に実行します。このため、プロセス外からEntity Beanを呼び出すとIIOP通信が頻繁に発生することにより、性能が劣化します。
Entity Beanは、同一IJServerのアプリケーションから呼び出すことを推奨します。
■インスタンス数
インスタンスはトランザクション内でキャッシュされます。インスタンスプールにインスタンスが存在しない場合、同一トランザクション内で使用したインスタンスのレコードデータをデータベースに反映し、そのインスタンスを別のレコードデータを格納するインスタンスとして再利用します。インスタンスが頻繁に再利用されると、データベースにアクセスする回数が増加することによって性能に影響があるので、性能を考慮してインスタンス数を設定してください。
インスタンス数はデータベースの検索レコード数とクライアントの同時接続数に関係します。効果的な値としては、通常検索されるレコード数の1.25倍の値を設定します。
以下に設定値の計算式を表します。
Entityインスタンス数=axbx1.25(安全率)
a:一度に検索されるレコード数
b:1プロセスで同時にアクセスするクライアント数
例
10クライアントが同時に100件を検索した場合
インスタンス数=10×100×1.25=1250
注意
インスタンス数を増やすと、使用メモリが増えるので注意してください。
■インスタンス管理モード
Entity Beanのインスタンス管理モードによってデータベースの処理をチューニングすることができます。
以下の表に、それぞれのインスタンス管理モードと最適な処理について示します。
ReadWrite | 検索を実行するとき、またオンラインのデータベースを更新するときに有効 |
ReadOnly | 更新されない主要なデータを検索(参照)するときに有効 |
Sequential | 大量のデータを一括処理するときに有効 |
Message-driven Beanのインスタンス数を設定することにより、同時にメッセージ処理を行うことができます。
目安としては、キューにメッセージが蓄積されない程度のインスタンス数を設定します。ただし、クライアント数とMessage-driven Bean処理時間に依存するため、環境に合わせ試験運用を行い、調整後に設定してください。
■オブジェクトの使い回し
lookupメソッドで取得したオブジェクトは、EJBアプリケーション内で保持して使い回すことにより、lookupメソッドの実行回数を軽減できます。
■deployment descriptor定義
deployment descriptorファイルにオブジェクトの情報を定義した場合、定義された情報をもとに、各ネーミングサービスからIJServer起動時にオブジェクトを取得してメモリ上に保持するため、処理性能が向上します。
deployment descriptorファイルにオブジェクトの情報を定義しない場合、アプリケーションでlookupメソッドを実行したときにオブジェクトが各ネーミングサービスに存在しないかどうかを確認します。
deployment descriptorファイルにオブジェクトの情報を定義することを推奨します。すでに開発済みのEARファイルを使用する場合などでdeployment descriptorファイルの編集ができない場合には、以下のオプションを使用することで、ネーミングサービスへのアクセス回数を軽減できます。
このオプションを使用すると、lookupメソッド実行時に各ネーミングサービスから取得した情報をメモリ上に保持するため、同一のオブジェクトに対する2回目以降のlookupメソッドの処理性能が向上します。
なお、以下のオブジェクトを取得する場合には、本オプションを設定してIJServerを運用してください。
他のIJServerに配備されたEJBアプリケーションのHomeオブジェクト
データソース
JMSコネクションファクトリ
JMS Destination
項目 | 設定内容 |
---|---|
定義ファイル格納ディレクトリ |
|
定義ファイル | FJEJBconfig.properties |
指定するキー名 | “LookupCache”(固定) |
指定する値 | “1”:同一オブジェクトへの2回目以降のlookupメソッド実行時にはメモリに保持した情報を返却します。 |