前へ     目次     索引     DocHome     次へ     
iPlanet Application Server パフォーマンスおよびチューニングガイド



第 4 章   iPlanet Application Server のチューニング


この章では、最大のパフォーマンスを得るために iPlanetTM Application Server をチューニングする包括的な手順を示します。この節では次のトピックについて説明します。



サーバプロセスのパフォーマンスの最適化

Executive Server (KXS)、Java エンジン (KJS)、 C++ エンジン (KCS)、および RMI/IIOP ブリッジプロセス (CXS) が iPlanet Application Server の核を形成しています。この節では、こうしたプロセスをチューニングしてパフォーマンスとスケーラビリティを最大にする方法について説明します。

この節では、次のトピックについて説明します。


iPlanet Application Server プロセスのチューニング

Executive Server (KXS)、Java エンジン (KJS)、および C++ エンジン (KCS) は、ワーカースレッドのプールを使ってリクエストを非同期的に処理します。これらのスレッドは、アプリケーションコンポーネントへのユーザのリクエストを処理します。iPlanet Application Server はリクエストを受け取ると、利用可能なスレッドにそのリクエストを割り当てます。スレッドはリクエストに対するシステムのニーズを管理します。たとえば、現在ビジー状態のシステムリソースが必要な場合、スレッドはそのリソースが解放されるのを待ってからリクエストにそのリソースの使用を許可します。

リクエストのスレッド数は、iPlanet Application Server のそのインスタンスが使用するすべてのプロセスについて、グローバルに調整できます。これは、プロセスレベルでも調整できます。


注

プロセスレベルの設定値はサーバレベルの設定値より優先されることに注意してください。設定のチューニングは、iPlanet Application Server Administration Tool を使って行います。


この節では次のトピックについて説明します。


KXS パフォーマンスの最適化

Web コネクタプラグインは、iPlanet Application Server アプリケーションへのユーザリクエストを実行プロセス (KXS) に送ります。これらのリクエストは実行プロセスのリクエストキューに記録されます。

次のタスクを実行して、KXS パフォーマンスを最適化できます。

  • Web コネクタプラグインがプロセスリクエストに対して使う最大スレッド数の制御。これにより、リクエストキューが処理能力以上のリクエストを受け付けないようにします。iPlanet Application Server のインストールでは、KXS のスレッド数はデフォルトで 32 に設定されます。スレッドは 128 まで増やせますが、64 あれば十分です。スレッドを増やす場合は KXS を少なくとも 1 つのプロセッサにバインドし、mutex ロックを取得するスレッドで時間を浪費しないようにすることをお勧めします。

  • リクエストのフローを制御するための、リクエストキューに記録する最大リクエスト数の設定。最大数を「高水位」と呼びます。

  • ログが再開されるキューのリクエスト数の設定。この数を「低水位」と呼びます。

  • 1 つのプロセッサまたはプロセッサセットへの KXS のバインド。これは、負荷テスト中にリクエストを KXS でキューに入れた場合にだけ実行します。これは KJS には実行しないでください。iPlanet Application Server では、JDK はマルチプロセッサ用に最適化されており、1 つのプロセッサにバインドしてもパフォーマンス上の利点がないためです。また、1 つのプロセッサにバインドしても KXS のパフォーマンスが向上しない場合は (KXS プロセスの CPU 使用率が高い場合など)、2 つのプロセッサを使って 1 つのプロセッサセットにすることができます。こうすると、KXS はこのプロセッサセットにバインドされます。

Executive Server (KXS)、Java サーバ (KJS)、C++ サーバ (KCS)、CORBA Executive Server (CXS) などのサーバプロセスが失敗すると、Administration Server によって再起動されます。再起動オプションを使うと、プロセスが再起動される回数を増減できます。フォールトトレランスとアプリケーションの可用性は、すべてのプロセスがスムーズに実行されているときに向上します。


KJS パフォーマンスの最適化

iPlanet Application Server のインストール時に、KJS スレッド数は 32 に設定されます。スレッドは 48 まで増やすことができます。KJS のスレッドは 48 が最適な設定数です。


リクエストスレッド数の調整

デフォルトのスレッドプールは、プロセスあたり 8 スレッドです。最大 32 まで設定できます。アプリケーションからのリクエスト用に確保するスレッドの最小数と最大数を指定することができます。スレッドプールはこれらの 2 つの値の間で動的に調整されます。アプリケーションリクエストに備えて、ユーザが指定した最小のスレッド数が維持されます。スレッドは、ユーザが指定した最大値まで増加します。

プロセスで使用可能なスレッドの数を増やすと、そのプロセスは同時により多くのアプリケーションリクエストに応答できるようになります。サーバレベルで、各プロセスのスレッドの追加や調整を行ったり、そのサーバのすべてのプロセスのスレッド数を定義したりできます。

これらのパラメータの最適な設定は、アプリケーションによって異なります。たとえば、リクエストに大量のデータベース処理が含まれており、データベースサーバのハードウェアへの負荷が軽くて同時処理が増えても処理できる場合は、プールサイズを多少大きくして大量のリクエストをデータベースに送り、スループットを増加させるようにします。一般に、スレッドプールのサイズは、KXS プロセスでも KJS プロセスでも 32 〜 48 スレッドまでは、大きいほどよいと考えられます。プールサイズの最小値と最大値もこの数に合わせて最初は 32 に設定し、必要に応じて 48 で試してみることをお勧めします。必要なパラメータは、iASAT を使って一度にすべて設定することもできます。

