3.3 EJBコンテナのチューニング

Interstage Application Server チューニングガイド

目次索引

第3章 J2EEのチューニング

3.3 EJBコンテナのチューニング

　EJBコンテナをチューニングする時に考慮するポイントは以下です。

同時処理数
Session Bean
Entity Bean
Message-driven Bean
JNDI
性能オプション

■同時処理数

　同時処理数は、1プロセスあたりの実行多重度です。IJServerで同時に処理できるクライアントのリクエスト数は、プロセス多重度と同時処理数で決まります。例えばプロセス多重度を2、同時処理数を16に設定すると、合計で2×16＝32の処理が同時に処理できます。クライアントからのリクエストが、処理できるリクエスト数を超えた場合は、キューイングされます。

同時処理数を変更することで、1プロセスあたりの実行多重度を増やすことができますが、同時処理数が増えることによる使用資源(CPU使用率、メモリ量など)の増加により、効果が見られない場合があります。
資源が不足している場合には、後から実行されたリクエストをキューイングすることにより、レスポンスの安定を図ります。

◆プロセスへの処理振り分け

　プロセス多重度を2以上に設定した場合、クライアントからの処理をEJB objectが少ない最適なプロセスに振り分けます。EJB objectが同数の場合には、特定のプロセスに処理を振り分けます。複数のEJBアプリケーションが配備されている場合、配備されているEJBアプリケーションのEJB objectの総数が少ないプロセスに処理を振り分けます。EJB objectの総数が少ないプロセスのスレッドがすべて使用されている場合には、EJB objectの総数が少ないプロセスのスレッドに空きがでるまで処理されません。

　同時処理数には以下のように最小値と最大値の設定ができます。
　通常はデフォルト値で運用することを推奨しています。

定義項目	デフォルト値	説明
最小値	16	IJServer起動直後から、EJBコンテナで同時処理可能なスレッド数です。クライアントのリクエスト数が最小値を超えた場合は、自動的に拡張して動作します。
最大値	64	拡張可能な同時処理数の最大値です。クライアントのリクエスト数が最大値を超えた場合は、リクエストはキューイングされます。

■Session Bean

　リソースを効果的に利用するために、Session Beanにおいては以下の設定を行います。

◆STATEFULとSTATELESSの選択

　STATELESS Session Beanを使用することで、メモリ資源やオブジェクトの生成回数が抑止されるため、処理性能が向上します。
　STATEFULとSTATELESSには以下の違いがありますので、用途に合わせて使い分けてください。

	STATEFUL	STATELESS
対話状態	createからremoveまで同一のオブジェクトにアクセスするため、クライアントとの対話状態を保持することができる。	クライアントとの対話状態を持たないため、クライアントが情報を保持する必要がある。
トランザクション	Session Beanのsynchronization機能を使って、トランザクションとの同期が可能。	１メソッド内でトランザクションを完了させる必要がある。
性能	クライアントごとにEJB objectを生成するため、STATELESSに比べてメモリ使用量が多い。	インスタンスやEJB objectを使い回すため、メモリ使用量を抑止することができる。また、オブジェクトの生成回数が抑止される。

◆STATEFUL Session Beanの無通信監視

createメソッドで作成したオブジェクトに対してremoveメソッドを実行せずに終了した場合、残存するオブジェクトを自動的に消去するため、不要なメモリの増加を防ぐことができます。

デフォルト値は、30(分)です。

◆Session Beanのcreateメソッド実行数の上限

　createメソッド実行数を高負荷の実行環境に合わせて変更できます。
　以下の計算式で算出された値が、デフォルト値の1024を超過する場合には、Session Beanのcreateメソッド実行数の上限値を変更してください。

(クライアントアプリケーションのプロセス数)*(1プロセス数あたりの実行スレッド数の平均)

※ createメソッド実行数はInterstage管理コンソールで設定します。

　createメソッドで作成したオブジェクトをremoveメソッドで削除しなかった場合、無通信監視機能でタイムアウトが発生するまでオブジェクトが残存するため、メモリの使用量が多くなる可能性があります。create数の上限値は適切な値に設定してください。

【設定範囲】

種類	設定値
初期設定値	1024
最小値	1
最大値	2147483647

■Entity Bean

