WebLogic Server パフォーマンス チューニング ガイド
|
 |
 |
|
以下の節では、WebLogic Server をアプリケーションのニーズに合わせてチューニングする方法について説明します。
Java パラメータの値は、WebLogic Server を起動するたびに指定する必要があります。weblogic.Server コマンドを使用してコマンドラインから行うと、この作業を単純化できます。ただし、コマンドラインから WebLogic Server を起動するために必要な引数は長くなる場合があり、エラーが発生しやすくなるので、コマンドをスクリプトに組み込むことをお勧めします。このプロセスを単純化するため、WebLogic 配布キットに付属するサンプル スクリプトのデフォルト値を変更して WebLogic Server を起動することもできます。詳細については、「WebLogic Server インスタンスの Java オプションの指定」を参照してください。
コンフィグレーション ウィザードを使用してドメインを作成した場合、WebLogic 起動スクリプトはそのドメインを指定した domain-name ディレクトリに格納されます。このディレクトリは、デフォルトでは BEA_HOME\user_projects\domain\domain-name となります。BEA_HOME は製品のインストール ディレクトリ、domain-name は選択したコンフィグレーション テンプレートで定義されているドメイン ディレクトリの名前です。コンフィグレーション ウィザードを使用したドメインの作成については、『コンフィグレーション ウィザードの使い方』を参照してください。
それらのスクリプトのいくつかのデフォルト Java 値は、実際の環境やアプリケーションに合わせて修正する必要があります。これらのファイル内で重要なパフォーマンス チューニング パラメータは、JAVA_HOME パラメータと Java ヒープ サイズ パラメータです。
JAVA_HOME の値を JDK の位置に変更します。次に例を示します。"%JAVA_HOME%\bin\java" -hotspot -Xms512m -Xmx512m -classpath %CLASSPATH% -
ヒープ サイズ オプションの設定の詳細については、「ヒープ サイズ値の指定」を参照してください。
WebLogic Server のコンフィグレーション ファイル (config.xml) には、実際の環境やアプリケーションに合わせて細かくチューニングできるパフォーマンス関連の多くの要素があります。これらのパラメータをシステム要件に基づいてチューニングすることで、デフォルト設定のまま実行する場合に比べ、単一ノードのパフォーマンスおよびアプリケーションのスケーラビリティ特性を大きく向上させることができます。
WebLogic Server ドメインでは、管理サーバのホスト マシン上にあるコンフィグレーション ファイルが WebLogic MBean 属性値の永続ストレージを提供します。管理サーバは、サーバ インスタンスおよびシステム管理ツールとのやり取りの中心として機能します。ドメインには、管理対象サーバと呼ばれる追加の WebLogic Server インスタンスを含めることもできます。管理対象サーバは、主にアプリケーションへのサービスの提供に使用します。
管理サーバを起動すると、ドメイン コンフィグレーション ファイルが読み込まれ、管理 MBean のデフォルトの属性値がコンフィグレーション ファイル内の属性値でオーバーライドされます。システム管理ツール (コマンドライン インタフェースまたは Administration Console) を使用して属性値を変更するたびに、その値は適切な管理 MBean に格納され、コンフィグレーション ファイルに書き込まれます。
システム管理インフラストラクチャの詳細については、『WebLogic Server のコンフィグレーションと管理』の「WebLogic Server システム管理の概要」を参照してください。
表 4-1 に、サーバのパフォーマンスに影響を与えるconfig.xml ファイルのパラメータを示します。
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
ドメインを使用する環境として、開発環境またはプロダクション環境のどちらかを指定できます。WebLogic Server では、指定した環境の種類に応じて、各種サービスのデフォルト値に異なる値が使用されます。
表 4-2 に、開発起動モードとプロダクション起動モードで異なるパフォーマンス関連のコンフィグレーション パラメータを示します。
この『WebLogic Server パフォーマンス チューニング ガイド』で示すデフォルトのチューニング値は、WebLogic Server インストール時のデフォルトの起動モードである「開発モード」のデフォルト値です。開発起動モードからプロダクション起動モードへの切り替えについては、Administration Console オンライン ヘルプの「実行時モードの変更」を参照してください。
開発起動モードとプロダクション起動モードの違いについては、『コンフィグレーション ウィザードの使い方』の「コンフィグレーションの起動モードの相違点」を参照してください。
ベンチマークでは、WebLogic Server インスタンスのホスト マシンでネイティブ パフォーマンス パックを使用したときにパフォーマンスが大きく向上することが示されています。パフォーマンス パックでは、プラットフォーム用に最適化されたネイティブのソケット マルチプレクサを使用して、サーバのパフォーマンスを向上させています。たとえば、ネイティブ ソケット リーダー マルチプレクサ スレッドは独自の実行キューを持ち、デフォルトの実行キューからスレッドを借用することがありません。その分、自由になったデフォルトの実行スレッドをアプリケーションの処理に使用できることになります。
ただし、ホスト マシンで pure-Java ソケット リーダー実装を使用しなければならない場合でも、サーバ インスタンスおよびクライアント マシンごとにソケット リーダー スレッドの数を適切にコンフィグレーションすることによって、ソケット通信のパフォーマンスを向上させることができます。
現時点でパフォーマンス パックが使用可能な、サポートされているプラットフォームを確認するには、次の手順を行います。
配布キットと共に出荷されている config.xml では、ネイティブ パフォーマンス パックの使用がデフォルトで有効になっています。この設定をコンフィグレーション ファイルで確認するには、Server 要素の NativeIOEnabled 属性が「true」(NativeIOEnabled=true) に設定されているかどうかをチェックします。
パフォーマンス パックが有効になっているかどうかは、Administration Console を使用して確認することもできます。その場合は次の手順を行います。
config.xml ファイルの ExecuteQueue 要素の ThreadCount 属性の値は、実行キューを使用するアプリケーションで実行可能な同時処理の数と同じです。処理が WebLogic Server のインスタンスに渡されると、その処理は実行キューに置かれます。 次に、この処理は 1 つのスレッドに割り当てられて実行されます。スレッドはリソースを消費するため、この属性は注意して取り扱う必要があります。値を不必要に大きくすると、パフォーマンスが低下する可能性があります。
デフォルトでは、新しい WebLogic Server インスタンスには、weblogic.kernel.default という開発モードの実行キューがコンフィグレーションされています。この実行キューのスレッド数は 15 です。さらに、WebLogic Server には、あらかじめコンフィグレーションされた次の 2 つのキューが提供されています。
weblogic.admin.HTTP - このキューは、管理サーバのみにあり、Administration Console との通信用に予約されている (再コンフィグレーション不可)。weblogic.admin.RMI - このキューは、管理サーバと管理対象サーバの両方にあり、管理トラフィック用に予約されている (再コンフィグレーション不可)。追加の実行キューをコンフィグレーションし、それらにアプリケーションを割り当てない限りは、Web アプリケーションおよび RMI オブジェクトでは weblogic.kernel.default が使用されます。
注意 : ネイティブ パフォーマンス パックがプラットフォームで使用されていない場合は、パフォーマンスを最適化するために、実行キューのスレッドのデフォルト数とソケット リーダーとして機能するスレッドの割合をチューニングする必要があります。詳細については、「ソケット リーダーとしての実行スレッドの割り当て」を参照してください。
デフォルト実行キューにスレッドを増やしたからといって、必ずしもより多くの作業を処理できるわけではありません。スレッドを増やした場合でも、依然としてプロセッサの処理能力による制約を受けます。スレッドはメモリを消費するので、ThreadCount 属性の値を不必要に大きくすると、パフォーマンスが低下する可能性があります。実行スレッドを大きくすると、メモリの使用量が大きくなり、コンテキストの切り替えが増加し、パフォーマンスが低下する可能性があります。
ThreadCount 属性の値は、アプリケーションが実行する処理のタイプによって大きく異なります。たとえば、使用しているクライアント アプリケーションが軽量で、その処理の多くをリモート呼び出しを介して行う場合、そのクライアント アプリケーションが接続に費やす時間は多くの処理をクライアントサイドで行うクライアント アプリケーションより長くなり、その結果としてスレッド数の値をより大きくしなければならなくなります。
デフォルトの 15 (開発モード) または 25 (プロダクション モード) を超えるスレッドを使用する必要がない場合は、この属性の値を変更しないようにします。一般に、アプリケーションが応答に時間のかかるデータベース呼び出しを行う場合は、応答が早く時間のかからない呼び出しを行うアプリケーションより多くの実行スレッドが必要となります。 後者のケースでは、実行スレッドの数を減らすとパフォーマンスが向上します。
実行キューの理想的なスレッド数を決めるには、キュー内のすべてのアプリケーションが最大負荷で動作しているときにキューのスループットをモニタします。キューのスレッド数を増やし、キューのスループットが最適になるまで負荷テストを繰り返します。あるポイントまでスレッドの数を増やしていくと、コンテキストの切り替えが増えすぎて、キューのスループットが低下し始めるので注意してください。
注意 : WebLogic Server Administration Console には、サーバのすべての実行キューの累積スループットが表示されます。このスループット値を表示するには、「デフォルト スレッド数の変更」の手順 1 ～ 6 を行ってください。
表 4-3 に、WebLogic Server ドメインで使用できる CPU 数との関係で使用可能なスレッドを調整するためのデフォルトのシナリオを示します。 これらのシナリオも、WebLogic Server が最大負荷で動作し、すべてのスレッド リクエストがデフォルト実行キューを使用して満たされることを前提としています。追加の実行キューをコンフィグレーションして、特定のキューにアプリケーションを割り当てる場合は、結果をプールごとにモニタします。
|
|
Administration Console でデフォルト実行キューのスレッド数を変更するには、次の手順を行います。
デフォルト実行キューをコンフィグレーションして、すべての WebLogic Server アプリケーションに対して最適な数のスレッドを提供することができます。また、複数の実行キューをコンフィグレーションすると、重要なアプリケーションをより詳細に制御することができます。複数の実行キューを使用することにより、WebLogic Server の負荷に関係なく、選択したアプリケーションが固定数の実行スレッドに確実にアクセスできるようになります。コンフィグレーションされた実行キューへのアプリケーションの割り当てに関する詳細については、「実行キューによるスレッド使用の制御」を参照してください。
ソケットの最適なパフォーマンスを実現するには、WebLogic Server インスタンスのホスト マシン上では、pure-Java 実装ではなくネイティブのソケット リーダー実装を使用することをお勧めします (「WebLogic Server 「ネイティブ IO」パフォーマンス パックの使い方」を参照)。ただし、ホスト マシンで pure-Java ソケット リーダー実装を使用しなければならない場合でも、サーバ インスタンスおよびクライアント マシンごとにソケット リーダー スレッドとして機能する実行スレッドの数を適切にコンフィグレーションすることによって、ソケット通信のパフォーマンスを向上させることができます。
ThreadPoolPercentSocketReaders 属性は、ソケットからメッセージを読み込む実行スレッドの割合の最高値を設定します。この属性の最適値は、アプリケーションによって異なります。デフォルト値は 33、有効範囲は 1 ～ 99 です。
実行スレッドをソケット リーダー スレッドとして割り当てると、サーバがクライアント リクエストを受け入れる速度と能力が向上します。重要なのは、ソケットからメッセージを読み込む実行スレッドの数と、サーバでタスクを実際に実行するスレッド数のバランスを取ることです。
Administration Console を使用してソケットからメッセージを読み込む実行スレッドの割合の最高値を設定するには、次の手順を行います。
クライアント マシン上では、クライアントを実行する JVM 内で使用できるソケット リーダー スレッドの数をコンフィグレーションできます。ソケット リーダーを指定するには、クライアントの java コマンドラインで以下のパラメータを定義します。
-Dweblogic.ThreadPoolSize=value-Dweblogic.ThreadPoolPercentSocketReaders=value
デフォルトの実行キューやユーザ定義の実行キューでオーバーフローになりそうな条件を検出し、必要に応じて対応するように WebLogic Server をコンフィグレーションできます。WebLogic Server は、キューのサイズがユーザ定義の最大サイズにおけるパーセンテージに達した場合、キューにオーバーフロー条件の可能性があることを認識します。 しきい値に達すると、サーバは自己の状態を「warning」に変更し、必要に応じて、キュー内の未処理の作業を追加のスレッドに割り当ててそのサイズを軽減します。
キューのオーバーフロー条件を自動的に検出したり、対処したりするには、以下の項目をコンフィグレーションします。
QueueLength 値)。WebLogic Server Administration Console を使用して実行キューをチューニングするには、次の手順に従います。
注意 : 変更できるのは、サーバのデフォルト実行キューまたはユーザ定義の実行キューだけです。
WebLogic Server は、実行キューのスレッドが「スタック」状態になるとこれを自動的に検出します。スタック スレッドは現在の作業を終了したり新しい作業を承認したりできないため、サーバはスタック スレッドを診断するたびに、メッセージのロギングを行います。実行キューのすべてのスレッドがスタック状態になった場合、サーバは実行キューに基づいて自己の状態を「warning」または「critical」に変更します。
weblogic.admin.HTTP、weblogic.admin.RMI またはユーザ定義の実行キューのすべてのスレッドがスタック状態になった場合、サーバは自己の状態を「warning」に変更します。WebLogic Server は、設定した期間、作業状態が継続した (アイドルでない) 場合、スレッドをスタック状態と診断します。サーバのスレッド検出動作は、スレッドがスタック状態と診断されるまでの時間や、サーバがスタック スレッドをチェックする頻度を変更することでチューニングできます。
注意 : WebLogic Server がスレッドがスタックかどうかを判断するために使用する基準は変更できますが、特定の実行キューのすべてのスレッドがスタック状態になった場合に「warning」および「critical」状態を設定するデフォルト動作を変更することはできません。詳細については、「WebLogic ロギング サービスの概要」を参照してください。
WebLogic Server のスレッド検出動作をコンフィグレーションするには、次の手順に従います。
config.xml ファイルの Server 要素の AcceptBacklog 属性を使用すると、WebLogic Server インスタンスが受け入れる接続リクエストの数を設定できます (これ以上のリクエストは拒否されます)。AcceptBacklog 属性は、待機キューに格納できる Transmission Control Protocol (TCP) 接続の数を指定します。この固定サイズのキューには、TCP スタックでは受信されたが、アプリケーションにはまだ受け入れられていない接続リクエストが格納されます。デフォルト値は 50 で、最大値はオペレーティング システムによって異なります。
Administration Console から [バックログを受け入れ] 値をチューニングするには、次の手順を行います。
DBMS への JDBC 接続の確立には非常に時間がかかる場合があります。JDBC アプリケーションでデータベース接続のオープンとクローズを繰り返す必要がある場合、これは重大なパフォーマンスの問題となります。WebLogic 接続プールは、こうした問題を効率的に解決します。
WebLogic Server を起動すると、接続プール内の接続が開き、すべてのクライアントが使用できるようになります。クライアントが接続プールの接続をクローズすると、その接続はプールに戻され、他のクライアントが使用できる状態になります。つまり、接続そのものはクローズされません。プール接続のオープンとクローズには、ほとんど負荷がかかりません。
どのくらいの数の接続をプールに作成すればよいでしょうか。接続プールの数は、コンフィグレーションされたパラメータに従って最大数と最小数の間で増減させることができます。最高のパフォーマンスが得られるのは、同時クライアント セッションと同じくらいの数の接続が接続プールに存在する場合です。
以降の節に加えて、『WebLogic JDBC プログラマーズ ガイド』の「JDBC アプリケーションのパフォーマンス チューニング」も参照してください。
JDBCConnectionPool 要素の InitialCapacity 属性を使用すると、プールのコンフィグレーション時に作成する物理的なデータベース接続の数を設定できます。ここで指定した数の接続をサーバで作成できない場合、この接続プールの作成は失敗します。
開発時は、InitialCapacity 属性の値を小さく設定して、サーバがすばやく起動するようにしておくと便利です。プロダクション システムでは、InitialCapacity の値を、プロダクション モードの MaxCapacity のデフォルト値である 25 に設定するようにしてください。これにより、サーバの起動時にすべてのデータベース接続を取得できます。MaxCapacity 値をチューニングする必要がある場合は、InitialCapacity を必ず MaxCapacity 値と同じ値に設定してください。
InitialCapacity の値が MaxCapacity の値より小さい場合は、負荷が増加すると、サーバで追加のデータベース接続を作成しなくてはならなくなります。サーバに負荷がかかると、できるだけ速くリクエストを完了するためにすべてのリソースが処理に費やされることになり、新しいデータベース接続を作成できなくなります。
JDBCConnectionPool 要素の MaxCapacity 属性を使用すると、接続プールが保持できる物理的なデータベース接続の最大数を設定できます。JDBC ドライバおよびデータベース サーバによっては、可能な物理的接続の数が制限されている場合もあります。
開発モードとプロダクション モードのデフォルト設定は、実行スレッドのデフォルト数である 15 (開発モード) と 25 (プロダクション モード) と同じです。ただし、プロダクション システムでは、プール内の接続数を、JDBC 接続を必要とする並行クライアント セッションの数と同じにすることをお勧めします。プールのサイズは、サーバ内の実行スレッドの数とは無関係です。実行中のユーザ セッションが実行スレッドより多くなる場合もあります。
アプリケーションまたは EJB で Prepared Statement や Callable Statement を使用すると、アプリケーション サーバとデータベース サーバの間の通信およびデータベース サーバ自体においてかなりの処理オーバーヘッドが生じます。WebLogic Server では、処理コストを最小限に抑えるため、アプリケーションで使用する Prepared Statement や Callable Statement をキャッシュできます。アプリケーションまたは EJB がこれらの Statement を呼び出すと、キャッシュに格納された Statement が再利用されます。Prepared Statement や Callable Statement を再利用することで、データベース サーバの CPU の使用率が下がり、現在の Statement のパフォーマンスが向上するため、CPU サイクルを他のタスクに割り当てることができます。詳細については、Administration Console オンライン ヘルプの「Statement キャッシュによるパフォーマンス向上」を参照してください。
Statement キャッシュを使用することでパフォーマンスを大幅に向上させることができますが、制限があることも考慮に入れる必要があります。詳細については、Administration Console オンライン ヘルプの「Statement キャッシュに関する制限」を参照してください。
JSP サーブレットをコンパイルするための標準 Java コンパイラは javac です。サーバの Java コンパイラを javac ではなく sj または jikes に設定することにより、パフォーマンスを大幅に向上させることができます。 以降の節では、この手順とコンパイラに関するその他の考慮事項について説明します。
コンパイラを Administration Console で変更するには、次の手順を行います。
weblogic.xml ファイルでは、jsp-descriptor 要素を使用してサーブレット JSP のパラメータの名前と値を定義します。
compileCommand パラメータでは、生成される JSP サーブレットをコンパイルするための Java コンパイラを指定します。precompile パラメータでは、WebLogic Server の起動時に WebLogic Server で JSP をあらかじめコンパイルするようコンフィグレーションします。サーバの Java コンパイラを weblogic.xml ファイルで設定する作業の詳細については、jsp-descriptor 要素を参照してください。
weblogic.appc ユーティリティを使用すると、EJB 2.0 および 1.1 のコンテナ クラスをコンパイルできます。EJB コンテナにデプロイするために Jar ファイルをコンパイルする場合は、weblogic.appc を使用して、コンテナ クラスを生成する必要があります。ejbc は、デフォルトでは javac コンパイラを使用します。パフォーマンスを向上させるには、-compiler フラグを使用して別のコンパイラ (Symantec の sj など) を指定します。
詳細については、『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「エンタープライズ JavaBean の実装」を参照してください。
UNIX マシン上で JSP ファイルをコンパイルしているときに次のエラー メッセージが表示された場合、
failed: java.io.IOException: Not enough space
set rlim_fd_max = 4096
set rlim_fd_cur = 1024
-native フラグを使用してネイティブ スレッドを使用する。
WebLogic Server クラスタは WebLogic Server インスタンスのグループで、互いに連携してフェイルオーバおよびレプリケーション サービスを提供することにより、ドメイン内のクライアントに対してスケーラブルで可用性の高い運用をサポートします。クラスタはそのクライアントにとって単一のサーバに見えますが、実際にはスケーラビリティと信頼性を向上するために一体で機能するサーバ群です。
ドメインには複数の WebLogic Server クラスタと、クラスタ化されない WebLogic Server インスタンスが存在できます。ドメイン内でクラスタ化される WebLogic Server インスタンスの動作は、フェイルオーバとロード バランシングの機能を備えること以外は、クラスタ化されないインスタンスと同様です。インスタンスのすべてのコンフィグレーション パラメータは、そのインスタンスがクラスタ化されるかどうかにかかわらず、そのドメインの管理サーバによって管理されます。
クラスタの詳細については、「WebLogic Server のクラスタ化の概要」を参照してください。
スケーラビリティとは、リソースの追加に伴ってシステムが 1 つまたは複数の側面において拡張していく能力です。通常、これらの側面としては (他にも多数ありますが) サポート可能な同時接続ユーザの数や、一定時間に処理可能なトランザクションの数などが挙げられます。
優れたアプリケーションであれば、単にリソースを追加することによってパフォーマンスが向上します。WebLogic Server の負荷処理の機能を強化するには、新しい WebLogic Server インスタンスをクラスタに追加します。その際、アプリケーションを変更する必要はありません。クラスタは、単一のサーバでは提供できない、スケーラビリティと可用性という 2 つの大きなメリットをもたらします。
WebLogic Server クラスタは、アプリケーション開発者からは見えないように、J2EE アプリケーションにスケーラビリティと高可用性を提供します。スケーラビリティにより中間層の能力が拡張され、単一の WebLogic Server またはコンピュータの能力を超過することができます。クラスタ メンバシップの唯一の制限は、すべての WebLogic Server が IP マルチキャストで通信できなければならないということです。新しい WebLogic Server をクラスタに動的に追加して能力を増大させることもできます。
WebLogic Server クラスタは、複数サーバの冗長性を利用してクライアントを障害から保護することで高可用性を確保します。クラスタ内の複数のサーバで、同じサービスを提供できます。1 つのサーバで障害が発生しても、別のサーバが引き継ぎます。障害が発生したサーバから機能しているサーバへのフェイルオーバ機能によって、クライアントに対するアプリケーションの可用性が増大します。
警告 : すべてのアプリケーションおよび環境上のボトルネックが解決済みという条件下で初めて、新しいサーバへのクラスタの追加により、直線的なスケーラビリティが実現されます。ベンチマークまたは初期コンフィグレーション テストを実行するときには、単一サーバ環境における問題を洗い出した後で、クラスタ化環境に移行してください。
一般にクラスタのサーバ間の通信が必要である何らかの処理は可能性のある拡張性障害であります。以下の節では、直線的にスケール クラスタされた WebLogic server への機能に影響を与える問題に関する情報を提供します。
多くの場合、WebLogic server のクラスタはスケールに失敗する場合、データベースはネットワークであります。この場合は、他のオプションを理解してデータベースをチューニングするまたはデータベースのロードを削減することだけソリューションです。JDBC アプリケーションのチューニングを参照してください。
ユーザ セッション データは、J2EE アプリケーションの 2 つの標準方法で格納することができます。たとえば、ステートフル セッション EJB または HTTP セッション。 彼らだけで、これらはクラスタ拡張性にまれに影響を与えます。だたし、セッション レプリケーション メカニズムと結び付いている場合は、高可用性を提供し、ボトルネックを導入されます。 J2EE アプリケーションには、Web および EJB コンポーネントがあり、HTTP セッション管理は、ステートフル セッション EJB より 1 つ以上の レプリケーション オプションを提供するので、ユーザ セッション データをステートフル セッション EJBよりHTTP セッションに格納しなければなりません。 セッションの管理を参照してください。
これは、エンティティ EJB に適用されます。このエンティティ EJB は、読み込みが行われ、読み書き対応パタ－ンを使用して、OptimisticまたはReadOnly の同時方式を使用します。
Optimistic— Optimistic 同時実行性 Bean を更新する場合は、EJB コンテナがbeanのローカル コピーを無効化するために他のクラスタ メンバー にマルチキャスト メッセージが送信します。これをすると、他のサーバによって送出されたオプティミスティックな同時実行性例外が回避され、したがって、トランザクションを再試行する必要があります。EJB が頻繁に更新すると、互いのロカール キャッシュを無効化にするサーバが行った作業は深刻なボトルネックになります。
読み込みが行われ、読み書き対応パタ－ンによってReadOnly このパターンでは、単一の EJB で表される永続データは実際に2つの EJB で表されます。1つは、読み込み専用および 2 つは、 更新できる EJB です。更新できる bean の状況が変更する場合、コンテナが 対応する read-only EJB インスタンスを自動的に無効化します。EJB が頻繁に更新すると、読み込み専用を無効化するにはサーバが行った作業は深刻なボトルネックになります。
エンティティ EJB の無効化と同じ、 HTTP セッションは無効化である可能性があります。セカンダリ サーバに格納したセッションデータだけ無効化にする必要があるので、これは、エンティティ EJB 無効化の対象ほど高くありません。特別に必要な場合以外は、セッションを無効化にしないことをお勧めします。
一般にJNDI のバインド、アンバインド および リバインドは負荷の大きな処理であります。ただし、JNDI ツリー内の情報が変更することをクラスタのすべてのメンバーに伝播する必要があるので、これらの処理はクラスタ化された環境により大きなボトルネックになります。このような処理が頻繁に行うと、クラスタ スケーラビリティは大幅に削減できます。
マルチプロセッサ マシンを使用する場合は、使用可能な CPU の数とクラスタ化された WebLogic Server インスタンスの数との比率も考慮する必要があります。 WebLogic Server には、クラスタ内のサーバ インスタンス数に関する制限はありません。したがって、Sun Microsystems の Sun Enterprise 10000 などの大規模マルチプロセッサ サーバは、非常に大規模なクラスタまたは複数のクラスタのホストとなることができます。
CPU と WebLogic Server インスタンスの最適な比率を決定するには、まず、アプリケーションがネットワーク I/O またはディスク I/O ではなく完全に CPU にバインドされていることを確認する必要があります。 以下の手順で、CPU とサーバ インスタンスの最適な比率を決定します。
WebLogic Server ドメインの状態とパフォーマンスをモニタするためのツールは Administration Console です。Administration Console では、サーバ、HTTP、JTA サブシステム、JNDI、セキュリティ、CORBA 接続プール、EJB、JDBC、JMS といった WebLogic Server リソースのステータスと統計を表示できます。
詳細については、『WebLogic Server のコンフィグレーションと管理』の「WebLogic Server ドメインのモニタ」を参照してください。
たとえば、Administration Console の [サーバ｜モニタ｜パフォーマンス] タブには、現在のサーバ インスタンスの保留中のリクエストや処理済みのリクエストに関するパフォーマンス メトリックが表示されます。これには以下の情報が含まれています。
詳細については、Administration Console オンライン ヘルプの「[サーバ] --> [モニタ] --> [パフォーマンス]」を参照してください。
|
|
|