デフォルトでは、各プロセスは iPlanet Application Server に割り当てられているスレッドを使います。たとえば、iPlanet Application Server が最小 8、最大 64 のスレッドを使う場合、個々のプロセスは最小 8、最大 64 のスレッドを使います。


サーバおよびエンジンの最大シャットダウン時間の指定

iPlanet Application Server とエンジンプロセスの両方に、Administration Server の最大エンジン再起動回数を設定できます。たとえば、エンジンシャットダウン時間を 60 秒に設定すると、処理中のアプリケーションタスクは処理を完了するのに 60 秒まで認められます。この期間の経過後は、新しいリクエストを受け付けません。シャットダウン値を指定することによって、クライアントにエラーを返す「ハード」シャットダウンを回避します。値の設定は、iPlanet Application Server Administration Tool を使って行います。

最大サーバシャットダウン時間: 「最大サーバシャットダウン時間」は、iPlanet Application Server をシャットダウンするまでの最大時間です。この時間を過ぎると、実行中のすべてのエンジンが強制終了されます。通常、負荷が大きくないかぎり、サーバはすぐにシャットダウンされます。

最大エンジンシャットダウン時間: 「最大エンジンシャットダウン時間」は、iPlanet Application Server がエンジンのシャットダウンを待つ最大時間です。この時間を過ぎると、エンジンは強制終了され、次のエンジンがシャットダウンされます。

すべてのログのスイッチオフ

入力と出力を繰り返すことによるシステムへの負担を軽減するために、KJS ログに記録されるアプリケーションログをすべてスイッチオフします。これにより、著しくパフォーマンスが向上します。

MaxBackups = 1 の設定

通常のアプリケーションサーバアーキテクチャでは、Sync Backup サーバが 1 台あるとクラスタ内通信の数が減少します。1 つのクラスタの Maxbackups (最大バックアップ数) を 1 に設定します。0 に設定すると、プライマリが利用不能になったときのセッションのバックアップはありません。2 に設定するとクラスタ内通信が増加し、サーバの負荷が大きくなります。そのため、このパラメータの設定は 1 が最適です。


RMI/IIOP のパフォーマンスチューニング

RMI/IIOP パスで多数の同時ユーザに対応しなければならない配置環境の場合は、この節で説明するチューニングを実行してください。RMI/IIOP を使う場合、JVM のデフォルト設定とその基本 OS だけでは最適なパフォーマンスおよび容量を達成できません。

この節には次のトピックがあります。


パフォーマンス問題の認識

RMI/IIOP クライアントアプリケーションを負荷状態で実行する前に、基本構造のテストが成功していることを確認してください。

負荷状態のクライアントアプリケーションの実行を開始する際、RMI/IIOP クライアントに次の例外が発生する場合があります。

org.omg.CORBA.COMM_FAILURE

java.lang.OutOfMemoryError

java.rmi.UnmarshalException

アプリケーションの基本構造は正しく動作することが確認されている場合に、アプリケーションの負荷テスト時にこれらの例外が発生した場合は、次の節で説明する RMI/IIOP 環境のチューニング方法を参照してください。


基本的なチューニング方法

次に説明するチューニング方法を試し、ユーザの環境に最適なバランスを見つけてください。

Solaris ファイル記述子の設定: Solaris の場合、ulimit を使って、開いているファイル数のプロパティを最大に設定すると、サポートできる RMI/IIOP クライアントの最大数に影響を与えます。このプロパティのデフォルト値は、Solaris 2.6 または Solaris 8 のどちらを実行しているかによって、64 または 1024 となります。制限数を増やすには、次のコマンドを /etc/system に追加し、再起動します。

set rlim_fd_max = 8192

次のコマンドを使うと、この使用制限を確認できます。

ulimit -a -H

上記の使用制限を設定後、次のコマンドを使うと、このプロパティの値をこの制限まで明示的に増やすことができます。

ulimit -n 8192

次のコマンドを使うと、この制限を確認できます。

ulimit -a

たとえば、ulimit がデフォルトの 64 の場合、1 つのテストドライバがサポートできる同時クライアントは 25 ですが、ulimit を 8192 に設定すると、同じテストドライバで 120 の同時クライアントをサポートできます。テストドライバは複数のスレッドを生成します。これらの各スレッドは JNDI 検索を実行し、ビジネスメソッド呼び出し間の思考 (遅延) 時間が 500 ミリ秒の同じビジネスメソッドを繰り返し呼び出し、約 100 KB のデータを送受信します。

これらの設定値は RMI/IIOP クライアント (Solaris)、および Solaris システムにインストールされた RMI/IIOP ブリッジに適用されます。ファイル記述子の制限の設定については、Solaris のマニュアルを参照してください。

Java ヒープ設定値: ファイル記述子の容量をチューニングするだけでなく、クライアントおよびブリッジ JVM の両方について異なるヒープ値も設定できます。詳細については、第 5 章「Java 実行時システムのチューニング」を参照してください。


スケーラビリティの向上