◆Entity Bean 呼出しの注意

　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のインスタンス数を設定することにより、同時にメッセージ処理を行うことができます。
　目安としては、キューにメッセージが蓄積されない程度のインスタンス数を設定します。ただし、クライアント数とMessage-driven Bean処理時間に依存するため、環境に合わせ試験運用を行い、調整後に設定してください。

◆異常時のメッセージ退避機能

　Point-To-Pointメッセージングモデルでかつ不揮発化チャネルを利用する場合、リトライ回数を超過してもメッセージ受信を繰り返す可能性があります。

　イベントチャネルのイベントデータをメモリにキャッシュする数を、イベントチャネルに蓄積できるイベントデータの最大値よりも大きく設定してください。

　設定はイベントサービス運用コマンドを使用して行います。詳細は“リファレンスマニュアル（コマンド編）”の“essetcnf"および"essetcnfchnl"を参照してください。

■JNDI

◆オブジェクトの使い回し

　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

項目	設定内容
定義ファイル格納ディレクトリ	Interstage インストールディレクトリ\ejb\etc /opt/FJSVejb/etc
定義ファイル	FJEJBconfig.properties
指定するキー名	“LookupCache”(固定)
指定する値	“1”：同一オブジェクトへの2回目以降のlookupメソッド実行時にはメモリに保持した情報を返却します。 “1”以外： lookupメソッドを実行する度に、各ネーミングサービスにアクセスします(デフォルト)。

■性能オプション

　EJBサービスでは処理性能を向上させるため、以下の性能オプションを提供しています。

◆複数レコードの一括更新

　EJBコンテナは、複数レコードの一括更新でトランザクション中に同一のCMP1.1 Entity Beanに対して複数回更新する場合に、データベースへのアクセス回数を削減し、処理性能を向上しています。

　複数レコードの一括更新は以下の場合に動作します。

使用するデータベース、および、JDBCドライバがJDBC2.0バッチ更新機能をサポートしている必要があります。
JDBC2.0バッチ更新機能が未サポートのデータベース、および、JDBCドライバを使用した場合は、通常のデータベースへの更新処理を行います。
分散トランザクションを使用しない場合のみ、有効になります。
分散トランザクションを使用する場合、通常のデータベースへの更新処理を行います。

◆SQL文のキャッシュ

　EJBコンテナは、データベースに発行するSQL文をEJBサービス内部でキャッシュすることにより、SQL文の準備に必要な処理を削減して処理性能を向上します。

　SQL文のキャッシュは以下の場合に動作します。

CMP Entity Beanを使用する。
使用するデータソースが、従来のDBアクセス環境定義を使用して定義した場合で、DBアクセス環境定義時にJDBCドライバのバージョンにJDBC1.Xを選択した場合に有効になります。
データベースとしてSymfowareを使用する場合、MAXSQLに対する定義を行ってください。

MAXSQLは、以下の計算式を参考にして値を算出してください。
　　キャッシュするSQL文＝a * 4 + b
　　a： IJServerに配備されたCMP Entity Beanの総数
　　b： CMP Entity Beanがもつfinderメソッドの総和数

◆ローカル呼出し機能

　IJServerに配備されたEJBアプリケーションが、同一のEJBコンテナ内のEJBアプリケーションからだけで呼び出される場合、ローカル呼出し機能を使用できます。
　ローカル呼出し機能を使用することによって、ネットワークを介してEJBアプリケーションを呼び出されることを考慮したIJServerの処理が軽減されるため、通常よりも更に性能良く動作します。

　「ローカル呼出し」を“する”に設定したEJBアプリケーションをプロセス外から呼び出した場合、“CORBA OBJ_ADAPTER”のエラーが発生します。

　IJServerがEJBアプリケーションのみ運用する場合、または、WebアプリケーションとEJBアプリケーションを別JavaVMで運用する場合にだけ有効です。

　ローカル呼出し機能の設定はInterstage管理コンソールの［ワークユニット］ > ［IJServer名］ > ［EJBアプリケーション］ > ［アプリケーション環境定義］ > ［Interstage拡張情報］の“ローカル呼出し”で行います。設定の詳細についてはInterstage管理コンソールのヘルプを参照してください。

　Entity Beanをプロセス外から呼び出す場合には、「ローカル呼出し」を“しない”に変更してください。また、ローカル呼出しをしない場合には、EJB objectをタイマで削除してください。EJB objectのタイマ削除については“J2EEユーザーズガイド”の“EJB objectのタイマ削除機能”を参照してください。

目次索引