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