1 つのブリッジプロセスおよびクライアントシステムの容量をチューニングするだけでなく、複数の RMI/IIOP ブリッジプロセスを使うことによって、RMI/IIOP 環境のスケーラビリティを向上させることができます。同じアプリケーションサーバインスタンス上で複数のブリッジプロセスを設定すると、アプリケーション配置のスケーラビリティが向上します。場合によっては、それぞれ 1 つまたは複数のブリッジプロセスを使って設定した多数のアプリケーションサーバインスタンスを使うこともできます。

複数のブリッジプロセスがアクティブな設定では、一連のクライアントをさまざまなブリッジにスタティックにマッピングするか、またはクライアントサイドに独自のロジックを実装して既知のブリッジプロセスと照らし合わせてロードバランスを行うことによって、クライアント負荷を分割できます。


RMI/IIOP のファイヤウォールの設定

RMI/IIOP クライアントがファイヤウォールを通過して iPlanet Application Server と通信する場合は、RMI/IIOP ブリッジプロセスが使うクライアントシステムから IIOP ポートへのアクセスを有効にする必要があります。クライアントのポート番号は動的に割り当てられるため、RMI/IIOP トラフィックがクライアントシステムからファイヤウォールを通過してアプリケーションサーバのインスタンスに達するように、ソースポートの範囲を広げ、1 つのデスティネーションポートを開く必要があります。

さらに、Converter サンプルアプリケーションを一度実行すると、2 つのシステム間の IIOP トラフィックが巡回ベースで追跡されます。ホスト swatch は RMI/IIOP クライアント、ホスト mamba は、デスティネーションシステムまたはアプリケーションサーバシステムです。RMI/IIOP ブリッジプロセスに割り当てられているポート番号は 9010 です。動的に割り当てられた 2 つのポート (33046 および 33048) は RMI/IIOP クライアントで使われます。一方、ブリッジプロセスとの通信にはポート 9010 が使われます。

swatch -> mamba.red.iplanet.com TCP D=9010 S=33046 Syn Seq=140303570 Len=0 Win=24820

Options=<nop,nop,sackOK,mss 1460>

mamba.red.iplanet.com -> swatch TCP D=33046 S=9010 Syn Ack=140303571 Seq=1229729413 Len=0 Win=8760

Options=<mss 1460>

swatch -> mamba.red.iplanet.com TCP D=9010 S=33046 Ack=1229729414 Seq=140303571 Len=0 Win=24820

swatch -> mamba.red.iplanet.com TCP D=9010 S=33046 Ack=1229729414 Seq=140303571 Len=236 Win=24820

mamba.red.iplanet.com -> swatch TCP D=33046 S=9010 Ack=140303807 Seq=1229729414 Len=168 Win=8524

swatch -> mamba.red.iplanet.com TCP D=9010 S=33046 Ack=1229729582 Seq=140303807 Len=0 Win=24820

swatch -> mamba.red.iplanet.com TCP D=9010 S=33048 Syn Seq=140990388 Len=0 Win=24820

Options=<nop,nop,sackOK,mss 1460>

mamba.red.iplanet.com -> swatch TCP D=33048 S=9010 Syn Ack=140990389 Seq=1229731472 Len=0 Win=8760

Options=<mss 1460>

swatch -> mamba.red.iplanet.com TCP D=9010 S=33048 Ack=1229731473 Seq=140990389 Len=0 Win=24820

swatch -> mamba.red.iplanet.com TCP D=9010 S=33048 Ack=1229731473 Seq=140990389 Len=285 Win=24820

mamba.red.iplanet.com -> swatch TCP D=33048 S=9010 Ack=140990674 Seq=1229731473 Len=184 Win=8475

swatch -> mamba.red.iplanet.com TCP D=9010 S=33048 Ack=1229731657 Seq=140990674 Len=0 Win=24820

swatch -> mamba.red.iplanet.com TCP D=9010 S=33048 Ack=1229731657 Seq=140990674 Len=132 Win=24820

mamba.red.iplanet.com -> swatch TCP D=33048 S=9010 Ack=140990806 Seq=1229731657 Len=25 Win=8343



分散セッションと Lite HTTP セッションの比較

分散セッションではセッションデータが iPlanet Application Server のバックアップノードに複製されるので、可用性が向上します。そのためには、分散セッションに配置されるオブジェクトが java.lang.Serializable インタフェースを実装している必要があります。

ただし、セッションサイズが大きく、頻繁に書き込まれる場合は、ネットワークのトラフィックが増大します。キューが使用されていることで分散セッションにアクセスする JSP と Servlet のパフォーマンスも低下しますが、その規模は使用する HttpSession の数とサイズによって異なります。Lite セッションの可用性とパフォーマンスはトレードオフの関係にあります。セッションオブジェクトは KJS プロセスにローカルにキャッシュされます。KJS プロセスはそのセッションの全リクエストを保存する場所として機能します。

Java オブジェクトが HttpSession に格納される場合は、Lite セッションにも利点があります。Lite セッションのオブジェクトはそれぞれの KJS プロセスにキャッシュされるため、ネットワークの Java オブジェクトを直列化する必要がありません。このため、HTTPSession に Java オブジェクトが格納されると、このオブジェクトは java.lang.Serializable インタフェースを実装する必要がなくなります。

必要なセッションタイプは ias-web.xml の <session-info>/<impl> プロパティを編集して指定します。

注

Lite セッションに切り換えることによるパフォーマンスの向上は、8 〜 40% と報告されています。




高可用セッションの単一バックアップ設定


