| ドキュメントのダウンロード | サイト マップ | Glossary | |
|
|||
| BEA ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Server > WebLogic Server パフォーマンス チューニング ガイド > WebLogic Server のチューニング |
|
WebLogic Server パフォーマンス チューニング ガイド
|
以下の節では、WebLogic Server をアプリケーションのニーズに合わせてチューニングする方法について説明します。
WebLogic Server のコンフィグレーション ファイル (config.xml) には、実際の環境やアプリケーションに合わせて細かくチューニングできるパフォーマンス関連の多くの要素があります。config.xml ファイル (管理サーバのホスト マシン上にある) は、MBean 属性値の永続ストレージを提供します。システム管理ツール (コマンドライン インタフェースまたは Administration Console) を使用して属性値を変更するたびに、その値は適切な管理 MBean に格納され、config.xml ファイルに書き込まれます。各 WebLogic Server ドメインには、それ専用の config.xml ファイルがあります。
WebLogic Server システム管理ツールの使い方の詳細については、『管理者ガイド』の「システム管理ツール」(を参照してください。
表 3-1 は、サーバのパフォーマンスに影響を与える config.xml ファイルの要素を示しています。
|
スレッド数の設定を参照。 |
||
|
「スタック」スレッドの検出を参照。 |
||
WebLogic Server パフォーマンス パックの使い方
ベンチマークは、WebLogic Server インスタンスのホスト マシンでネイティブ パフォーマンス パックを使用したときにパフォーマンスの大きな向上を示します。パフォーマンス パックは、プラットフォーム用に最適化されたネイティブのソケット マルチプレクサを使用してサーバのパフォーマンスを向上させます。ただし、ホスト マシンで pure-Java ソケット リーダー実装を使用しなければならない場合でも、サーバ インスタンスおよびクライアント マシンごとにソケット リーダー スレッドの数を適切にコンフィグレーションすることによって、ソケット通信のパフォーマンスを向上させることができます。
現時点でパフォーマンス パックを使用できる、サポート対象のプラットフォームを確認するには、次の手順に従います。
config.xml ファイルの Server 要素の NativeIOEnabled 属性を定義する必要があります。配布キットに付属のデフォルト config.xml ファイルでは、この属性はデフォルトで有効 (NativeIOEnabled=true) になっています。
Administration Console を使用してパフォーマンス パックが有効化されていることを確認するには、次の手順を行います。
config.xml ファイルの ExecuteQueue 要素の ThreadCount 属性の値は、実行キューを使用するアプリケーションで実行可能な同時処理の数と同じです。処理が WebLogic Server のインスタンスに入ると、その処理は実行キューに置かれます。次に、この処理は 1 つのスレッドに割り当てられて実行されます。スレッドはリソースを消費するため、この属性は注意して取り扱う必要があります。値を不必要に大きくすると、パフォーマンスが低下する可能性があります。
デフォルトでは、新しい WebLogic Server インスタンスは、「default」という名前のデフォルト実行キューにコンフィグレーションされています。この実行キューのスレッド数は 15 で、サーバ インスタンスで動作するすべてアプリケーションによって使用されます。また、WebLogic Server のインスタンスには、__weblogic_admin_html_queue と __weblogic_admin_rmi_queue という 2 つの組み込み実行キューがあります。ただし、これらのキューは、Administration Console との通信用に予約されています。追加の実行キューをコンフィグレーションしない場合、デフォルト キューは、すべての Web アプリケーションおよび RMI オブジェクトによって使用されます。
注意: ネイティブ パフォーマンス パックがプラットフォームで使用されていない場合は、パフォーマンスを最適化するために、実行キューのスレッドのデフォルト数とソケット リーダーとして機能するスレッドの割合をチューニングする必要があります。詳細については、ソケット リーダーとしてのスレッドの割り当てを参照してください。
デフォルト実行キューにスレッドを増やしたからといって、必ずしもより多くの作業を処理できるわけではありません。スレッドを増やした場合でも、依然としてプロセッサの処理能力による制約を受けます。スレッドはメモリを消費するので、ThreadCount 属性の値を不必要に大きくすると、パフォーマンスが低下する可能性があります。実行スレッドを大きくすると、メモリの使用量が大きくなり、コンテキストの切り替えが増加し、パフォーマンスが低下する可能性があります。
ThreadCount 属性の値は、アプリケーションが実行する処理のタイプによって大きく異なります。たとえば、使用しているクライアント アプリケーションが軽量で、その多くの処理をリモート呼び出しを介して行う場合、そのクライアント アプリケーションが接続に費やす時間は多くの処理をクライアントサイドで行うクライアント アプリケーションより長くなり、その結果としてスレッド数の値をより大きくしなければならなくなります。
デフォルトの 15 を超えるスレッドを使用する必要がない場合は、この属性の値を変更しないようにします。一般に、アプリケーションが応答に時間のかかるデータベース呼び出しを行う場合は、応答が早く時間のかからない呼び出しを行うアプリケーションより多くの実行スレッドが必要となります。後者のケースでは、実行スレッドの数を減らすとパフォーマンスが向上します。
実行キューの理想的なスレッド数を決めるには、キュー内のすべてのアプリケーションが最大負荷で動作しているときにキューのスループットをモニタします。キューのスレッド数を増やし、キューのスループットが最適になるまで負荷テストを繰り返します。あるポイントまでスレッドの数を増やしていくと、コンテキストの切り替えが増えすぎて、キューのスループットが低下し始めるので注意してください。
注意: WebLogic Server Administration Console には、サーバのすべての実行キューの累積スループットが表示されます。このスループット値を表示するには、デフォルト実行キューのスレッド数の変更の手順 1 〜 6 を行ってください。
表 3-2 に、WebLogic Server システムの CPU 数との関係で使用可能なスレッドを調整するためのデフォルトのシナリオを示します。これらのシナリオも、WebLogic Server が最大負荷で動作し、すべてのスレッド要求がデフォルト実行キューを使用して満たされることを前提としています。追加の実行キューをコンフィグレーションして、特定のキューにアプリケーションを割り当てる場合は、結果をプールごとにモニタします。
|
CPU と同じ数にスレッド数を減らしてから、確認された「スタック」スレッドの数だけ追加する。 たとえば、プロセッサが 4 つの場合は、スタック スレッドの数に加えて 4 つのスレッドを同時に実行できる。このため、実行スレッド数は、4 とスタック スレッド数を足した数が望ましい。 スタック スレッドの数を確認するには、「スタック」スレッドの検出を参照。 注意: 以上のことは、アプリケーションに大きく依存する。たとえば、アプリケーションがスレッドをブロックする時間によっては、上の公式が当てはまらない場合もある。 |
Administration Console でデフォルト実行キューのスレッド数を変更するには、次の手順を行います。
デフォルト実行キューをコンフィグレーションして、すべての WebLogic Server アプリケーションに対して最適な数のスレッドを提供することができます。また、複数の実行キューをコンフィグレーションすると、重要なアプリケーションをより詳細に制御することができます。複数の実行キューを使用することにより、WebLogic Server の負荷に関係なく、選択したアプリケーションが固定数の実行スレッドに確実にアクセスできるようになります。コンフィグレーションされた実行キューへのアプリケーションの割り当てに関する詳細については、実行キューによるスレッド使用の制御を参照してください。
ソケットの最適なパフォーマンスを実現するには、WebLogic Server インスタンスのホスト マシン上では、pure-Java 実装ではなくネイティブのソケット リーダー実装を使用することをお勧めします (WebLogic Server パフォーマンス パックの使い方を参照)。ただし、ホスト マシンで pure-Java ソケット リーダー実装を使用しなければならない場合でも、サーバ インスタンスおよびクライアント マシンごとにソケット リーダー スレッドとして機能する実行スレッドの数を適切にコンフィグレーションすることによって、ソケット通信のパフォーマンスを向上させることができます。
ThreadPoolPercentSocketReaders 属性は、ソケットからメッセージを読み込む実行スレッドの最高割合を設定します。この属性の最適値は、アプリケーションによって異なります。デフォルト値は 33、有効範囲は 1 〜 99 です。
実行スレッドをソケット リーダー スレッドとして割り当てると、サーバがクライアント要求を受け入れる速度と能力が向上します。重要なのは、ソケットからメッセージを読み込む実行スレッドの数と、サーバでタスクを実際に実行するスレッド数のバランスを取ることです。
WebLogic Server でのソケット リーダー スレッド数の設定
Administration Console を使用してソケットからメッセージを読み込む実行スレッドの最高割合を設定するには、次の手順を行います。
クライアント マシンでのソケット リーダー スレッド数の設定
クライアント マシン上では、クライアントを実行する Java 仮想マシン (JVM) 内でソケット リーダーの数をコンフィグレーションできます。java コマンドラインで -Dweblogic.ThreadPoolSize=value オプションおよび -Dweblogic.ThreadPoolPercentSocketReaders=value オプションを定義してクライアントのソケット リーダー数を指定します。
デフォルトの実行キューやユーザ定義の実行キューでオーバーフローになりそうな条件を検出し、必要に応じて対応するようにサーバをコンフィグレーションできます。WebLogic Server は、キューのサイズがユーザ定義の最大サイズにおけるパーセンテージに達した場合、キューにオーバーフロー条件の可能性があることを認識します。しきい値に達すると、サーバは自己の状態を「警告」に変更し、必要に応じて、キュー内の未処理の作業を追加のスレッドに割り当ててそのサイズを軽減します。
キューのオーバーフロー条件を自動的に検出したり、対処したりするには、以下の項目をコンフィグレーションします。
WebLogic Server Administration Console を使用して実行キューをチューニングするには、次の手順に従います。
WebLogic Server は、デフォルトの実行キューのスレッドが「スタック」状態になるとこれを自動的に検出します。 スタック スレッドは現在の作業を終了したり新しい作業を承認したりできないため、サーバはスタック スレッドを診断するたびに、メッセージのロギングを行います。実行キューのすべてのスレッドがスタック状態になった場合、サーバは実行キューに基づいて自己の状態を「警告」または「危険」に変更します。
WebLogic Server は、設定した期間、作業状態が継続した (アイドルでない) 場合、スレッドをスタック状態と診断します。サーバのスレッド検出動作は、スレッドがスタック状態と診断されるまでの時間や、サーバがスタック スレッドをチェックする頻度を変更することでチューニングできます。
注意: WebLogic Server がスレッドがスタック状態かどうかを判断するために使用する基準は変更できますが、デフォルト実行キューのすべてのスレッドがスタック状態になった場合に「警告」および「危険」状態を設定するデフォルト動作を変更することはできません。
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 の値と同じに設定するようにしてください。InitialCapacity の値が MaxCapacity の値より小さい場合は、負荷が増加すると、サーバで追加のデータベース接続を作成しなくてはならなくなります。サーバに負荷がかかると、できるだけ速く要求を完了するためにすべてのリソースが処理に費やされることになり、新しいデータベース接続を作成できなくなります。
JDBCConnectionPool 要素の MaxCapacity 属性を使用すると、接続プールが保持できる物理的なデータベース接続の最大数を設定できます。JDBC ドライバおよびデータベース サーバによっては、可能な物理的接続の数が制限されている場合もあります。
プロダクション システムでは、プール内の接続数を、JDBC 接続を必要とする並行クライアント セッションの数と同じにすることをお勧めします。プールのサイズは、サーバ内の実行スレッドの数とは無関係です。実行中のユーザ セッションが実行スレッドより多くなる場合もあります。
WebLogic Server 上で作成する各接続プールに対し、Prepared Statement キャッシュ サイズを指定できます。Prepared Statement のキャッシュ サイズを設定するとき、WebLogic Server は、指定した Prepared Statement 数に達するまでアプリケーションおよび EJB で使用される各 Prepared Statement を保存します。たとえば、Prepared Statement キャッシュ サイズを 10 に設定した場合、WebLogic Server はアプリケーションまたは EJB に呼び出される始めの 10 の Prepared Statement を保存します。
Prepared Statement キャッシュを使用することでパフォーマンスを大幅に向上させることができますが、制限があることも考慮に入れる必要があります。詳細については、『管理者ガイド』の「Prepared Statement キャッシュのパフォーマンスの向上」(を参照してください。
パフォーマンス関連の weblogic-ejb-jar.xml 要素の設定
weblogic-ejb-jar.xml デプロイメント ファイルには、EJB の同時実行、キャッシング、クラスタ化、および動作を定義する WebLogic Server 固有の EJB DTD が格納されます。このファイルには、利用可能な WebLogic Server リソースを EJB にマップする記述子も格納されます。WebLogic Server リソースには、セキュリティ ロール名、データ ソース (JDBC プールや JMS 接続ファクトリなど)、およびデプロイ済みの他の EJB があります。
weblogic-ejb-jar.xml デプロイメント ファイルの修正方法については、『WebLogic エンタープライズ JavaBeans プログラマーズ ガイド』の「EJB デプロイメント記述子の指定と編集」(を参照してください。
表 3-3 は、パフォーマンスに影響を与える weblogic-ejb-jar.xml ファイルの要素を示しています。
|
EJB プール サイズの設定を参照。 |
|
|
EJB キャッシュ サイズの設定を参照。 |
|
|
データベース ロックの委任を参照。 |
|
WebLogic Server では、すべてのステートレス セッション Bean クラスに対して EJB のフリー プールが保持されます。weblogic-ejb-jar.xml ファイルの max-beans-in-free-pool 要素は、このフリー プールのサイズを定義します。デフォルトでは、max-beans-in-free-pool は無制限です。フリー プール内の Bean の最大数はメモリによってのみ制限されます。
セッション Bean を頻繁に作成し、処理を迅速に行って Bean を解放する場合を除き、max-beans-in-free-pool パラメータの値は変更しないでください。変更する場合は、フリー プールを 25 〜 50% 拡張して、パフォーマンスが改善されるかどうかを確認します。オブジェクトの作成が負荷全体の中でわずかな割合しか占めない場合、このパラメータを大きくしてもパフォーマンスは大幅には改善されません。EJB がデータベースを頻繁に使用するアプリケーションの場合は、このパラメータの値を変更しないでください。
警告: このパラメータを大きくしすぎると、余計なメモリが消費されます。小さくしすぎると、不必要にオブジェクトが作成されます。このパラメータの変更について疑問がある場合は、値をそのままにしておいてください。
以降の節以外に、『WebLogic エンタープライズ JavaBeans プログラマーズ ガイド』の「max-beans-in-free-pool」を参照してください。
セッション Bean およびメッセージ Bean に対するプール サイズの割り当て
EJB が作成されると、セッション Bean インスタンスが作成され、ID が与えられます。クライアントが Bean を削除すると、その Bean インスタンスはフリー プールに置かれます。その後 Bean を作成する場合、フリー プールに置かれている直前のインスタンスを再利用することで、オブジェクトの割り当てを回避できます。max-beans-in-free-pool 要素を使用すると、EJB が頻繁に作成および削除される場合のパフォーマンスを向上させることができます。
メッセージの並行処理での必要に応じて、EJB コンテナではメッセージ Bean の新しいインスタンスが作成されます。max-beans-in-pool 要素によって、作成されるインスタンス数に対して絶対的な制限が設定されます。使用可能な実行時リソースに応じて、コンテナでこの設定値がオーバーライドされる場合もあります。
ステートレス セッション Bean およびメッセージ Bean の最高のパフォーマンスを引き出すには、max-beans-in-free-pool 要素のデフォルト値を使用します。デフォルト値を使用すると、できる限り多くのスレッドを使用して Bean を並行して実行できます。並行して実行される Bean の数を制限する場合を除き、この値を変更しないでください。
ファインダやホーム メソッドを呼び出す場合や、エンティティ Bean を作成する場合に使用される匿名エンティティ Bean (主キーの割り当てられていない Bean) のプールがあります。max-beans-in-free-pool 要素は、このプールのサイズも指定します。
数多くのファインダやホーム メソッドを実行している場合や、多くの Bean を作成している場合は、プール内で使用可能な Bean を確保できるよう、max-beans-in-free-pool 要素をチューニングすることもできます。
weblogic-ejb-jar.xml ファイルの initial-beans-in-free-pool 要素を使用すると、起動時のフリー プール内のステートレス セッション Bean インスタンスの数を指定できます。
initial-beans-in-free-pool の値を指定すると、WebLogic Server では、起動時に、指定した数の Bean インスタンスがフリー プールに生成されます。この方法で Bean インスタンスをフリー プールに格納しておくと、要求が来てから新しいインスタンスを生成せずに Bean に対する初期要求が可能になるため、EJB の初期応答時間が短縮されます。
initial-beans-in-free-pool が定義されていない場合のデフォルト値は 0 です。
initial-beans-in-free-pool 要素については、『WebLogic エンタープライズ JavaBeans プログラマーズ ガイド』(を参照してください。
WebLogic Server では、EJB キャッシュ (Bean が存在するインメモリ スペース) に存在するアクティブな Bean の数をコンフィグレーションできます。
weblogic-ejb-jar.xml ファイルの max-beans-in-cache 要素は、メモリに保持可能なこのクラスのオブジェクトの最大数を指定します。max-beans-in-cache の値に達すると、WebLogic Server では、最近クライアントに使用されていない EJB の一部に対してパッシベーションが行われます。また、max-beans-in-cache 要素の値は、EJB を WebLogic Server のキャッシュからいつ削除するかにも影響を与えます。
この要素の値は、ステートフル セッション Bean とエンティティ Bean の両方のキャッシュ サイズを設定します。
詳細については、『WebLogic エンタープライズ JavaBeans プログラマーズ ガイド』の「EJB の同時方式」(を参照してください。
『WebLogic エンタープライズ JavaBeans プログラマーズ ガイド』の「max-beans-in-cache」(を参照してください。
ステートフル セッション EJB のアクティベーションとパッシベーション
過度のパッシベーションとアクティベーションを回避するには、max-beans-in-cache 要素を使用してキャッシュを適切なサイズに設定します。アクティベーションとは、2 次ストレージからメモリに EJB インスタンスを転送することです。パッシベーションとは、メモリから 2 次ストレージに EJB インスタンスを転送することです。max-beans-in-cache の値を大きくしすぎると、メモリが不必要に消費されます。
EJB コンテナでは、ejbPassivate() メソッドを呼び出すことでパッシベーションが実行されます。EJB セッション オブジェクトが再び必要になると、ejbActivate() メソッドによって、そのオブジェクトが呼び出されます。ejbPassivate() メソッドが呼び出されると、EJB オブジェクトは Java シリアライゼーション API または類似のメソッドによってシリアライズされ、2 次メモリ (ディスク) に格納されます。ejbActivate() メソッドが呼び出されると、これとは反対の処理が実行されます。
コンテナは、クライアントまたはサーバの直接の関与を必要とせずに、EJB キャッシュ内の一連のセッション オブジェクトを自動的に管理します。各 EJB の特定のコールバック メソッドは、これらのオブジェクトのパッシベーション (キャッシュへの格納) またはアクティベーション (キャッシュからの取り出し) の方法を定義します。アクティベーションとパッシベーションの回数が多すぎると、EJB キャッシュ内に一連のセッション オブジェクトをキャッシュするというパフォーマンス上のメリットが消えてしまいます (特にアプリケーションで多くのセッション オブジェクトを処理する必要がある場合)。
WebLogic Server では、データベース ロックと排他的ロックのメカニズムがサポートされています。EJB 1.1 および EJB 2.0 でのデフォルトかつ推奨のロック メカニズムは、委任データベース ロックです。
データベース ロックによって、エンティティ EJB の同時アクセスの処理速度が向上します。WebLogic Server コンテナでは、ロック サービスを基盤となるデータベースに委ねることにより、同時アクセスの改善が行われます。委任データベース ロックの場合、排他的ロックとは異なり、基盤データ ストアはより高い粒度で EJB データをロックでき、ほとんどの場合では、さらにデッドロックの検出もできます。
weblogic-ejb-jar.xml ファイルの concurrency-strategy デプロイメント パラメータを設定することによって、EJB 用に使用するロック メカニズムを指定します。
データベース ロックの詳細については、『WebLogic エンタープライズ JavaBeans プログラマーズ ガイド』の「Database 同時方式」(を参照してください。
データへのアクセスは、トランザクションのアイソレーション レベル メカニズムを介して制御されます。トランザクション アイソレーション レベルは、マルチユーザ データベース システムにおいて、複数のインターリーブされるトランザクションが互いを干渉しないようにするレベルを決定します。トランザクションのアイソレーションは、トランザクション データの読み書きを管理するロック プロトコルによって実現されます。トランザクション データは、「シリアライゼーション」というプロセスでディスクに書き込まれます。アイソレーション レベルを低くすると、トランザクションのアイソレーションは低くなりますが、データベースの同時接続性を高めることができます。
詳細については、『WebLogic エンタープライズ JavaBeans プログラマーズ ガイド』にある、weblogic-ejb-jar.xml ファイルの solation-level 要素の説明を参照してください。
異なるアイソレーション レベルの関係と各アイソレーション レベルのサポートの詳細については、各データベースのマニュアルを参照してください。
WebLogic Server を起動するための Java パラメータの設定
Java パラメータの値は、WebLogic Server を起動するたびに指定する必要があります。weblogic.Server コマンドを使用してコマンドラインから行うと、この作業を単純化できます。ただし、コマンドラインから WebLogic Server を起動するために必要な引数は長くなる場合があり、エラーが発生しやすくなるので、コマンドをスクリプトに組み込むことをお勧めします。そのプロセスを単純化するため、WebLogic 配布キットに付属するサンプル スクリプトのデフォルト値を変更して WebLogic Server を起動することもできます。詳細については、「スクリプトを使用した管理サーバの起動」(を参照してください。
管理サーバを起動するためのスクリプトは、startWLS.sh (UNIX) と startWLS.cmd (Windows) です。これらのスクリプトは、WL_HOME¥server¥bin ディレクトリにあります (WL_HOME は WebLogic Server のインストール位置)。
それらのスクリプトのいくつかのデフォルト Java 値は、実際の環境やアプリケーションに合わせて修正する必要があります。これらのファイル内で重要なパフォーマンス チューニング パラメータは、JAVA_HOME パラメータと Java ヒープ サイズ パラメータです。
"%JAVA_HOME%¥bin¥java" -hotspot -Xms512m -Xmx512m -classpath %CLASSPATH% -
ヒープ サイズ オプションの設定の詳細については、ヒープ サイズ値の指定を参照してください。
JSP サーブレットをコンパイルするための標準 Java コンパイラは javac です。サーバの Java コンパイラを javac ではなく sj または jikes に設定することにより、パフォーマンスを大幅に向上させることができます。以降の節では、この手順とコンパイラに関するその他の考慮事項について説明します。
Administration Console でのコンパイラの変更
コンパイラを Administration Console で変更するには、次の手順を行います。
weblogic.xml ファイルでは、jsp-descriptor 要素を使用してサーブレット JSP のパラメータの名前と値を定義します。
サーバの Java コンパイラを weblogic.xml ファイルで設定する作業の詳細については、jsp-descriptor 要素を参照してください。
weblogic.ejbc ユーティリティを使用すると、EJB 2.0 および 1.1 のコンテナ クラスをコンパイルできます。EJB コンテナにデプロイするために .jar ファイルをコンパイルする場合は、weblogic.ejbc を使用して、コンテナ クラスを生成する必要があります。ejbc は、デフォルトでは javac コンパイラを使用します。パフォーマンスを向上させるには、-compiler フラグを使用して別のコンパイラ (Symantec の sj など) を指定します。
詳細については、「WebLogic Server EJB のユーティリティ」(を参照してください。
UNIX マシン上で JSP ファイルをコンパイルしているときに次のエラー メッセージが表示された場合、
failed: java.io.IOException: Not enough space
set rlim_fd_max = 4096
set rlim_fd_cur = 1024
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 インスタンスと使用可能な CPU の数との比率も考慮する必要があります。WebLogic Server には、クラスタ内のサーバ インスタンス数に関する制限はありません。したがって、Sun Microsystems の Sun Enterprise 10000 などの大規模マルチプロセッサ サーバは、非常に大規模なクラスタまたは複数のクラスタのホストとなることができます。
サーバと CPU の最適比率を決定する前に、以下の事項についてアプリケーションを徹底的にテストしてください。
つまり、CPU を増やす場合は、事前に Web アプリケーションがネットワーク I/O またはディスク I/O ではなく完全に CPU にバインドされていることを確認します。
CPU にバインドされたアプリケーションの場合、まず、すべての CPU につき 1 つの WebLogic Server インスタンスの比率でパフォーマンスをテストします。CPU 使用率がほぼ 100% を常に維持していれば、サーバに対する CPU の比率を高くします (たとえば、1 つの WebLogic Server インスタンスに 2 つの CPU を割り当てる)。プロダクション システムの場合、管理タスクを実行できるよう常に利用可能な CPU サイクルを予備として残しておく必要があることに注意してください。
Web アプリケーションの処理のニーズによって異なりますが、BEA では、WebLogic Server インスタンスと CPU の比率が 1 対 2 の場合に、一般的に最適の結果が得られることを確認しています。
WebLogic Server ドメインの状態とパフォーマンスをモニタするためのツールは Administration Console です。Administration Console では、サーバ、HTTP、JTA サブシステム、JNDI、セキュリティ、CORBA 接続プール、EJB、JDBC、JMS といった WebLogic Server リソースのステータスと統計を表示できます。
詳細については、「WebLogic Server ドメインのモニタ」を参照してください。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