これは、高可用セッション (dsync 分散) を使い、HttpSession フェールオーバーにプライマリとセカンダリを設定している場合だけに当てはまります。クラスタに対するレジスタ設定の Maxbackups は、1 にする必要があります。0 に設定すると、プライマリが利用不能になったときのセッションのバックアップはありません。2 に設定すると、クラスタの内部通信が増加します。このパラメータの最適な設定値は 1 です (デフォルト)。

このパラメータは、次の iPlanet レジストリキー内に設定できます。

Software¥iPlanet¥Application Server¥6.0¥Clusters¥<cluster-name>¥MaxBackups



Dsync セッション管理スレッドの設定


Dsync は、分散ステート同期サービスです。指定した Dsync プライマリとバックアップにはセッションノードのメモリデータベースが含まれています。HTTP セッションがタイムアウトもしくは無効になった場合、メモリ内のデータベースからすぐに削除する必要があります。専用スレッド数を増やすと、削除と記録をほとんど同時に行うことができます。

レジストリで次のプロパティを設定してください。メモリが一時的に増加する問題を解決し、セッションノードをより効率的に無効化できます。次のように設定すると、KXS 削除スレッドが iPlanet レジストリ内で 20 になります。

Software¥iPlanet¥Application Server¥6.0¥CCSO¥ENG¥0¥SyncTimeoutThreadCount=20

KJS エンジン #1 にも同じことをする場合は、iPlanet レジストリ内で次のキーを変更します。

Software¥iPlanet¥Application Server¥6.0¥CCSO¥ENG¥1¥SyncTimeoutThreadCount=20

スレッドがアクティブな場合は次の方法で間隔を設定します。

Software¥iPlanet¥Application Server¥6.0¥CCSO¥ENG¥<n>¥SyncTimerInterval

デフォルトは 60 です。この設定で十分です。
注

この方法で直接パフォーマンスが向上するわけではありませんが、小さなセッションオブジェクトを保存しておくと必ず役に立ちます。また、すぐに効率よく削除すると、KXS プロセスと KJS プロセスでのメモリリークを防ぐこともできます。


セッションを削除するために HttpSession タイムアウトに頼らないことをお勧めします。削除には HttpSession.invalidate() メソッドを使います。このメソッドが使えない場合は、配置環境でのデフォルトの HttpSession タイムアウトをできるだけ小さく設定してください。



ロードバランスのオプション


この節では、次のトピックについて説明します。


クラスタ設定のロードバランス

iPlanet Application Server 環境では、クラスタはステートとセッションの情報を共有して保存するサーバコレクションとして定義され、データ同期サービス (Dsync) によって実行されます。

したがって、Dsync は指定したクラスタのサイズを制約する共有リソースです。一般に、iPlanet Application Server の各クラスタは最大 4 個のインスタンスで実行されます。それ以上のサーバが必要な場合は、Web サーバ層のスティッキーロードバランスを使ってクラスタを複数にします。ステート情報とセッション情報が Dsync に格納されていない場合は、並行して実行できるサーバ数に制限はありません。最適な設定は、iPlanet Application Server Sizing Tool を使って見つけます。

クラスタ設定のロードバランスには次の 2 つのシナリオが考えられます。

シナリオ 1:

2 つの iPlanet Application Server クラスタが 1 つの LDAP 設定ツリーを共有する。

このシナリオでは、すべての iPlanet Application Server が同じ LDAP 構成ツリーを共有しています。スティッキーロードバランスをサポートするために、スティッキーロードバランスメソッドをルータで作動させる必要はありません。

次の図にこの設定を示します。この図では、受信したリクエストは青い矢印間で設定 LDAP を共有することで示され、LDAP のアクセスは赤い矢印で示されています。

図 4-1    1 つの LDAP 設定ツリーを共有する 2 つのアプリケーションサーバ


奨励する使用法 :

この設定は各アプリケーションが 1 つのクラスタだけに存在する場合に有効です。このシナリオには、アプリケーションを分離し、Web 層を単純化する利点があります。

設定 :

iPlanet Application Server のインストール時に、すべてのクラスタのすべての iPlanet Application Server に同じ LDAP と同じ設定ルートを指定します。

シナリオ 2 :

iPlanet Application Server クラスタを別々の LDAP 設定ツリーに割り当てる。

このシナリオでは、各 iPlanet Application Server クラスタの LDAP 設定ツリーに枝があります。各 iPlanet Application Server クラスタには、専用の iPlanet Web Server が少なくとも 1 つあります。リクエストが iPlanet Web Server に到着すると、iPlanet Web Server は 1 つの iPlanet Application Server クラスタしか知らないため、リクエストは常にクラスタ内の iPlanet Application Server に送信されます。ルータの役目は、個々の iPlanet Web Server 間の負荷を分散することです。

スティッキーロードバランスのサポートを有効にするには、ルータのスティッキーオプションをオンにして、後続のリクエストも同じ iPlanet Web Server に送信されるようにする必要があります。

次の図にこの設定を示します。この図では、受信したリクエストは青い矢印間で設定 LDAP を共有することで示され、LDAP のアクセスは赤い矢印で示されています。

図 4-2    別々の LDAP ツリーに割り当てられた 2 つのアプリケーションサーバクラスタ

奨励する使用法 :

この設定は、アプリケーションがクラスタ間配置を必要とする場合に有効です。このシナリオの利点は、1 つのクラスタで新しいバージョンのアプリケーションを使用できることと、1 つのクラスタで提供できる以上の処理能力を必要とするアプリケーションに対応できることです。


情報のブロードキャストと更新

ロードバランスが有効に機能するために、プロセスに関連する各サーバには、ほかのすべてのサーバについての最新情報がなければなりません。つまり、ロードバランスに影響を与える要因についての情報がすべての iPlanet Application Server マシンにブロードキャストされる必要があり、また、各 iPlanet Application Server マシンでは、ロードバランスの決定を行うためにこの情報を監視して更新する必要があります。情報をブロードキャストする頻度が多すぎると、ネットワークトラフィックが増え、応答時間が遅くなる可能性があります。ただし、ロードバランス情報が頻繁に計算および更新されない場合は、ロードバランスを決定するために iPlanet Application Server が使用する情報が古くなるため、アプリケーションコンポーネントの負荷のリスクが適切に分散されなくなります。

ロードバランスについての意思決定を行うときに、2 つの主要なジレンマに直面します。

  • どのくらいの頻度で iPlanet Application Server サーバがロードバランス情報を更新したらよいか

  • どのくらいの頻度で各 iPlanet Application Server インストールがロードバランス情報をブロードキャストしたらよいか

更新の間隔: ほとんどの場合、最低 5 秒間、最高 10 秒間が適切です。通常、安定した状態で各サーバでもっともよく使用されるアプリケーションコンポーネントの応答時間の 2 倍を、更新間隔の基準にします。たとえば、もっともよく使用されるアプリケーションコンポーネントが 5 秒間でリクエストに応答するシステムでは、更新間隔を 10 秒間に設定します。更新の頻度を多くするとサーバの作業量も増え、ロードバランスの特性さえも変えてしまうことがあります。この計算には注意を払ってください。非常によく使用されるアプリケーションコンポーネントの応答時間が 1.5 秒だったとしても、更新間隔を 3 秒に設定しないでください。


注

非常によく使用されるアプリケーションコンポーネントの応答時間が 1.5 秒だったとしても、更新間隔を 3 秒に設定しないでください。


ブロードキャスト間隔: 上記で説明したように、ロードバランス情報のブロードキャストの頻度が多すぎると、ネットワークトラフィックが増えるだけでなく、iPlanet Application Server の作業負荷も増大します。これは、すべてのサーバが情報を記録して収集するためです。通常、更新間隔の値の 2 倍にブロードキャスト間隔の基準を設定します。

iPlanet Application Server Administration Tool 内のロードバランスのツールを使用して、更新間隔とブロードキャスト間隔を設定します。


ロードバランス情報の監視

ロードバランスの基準を設定するときは、精細なチューニングプロセスに忍耐強く臨んでください。ロードバランスの基準を最適な組み合わせにするには、一定期間、iPlanet Application Server の設定を注意深く監視することが必要です。その期間中に、ピーク時の負荷、リクエストの各タイプの割合、平均応答時間、ボトルネックなどの統計データを収集する必要があります。各システムが異なるパラメータと基準で配置されているため、すべての iPlanet Application Server ユーザに対して、1 つの同じソリューションはあり得ません。iPlanet Application Server 配置のすべての側面と同様、サイトに配置された iPlanet Application Server システムの長期にわたるパフォーマンスを向上させる最適な基準を決定できるのは、管理者だけです。

ロードバランスについて、および iASAT を使用してロードバランスの基準を設定する方法については、『iPlanet Application Server 管理者ガイド』にある「ユーザリクエストのロードバランス」を参照してください。


奨励するクラスタのロードバランス設定

iPlanet Application Server のインストール時に、すべてのクラスタ内のすべての iPlanet Application Server に同じ LDAP を指定します。クラスタが 1 つの場合はすべての iPlanet Application Server に同じ設定ルートを指定し、クラスタが異なる場合は異なる設定ルートを指定します。


クラスタのセッションサイズの最適化

セッションサイズは、iPlanet Application Server クラスタのパフォーマンスにもっとも影響を与えます。iPlanet Application Server を数多くインストールした結果、パフォーマンスを最大にするにはセッションサイズを 4K 以下にすべきことがわかりました。セッションサイズが大きくてもシステムは機能しますが、パフォーマンスが低下します。パフォーマンスが低下する主な原因は、システムのプライマリとホットバックアップがセッションデータを同期させるために常に通信していることです。

次のいずれかの方法を使って、セッションのパフォーマンスを向上させることができます。

  • セッションで最も重要な要素だけを格納する

    アプリケーション作成者が重要なデータを指定し、セッションにこのデータだけを格納します。分散する必要がないデータはセッションから除外されます。

  • セッションにスティッキーロードバランスを使用する

    スティッキーロードバランスとセッション分散は同じ数式の別々の値ですが、関連があり、同時に有効にすることができます。スティッキーロードバランスでは、1 つのクライアントは常に同じ KJS に転送されます。このため、セッションではなく JVM メモリへのデータストレージが可能になります。セッションに格納する必要があるのはキー (ハッシュテーブルやアレイなどのキー) だけです。セッション内のデータ量が著しく減るため、パフォーマンスが向上します。

    この設定では、クライアントのリクエストを扱う iPlanet Application Server が使えなくなると、リクエストはクラスタ内の別の iPlanet Application Server インスタンスに転送されます。キーはこのセッションにあるので、データを再作成してメモリに格納することができます。これにより、リクエストは新しい KJS に転送されます。

    このオプションは、セッションのデータがアクセスされ LDAP サーバなどの二次ソースに格納される場合に有効です。

  • 別のデータストアを使って大量のセッションデータを直列化する

    この概念では、システムに新しい変数、つまりデータベースが導入されます。ここで考えられているのは、セッションの大部分をデータベースに格納してセッションにはプライマリキーだけを格納するというものです。そうすればセッションは小さくなり、パフォーマンスが向上します。これには、データベーススキーマを注意深く計画し、データベースアクセスの速度を上げる適切な検索インデックスを作成することが必要です。


個々の JSP のロードバランス

iPlanet Application Server では、JSP のロードバランスを個別に行うことができます。これは XML 記述子で JSP に GUID を割り当てることによって実行され、Servlet に GUID を割り当てる方法に似ています (JSP の登録に関する節を参照)。JSP に GUID を割り当てると、Servlet と同じように iPlanet Application Server Administration Tool を使って JSP にロードバランスを行うことができるようになります。


スティッキーセッションロードバランスの使用

Web アプリケーションの Servlet にスティッキーロードバランスが設定されていると、Web パフォーマンスが最大になります。この設定では、アプリケーションサーバや Web コネクタプラグインのユーザセッションのロードバランスが取られます。セッションの最初のユーザリクエストは、最適な候補である KJS プロセスまたはサーバにロードバランスされます。これ以降、同じユーザのセッションは同じプロセスに送信されます。このため、追加された KJS プロセスはセッションオブジェクトをローカルにキャッシュし、パフォーマンスが向上します。スティッキーロードバランスは分散セッションでも使用できます。

Servlet や JSP をスティッキーにするには、ias-web.xml の <servlet>/<servlet-info>/<sticky> プロパティをオンに設定します。配置ツールとパッケージツールにより、自動的にスティッキーがオンになります。

注

パフォーマンスが 10% 前後向上したというテスト結果が報告されています。



セッションデータの単純化

次のような理由から、オブジェクトはセッションに格納した後で直列化します。

  • iPlanet Application Server の分散セッションは単純なデータ要素で動作するように調整されています。規模の大きい直列化されたオブジェクトは体裁も悪く、パフォーマンスに著しい影響があります。セッションを最大限に活用するには、データは個別の単純なデータ要素として格納する必要があります。

Java コーディングの観点からは、直列化と直列化解除は時間がかかる操作なので避けた方が賢明です。



データベースコネクションプールの設定


iPlanet Application Server には、コネクションをプールする機能があります。この機能で、わずかなデータベースコネクションが多くのスレッドに多重送信されます。最初に使うときはコネクションは試験的に確立されますが、閉じられることはありません。すでに開かれているコネクションは、アプリケーションサーバのプロセスが存在しているかぎり再利用できます。

コネクションプールは、JDBC データソースとユーザの一意の組み合わせごとに作成されます。アプリケーションでコネクションを得るために、呼び出すごとにユーザとパスワードを変える DataSource.getConnection (user,password) を使用すると、同じデータソースに対して複数のプールを作成することができます。

このプールのサイズが、KJS に設定されているワーカースレッドの数よりもわずかに多いことを確認します。必要なデータベースについては、レジストリの CacheInitSlots プロパティと CacheMaxConn プロパティを設定します。

たとえば、iPlanet Application Server に含まれている Oracle JDBC ドライバを使う場合、iPlanet レジストリの次のキーでプロパティを変更します。

Software¥iPlanet¥Application Server¥6.0¥CCS0¥DAE2¥ORACLE_OCI

注

すべてのスレッドでユーザリクエストを同時に処理し、データベースにアクセスする必要がある場合は、プールのコネクション数と KJS プロセスのワーカースレッド数が同じである必要があります。データベースへのアクセスが集中するアプリケーションでは、明らかにパフォーマンスが向上します。


この節には次のトピックがあります。


データベースコネクションプール設定のガイドライン

iPlanet Application Server 内のコネクションプールは、次のようなさまざまなレベルで設定できます。

  • データソース XML ファイル内

  • レジストリの変更

  • Administration Tool による動的な設定

    設定可能なコネクションプールのパラメータについては、『iPlanet Application Server 管理者ガイド』を参照してください。

コネクションプールを設定する際は、次の一般的なガイドラインに従ってください。

  • データベースのバックエンドごとに論理データソースを使用します。複数の論理データソースが同じバックエンドをポイントしている場合は、リソースが最適に利用されていない可能性があります。

  • 回復時間は、主として、コネクションを解放しないアプリケーションがコネクションを回復するための時間なので、できるだけ大きく保ちます。回復時間の後に使用されたとしても、コネクションの回復で生じる副作用があるためです。

  • maxPoolSize の値は、このデータソースから行おうとした物理的な接続数に合わせます。

  • minPoolSize の値は、このデータソースにアクセスするデータベースに関連した同時接続ユーザの平均リクエスト数に合わせます。

  • コネクションがプールからアプリケーションに与えられる前に、コネクションの妥当性がチェックされます。最初のチェックは setAutoCommit に基づく単純な妥当性に関してであり、次のチェックはテーブルに基づく妥当性に関してです。

    ほとんどの場合は、単純な妥当性のチェックで十分です。ただしある種の JDBC ドライバでは、単純な妥当性で不備なコネクションを認識することができません。

    そのため、データベースドライバが単純な妥当性チェックをサポートしているときにだけそれを使用し、データベースのバックエンドが適度にフェールセーフである場合は、isSanityRequired を false に設定します。

  • アプリケーションで DataSource.getConnection (username,password) を呼び出し、ユーザ名とパスワードが毎回異なる場合は、コネクションプールの設定を非常に小さく保ちます。


コネクションプールを設定するための統計の使用

iPlanet Application Server では、コネクションプールを設定するために使用できる豊富なコネクションプールの統計がサポートされます。

統計の設定と収集については、『iPlanet Application Server 管理者ガイド』を参照してください。

一般的な提案には、次のものがあります。

  • 「ドロップしたコネクション総数」がゼロでなく、「プール内のコネクション総数のピーク値」が MaxPoolSize に達していなかった場合は、データベースのバックエンドに余分なコネクションを与える余裕はない

    この問題を避けるために、データベースのバックエンドのコネクション数を増やして設定するか、MaxPoolSize の値を増やすことができます。

  • 「キューサイズのピーク値」がゼロでない場合は、コネクションのリクエスト数が maxPoolSize より多く、コネクションのリクエストはキューに入れられる。「キューサイズのピーク値」が 5 より大きい場合は、maxPoolSize を増やすことが望ましい

  • 「キャッシュのミス数」の数値がゼロ以上で、「プール内のコネクション総数のピーク値」が maxPoolSize に達していなかった場合は、minPoolSize をさらに大きな値に増やすことができる



実行時の EJB パラメータの設定

iPlanet Application Server では、EJB コンテナによって、ユーザ独自の EJB コンポーネントやほかのベンダコンポーネントを使って、分散アプリケーションを構築できます。企業向けに iPlanet Application Server を設定する場合は、EJB コンテナの宣言パラメータを設定する必要があります。たとえば、これらのパラメータで、EJB が指定された時間 (秒単位) アクティブでなかった場合に削除されるセッションタイムアウトを決定します。iPlanet Application Server Administration Tool を使ってこれらのパラメータを設定します。

設定可能な値は次のとおりです。

    • デフォルトのセッションタイムアウト

      デフォルトのセッションタイムアウトは 14400 秒です。これは、HttpSession オブジェクトが使われないために削除されるまでの間、オブジェクトが存在できる時間です。できるだけ小さい有効な値を設定します。状態のあるセッション EJB に適用されます。

    • デフォルトの不活性化タイムアウト

      デフォルトの不活性化タイムアウトは 60 秒です。Beans の作成率が非常に低く、しかも Beans サイズが大きい場合は、この時間を増やす必要がある場合があります。ただし、この値を増やしても、ほとんどの事例でパフォーマンスに影響がありません。

      Beans はファイルシステムに対して不活性化されるので、ファイルシステムが極端に活発な場合は、不活性化も極端になり、このパラメータを調整すると効果がある可能性があります。この値はセッションタイムアウトの値より小さくする必要があります。

    • メタデータのキャッシュサイズ

      メタデータのキャッシュサイズは 10 Beans です。これはホーム Beans のキャッシュが扱うサイズです。この値は、アプリケーションに存在する Beans の種類の数まで設定することができます。50 から 60 までであればほとんどのユーザアプリケーションを扱えます。EJBHome インスタンスがキャッシュされるので、同じホームインタフェースのその後の検索では、キャッシュの内容が使われます。

    • 実装キャッシュサイズ

      実装キャッシュサイズは 10 のインスタンスに設定されています。N 個の同時ユーザセッションが状態のあるセッション Beans にアクセスする場合、この値が N 以上に設定されていることを確認してください。状態のないセッション Beans では、この値を KJS のスレッド数以上に設定しても効果がないことがあります。同じことがエンティティ Beans にも言えます。この iPlanet Application Server Administration Tool の設定は、配置されているすべての Beans に適用されるため、制御が大まかになります。

      最大キャッシュサイズは EJB の数以内です。

    • タイマー間隔

      「タイマー間隔」で間隔を設定し、Beans 実装プールをスキャンして不活性化の候補を検索します。

      この間隔は iPlanet レジストリキーの CCSO¥EB¥EbInterval で指定することもできます。

      このパラメータで、エンティティおよび状態のあるセッション Beans の削除間隔を指定します。デフォルト値は 10 秒です。実験的な条件下では、タイマー間隔の設定値を小さくすると EJB コンテナが頻繁に停止して応答時間に影響が出ることが確認されました。設定値を極端に大きくすると、不活性化の時間が長くなります。

    • フェールオーバー保存間隔

      「フェールオーバー保存間隔」で、フェールオーバー用に設定されているすべてのアクティブな状態付きセッション Beans が状態を直列化し、Dsync メモリ内データベースに不活性化される間隔を指定します。これは時間がかかる操作で、Beans のサイズが大きすぎたり保存間隔が短すぎるとパフォーマンスに影響を与えます。

      状態のあるセッション Beans のフェールオーバーサポートの設定と使い方については、『iPlanet Application Server 開発者ガイド』を参照してください。

      サーバが失敗した場合、最後に保存された EJB のステートが復元されます。保存されたデータはクラスタ内にあるすべてのエンジンからアクセスできます。この値はサーバごとに設定され、Deployment Tool EJB 記述子エディタの「一般」タブで有効にしたフェールオーバーオプションで配置された EJB に適用されます。



JSP と Servlet のキャッシュ

各 iPlanet Application Server インスタンスの各 KJS エンジンによってキャッシュされる JSP ページの数を指定できます。JSP をキャッシュすることにより、アプリケーションの応答時間が最適化されます。

キャッシュサイズはページごとに設定されます。JSP キャッシュは、構造的な JSP の開発を目的にしています。Java エンジン内に JSP をキャッシュして、複数の JSP が含まれるマスター JSP を作成できます。各 JSP は、異なるキャッシュ基準を使ってキャッシュできます。たとえば、株式相場を表示するウィンドウや気象情報を表示するウィンドウなどを含んでいるポータルページでは、株式相場のウィンドウを 10 分間キャッシュし、気象通報のウィンドウを 30 分間キャッシュするというように設定できます。

JSP のキャッシュは結果キャッシュの追加機能なので、複数の JSP を取り込んである JSP を合成し、それぞれに異なるキャッシュ基準を持たせることができます。JSP には GUID があるため、使用できるようになった結果キャッシュを使って合成 JSP 自体を KXS にキャッシュすることができます (JSP の登録に関する節を参照)。

JSP のキャッシュには JSP 1.1 で提供されているカスタムタグライブラリのサポートを使います。キャッシュ可能な一般的な JSP ページは次のとおりです。

<%@ taglib prefix="ias" uri="CacheLib.tld"%>

<ias:cache>

<ias:criteria timeout="30">

<ias:check class="com.iplanet.server.servlet.test.Checker"/>

<ias:param name="y" value="*" scope="request"/>

</ias:criteria>

</ias:cache>

<%! int i=0; %>

<html>

<body>

<h2>Hello there</h2>

I should be cached.

No? <b><%= i++ %></b>

</body>

</html>

<ias:cache> および </ias:cache> はキャッシュの各制約条件を区切ります。<ias:criteria> タグはタイムアウト値を指定し、別のキャッシュ基準を囲みます。キャッシュ基準は <ias:check> と <ias:param> の両方のタグを使って表現できます。これらのタグの構文は次のとおりです。

<ias:criteria timeout="val" > は、キャッシュされた要素のタイムアウトを秒単位で指定します。キャッシュ基準はこれと終了用の </ias:criteria> <ias:check class="classname" /> の範囲内で指定されます。これはキャッシュ基準の指定メカニズムの 1 つです。classname は、「check」と呼ばれるメソッドを持つクラスを参照します。これは次のシグネチャを持ちます。

public Boolean check(HttpServletRequest req)

これは、要素がキャッシュされるかどうかを示すブール値を返します。

<ias:param name="paramName" value="paramValue" scope="request" /> :

このメカニズムでも各基準を指定することができます。

paramName は属性の名前です。この名前は setAttribute を使ってリクエストオブジェクトまたは URI に渡されます。これはキャッシュ基準として使用されるパラメータです。paramValue はパラメータの値で、キャッシュを実行するかどうかを決定します。これには次のような種類があります。

Constraint

Meaning

x = ""

x はパラメータまたは属性として存在している必要があります。

x = "v1|...|vk"、ここで vi は "*" にすることができます。

x のリクエストパラメータが、キャッシュされたバッファを格納するときに使われた値と同じ値を持つとき、現在のリクエストの制約は true になります。

x = "1-u"、ここで 1 および u は整数です。

x は、[1,u] の範囲内の値にマッピングされます。

この範囲は、チェックする属性のソースを指定します。ページ、リクエスト (デフォルト)、セッション、またはアプリケーションです。

キャッシュされる JSP の例は次のとおりです。

<%@ taglib prefix="ias" uri="CacheLib.tld"%>

<ias:cache>

<ias:criteria timeout="30">

<ias:check class="com.iplanet.server.servlet.test.Checker"/>

<ias:param name="y" value="*" scope="request"/>

</ias:criteria>

</ias:cache>

<%! int i=0; %>

<html>

<body>

<h2>Hello there</h2>

I should be cached.

No? <b><%= i++ %></b>

</body>

</html>

Checker は次のように定義されます。

package com.iplanet.server.servlet.test;

import javax.servlet.*;

import javax.servlet.http.*;

public class Checker {

String chk = "42";

public Checker()

{

}

public Boolean check(ServletRequest _req)

HttpServletRequest req = (HttpServletRequest)_req;

String par = req.getParameter("x");

return new Boolean(par == null ? false :par.equals(chk));

}

}

この例でキャッシュされた要素は、リクエストのパラメータが x=42 で、y がその要素の保存に使われた値と等しい場合に有効です。<ias:criteria> ブロック内に <ias:param> および <ias:check> の複数の組み合わせを持たせることができます。また、JSP 内に複数の <ias:criteria> ブロックを持たせることもできます。
注

* cache-criteria = "*" は使用できません。

* キャッシュ基準が正しく確立されると (arg="*")、動作が遅くなります。つまり、キャッシュできなかったときの更新、キャッシュヒット、次に更新、次にキャッシュヒットという動作です。



前へ     目次     索引     DocHome     次へ     
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.

最新更新日 2002 年 3 月 6 日