|
|
|
|
|
|
| | | |
WebLogic Server のチューニング
以下の節では、WebLogic Server をアプリケーションのニーズに合わせてチューニングする方法について説明します。
表 3-1 は、サーバのパフォーマンスに影響を与える config.xml ファイルの要素を示しています。
|
要素 |
属性 |
詳細情報の参照先 |
|---|---|---|
|
|
|
|
|
|
|
スレッド数の設定を参照。 |
|
|
|
|
|
|
|
|
|
|
|
WebLogic Server パフォーマンス パックの使い方
ベンチマークの結果、プラットフォームに対応したパフォーマンス パックを使用すると、WebLogic Server のパフォーマンスが大幅に向上することが実証されています。パフォーマンス パックは、プラットフォーム用に最適化された（ネイティブ）ソケット マルチプレクサを使用してサーバのパフォーマンスを向上させます。
パフォーマンス パックを使用するには、config.xml ファイルの Server 要素の NativeIOEnabled 属性を定義する必要があります。配布キットに付属のデフォルト config.xml ファイルでは、この属性はデフォルトで有効（NativeIOEnabled=true）になっています。
パフォーマンス パックを使用できるプラットフォーム
現時点でパフォーマンス パックを使用できるプラットフォームを確認するには、次の手順を行います。
Administration Console を使用してパフォーマンス パックが有効化されていることを確認するには、次の手順を行います。
myserver）を選択します。
config.xml ファイルの ExecuteQueue 要素の ThreadCount 属性の値は、実行キューを使用するアプリケーションで実行可能な同時処理の数と同じです。処理が WebLogic Server インスタンスに入ると、その処理は実行キューに置かれます。次に、この処理は 1 つのスレッドに割り当てられて実行されます。スレッドはリソースを消費するため、この属性は注意して取り扱う必要があります。値を不必要に大きくすると、パフォーマンスが低下する可能性があります。
デフォルトでは、新しい WebLogic Server インスタンスは、「default」という名前のデフォルト実行キューにコンフィグレーションされています。この実行キューのスレッド数は 15 です。また、WebLogic Server には、__weblogic_admin_html_queue と __weblogic_admin_rmi_queue という 2 つの組み込み実行キューがあります。ただし、これらのキューは、WebLogic Administration Console との通信用に予約されています。追加の実行キューをコンフィグレーションしない場合、デフォルト キューは、すべての Web アプリケーションおよび RMI オブジェクトによって使用されます。
注意: ほとんどのアプリケーションでは、デフォルト値を変更する必要はありません。
デフォルト実行キューにスレッドを増やしたからといって、必ずしもより多くの作業を処理できるわけではありません。スレッドを増やした場合でも、依然としてプロセッサの処理能力による制約を受けます。ThreadCount 属性の値を不必要に大きくすると、パフォーマンスが低下する可能性があります。また、スレッドはメモリを消費するため、実行スレッドを大きくすると、メモリの使用量が大きくなり、コンテキストの切り替えが増加し、パフォーマンスが低下する可能性があります。
ThreadCount 属性の値は、アプリケーションが実行する処理のタイプによって大きく異なります。たとえば、使用しているクライアント アプリケーションが軽量で、その多くの処理をリモート呼び出しを介して行う場合を考えます。そのクライアント アプリケーションが接続に費やす時間は、多くの処理をクライアントサイドで行うクライアント アプリケーションより長くなります。
処理に対してスレッドの追加が不要な場合は、この属性の値を変更しないようにします。クライアント アプリケーションでは、スレッドは保持されません。
アプリケーションが応答に時間のかかるデータベース呼び出しを行う場合、応答が早く時間のかからない呼び出しを行うアプリケーションより多くの実行スレッドが必要となります。後者の場合は、少ない実行スレッドを使用してパフォーマンスを向上させることができます。
表 3-2 に、デフォルト実行キューで使用可能なスレッドを調整するシナリオをいくつか示します。これらのシナリオでは、すべてのスレッド要求がデフォルト実行キューを使用して満たされていることを前提としています。追加の実行キューをコンフィグレーションして、特定のキューにアプリケーションを割り当てる場合は、結果をプールごとにモニタする必要があります。
スレッド数が少なすぎる場合、WebLogic Server が最大負荷で動作しているときに以下の症状が現れます。
WebLogic Server が最大負荷で動作しているときにスレッド数が多すぎる場合は、スレッド数を減らすにつれてパフォーマンスが向上します。
デフォルト実行キューをコンフィグレーションして、すべての WebLogic Server アプリケーションに対して最適な数のスレッドを提供することができます。また、複数の実行キューをコンフィグレーションすると、重要なアプリケーションをより詳細に制御することができます。複数の実行キューを使用することにより、WebLogic Server の負荷に関係なく、選択したアプリケーションが固定数の実行スレッドに確実にアクセスできるようになります。コンフィグレーションされた実行キューへのアプリケーションの割り当てに関する詳細については、 実行キューによるスレッド使用の制御を参照してください。
ソケットからメッセージを読み込む実行スレッドの最高割合を設定するには、config.xml ファイルの ThreadPoolPercentSocketReaders 属性を使用します。この属性の最適値は、アプリケーションによって異なります。デフォルト値は 33、有効範囲は 1 〜 99 です。
ThreadPoolPercentSocketReaders 属性は、ソケットからメッセージを読み込む実行スレッドの最高割合を設定します。実行スレッドをソケット リーダー スレッドとして割り当てると、サーバがクライアント要求を受け入れる速度と能力が向上します。重要なのは、ソケットからメッセージを読み込む実行スレッドの数と、サーバでタスクを実際に実行するスレッド数のバランスを取ることです。
ネイティブ パフォーマンス パックを使用していない場合は、実行スレッドをソケット リーダー スレッドとして割り当てる必要があります。可能な場合は、使用しているプラットフォーム用のパフォーマンス パックを使用します。 WebLogic Server パフォーマンス パックの使い方を参照してください。
接続プールによるパフォーマンスの向上
DBMS への JDBC 接続の確立には非常に時間がかかる場合があります。JDBC アプリケーションでデータベース接続のオープンとクローズを繰り返す必要がある場合、これは重大なパフォーマンスの問題となります。WebLogic 接続プールは、こうした問題を効率的に解決します。
WebLogic Server を起動すると、接続プール内の接続が開き、すべてのクライアントが使用できるようになります。クライアントが接続プールの接続をクローズすると、その接続はプールに戻され、他のクライアントが使用できる状態になります。つまり、接続そのものはクローズされません。プール接続のオープンとクローズには、ほとんど負荷がかかりません。
どのくらいの数の接続をプールに作成すればよいでしょうか。接続プールの数は、コンフィグレーションされたパラメータに従って最大数と最小数の間で増減させることができます。最高のパフォーマンスが得られるのは、同時ユーザと同じくらいの数の接続が接続プールに存在する場合です。
JDBCConnectionPool 要素の InitialCapacity 属性を使用すると、プールのコンフィグレーション時に作成する物理的なデータベース接続の数を設定できます。ここで指定した数の接続をサーバで作成できない場合、この接続プールの作成は失敗します。
JDBC 接続プールの初期サイズのチューニングを参照してください。
JDBCConnectionPool 要素の MaxCapacity 属性を使用すると、接続プールの物理的なデータベース接続の最大数を設定できます。
JDBC 接続プールの最大サイズのチューニングを参照してください。
JDBC チューニングの詳細については、『WebLogic JDBC プログラミング ガイド』の「JDBC アプリケーションのパフォーマンス チューニング」を参照してください。
JDBC 接続プールの初期サイズのチューニング
開発時は、InitialCapacity 属性の値を小さく設定すると便利です。これにより、サーバの起動が速くなります。
プロダクション システムでは、サーバの起動時にすべてのデータベース接続を取得できるよう、InitialCapacity の値は MaxCapacity の値と同じに設定するようにしてください。
InitialCapacity の値が MaxCapacity の値より小さい場合は、負荷が増加すると、サーバで追加のデータベース接続を作成しなくてはならなくなります。サーバに負荷がかかると、できるだけ速く要求を完了するためにすべてのリソースが処理に費やされることになり、新しいデータベース接続を作成できなくなります。
JDBC 接続プールの最大サイズのチューニング
JDBCConnectionPool 要素の MaxCapacity 属性を使用すると、接続プールが保持できる物理的なデータベース接続の最大数を設定できます。JDBC ドライバおよびデータベース サーバによっては、可能な物理的接続の数が制限されている場合もあります。
プロダクション システムでは、プール内の接続数を、JDBC 接続を必要とする並行クライアント セッションの数と同じにすることをお勧めします。プールのサイズは、サーバ内の実行スレッドの数とは無関係です。実行中のユーザ セッションが実行スレッドより多くなる場合もあります。
config.xml ファイルの Server 要素の AcceptBacklog 属性を使用すると、サーバが受け入れる接続要求の数を設定できます（これ以上の要求は拒否されます）。AcceptBacklog 属性は、待機キューに格納できる TCP 接続の数を指定します。この固定サイズのキューには、TCP スタックでは受信されたが、アプリケーションにはまだ受け入れられていない接続要求が格納されます。デフォルト値は 50 で、最大値はオペレーティング システムによって異なります。
Administration Console で、[サーバ｜コンフィグレーション｜チューニング] を選択し、[バックログを受け入れ] 属性の値を入力します。
処理中に、クライアントで多くの接続が削除または拒否され、サーバに他のエラー メッセージが存在しない場合は、AcceptBacklog 属性の値が小さすぎる可能性があります。
WebLogic Server にアクセスしようとしたときに「connection refused（接続が拒否されました）」というメッセージを受け取った場合は、AcceptBacklog 属性の値をデフォルトから 25% 大きくします。メッセージが表示されなくなるまで、この属性の値を 25% ずつ大きくしていきます。
weblogic-ejb-jar.xml ファイルの要素のチューニング
表 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 に対するプール サイズの割り当て
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 要素をチューニングすることもできます。
プール サイズのチューニング
セッション Bean を頻繁に作成し、処理を迅速に行って Bean を解放する場合を除き、max-beans-in-free-pool パラメータの値は変更しないでください。変更する場合は、フリー プールを 25 〜 50% 拡張して、パフォーマンスが改善されるかどうかを確認します。オブジェクトの作成が負荷全体の中でわずかな割合しか占めない場合、このパラメータを大きくしてもパフォーマンスは大幅には改善されません。EJB がデータベースを頻繁に使用するアプリケーションの場合は、このパラメータの値を変更しないでください。
警告: このパラメータを大きくしすぎると、余計なメモリが消費されます。小さくしすぎると、不必要にオブジェクトが作成されます。このパラメータの変更について疑問がある場合は、値をそのままにしておいてください。
weblogic-ejb-jar.xml ファイルの initial-beans-in-free-pool 要素を使用すると、起動時のフリー プール内のステートレス セッション Bean インスタンスの数を指定できます。
initial-bean-in-free-pool の値を指定すると、WebLogic Server では、起動時に、指定した数の Bean インスタンスがフリー プールに生成されます。この方法で Bean インスタンスをフリー プールに格納しておくと、要求が来てから新しいインスタンスを生成せずに Bean に対する初期要求が可能になるため、EJB の初期応答時間が短縮されます。
initial-bean-in-free-pool が定義されていない場合のデフォルト値は 0 です。
『WebLogic エンタープライズ JavaBeans プログラマーズ ガイド』にある、initial-beans-in-free-pool 要素の説明を参照してください。
WebLogic Server では、EJB キャッシュ（Bean が存在するインメモリ スペース）に存在するアクティブな Bean の数をコンフィグレーションできます。
weblogic-ejb-jar.xml ファイルの max-beans-in-cache 要素は、メモリに保持可能なこのクラスのオブジェクトの最大数を指定します。max-bean-in-cache の値に達すると、WebLogic Server では、最近クライアントに使用されていない EJB の一部に対してパッシベーションが行われます。また、max-beans-in-cache 要素の値は、EJB を WebLogic Server のキャッシュからいつ削除するかにも影響を与えます。
この要素を使用すれば、ステートフル セッション Bean とエンティティ Bean のキャッシュ サイズを同じように設定できます。
詳細については、「エンティティ 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 の同時アクセスの改善が行われます。排他的ロックとは異なり、基盤データ ストアはより高い粒度で EJB データをロックでき、ほとんどの場合では、さらにデッドロックの検出もできます。
データベース ロックの詳細については、「エンティティ EJB のロック サービス」を参照してください。
weblogic-ejb-jar.xml の concurrency-strategy デプロイメント パラメータを設定することによって、EJB 用に使用するロック メカニズムを指定します。http://edocs.beasys.co.jp/e-docs/wls61/ejb/reference.html#concurrency_strategy_60 を参照してください。
トランザクションのアイソレーション レベルの設定
データへのアクセスは、トランザクションのアイソレーション レベル メカニズムを介して制御されます。トランザクション アイソレーション レベルは、マルチユーザ データベース システムにおいて、複数のインターリーブされるトランザクションが互いを干渉しないようにするレベルを決定します。トランザクションのアイソレーションは、トランザクション データの読み書きを管理するロック プロトコルによって実現されます。トランザクション データは、「シリアライゼーション」というプロセスでディスクに書き込まれます。アイソレーション レベルを低くすると、トランザクションのアイソレーションは低くなりますが、データベースの同時接続性を高めることができます。
詳細については、『WebLogic エンタープライズ JavaBeans プログラマーズ ガイド』にある、weblogic-ejb-jar.xml ファイルの isolation-level 要素の説明を参照してください。
異なるアイソレーション レベルの関係と各アイソレーション レベルのサポートの詳細については、各データベースのマニュアルを参照してください。
WebLogic Server 起動用パラメータのチューニング
WebLogic 配布キットには、WebLogic Server の起動に使用できるサンプル スクリプトが付属しています（「WebLogic Server の起動と停止」を参照）。
それらのスクリプトは、実際の環境やアプリケーションに合わせて修正する必要があります。管理サーバの起動用と管理対象サーバの起動用に、別々のサンプル スクリプトが用意されています。管理サーバを起動するためのスクリプトは、startWebLogic.sh（UNIX）と startWeblogic.cmd（Windows）です。これらのスクリプトは、ドメインのコンフィグレーション サブディレクトリに配置されています。
これらのファイル内で重要なパフォーマンス チューニング パラメータは、JAVA_HOME パラメータと Java ヒープ サイズ パラメータです。
JAVA_HOME の値を JDK の位置に変更します。次に例を示します。
set JAVA_HOME=C:\bea\jdk131
"%JAVA_HOME%\bin\java" -hotspot -ms512m -mx512m -classpath %CLASSPATH% -
ヒープ サイズ オプションの設定の詳細については、 ヒープ サイズ値の指定を参照してください。
JSP サーブレットをコンパイルするための標準 Java コンパイラは javac です。サーバの Java コンパイラを javac ではなく sj または jikes に設定することにより、パフォーマンスを大幅に向上させることができます。以降の節では、この手順とコンパイラに関するその他の考慮事項について説明します。
Administration Console でのコンパイラの変更
コンパイラを Administration Console で変更するには、次の手順を行います。
myserver）を選択します。
c:\visualcafe31\bin\sj.exe
weblogic_home\jdk131\jre\lib\rt.jar
weblogic.xml でのコンパイラの設定
weblogic.xml ファイルでは、jsp-descriptor 要素を使用してサーブレット JSP のパラメータの名前と値を定義します。
compileCommand パラメータでは、生成される JSP サーブレットをコンパイルするための Java コンパイラを指定します。
precompile パラメータを使用すると、WebLogic Server の起動時に WebLogic Server で JSP をあらかじめコンパイルするようコンフィグレーションできます。
サーバの Java コンパイラを weblogic.xml ファイルで設定する作業の詳細については、 jsp-descriptor 要素を参照してください。
EJB コンテナ クラスのコンパイル
WebLogic Server には、EJB 2.0 および 1.1 のコンテナ クラスをコンパイルするための weblogic.ejbc ユーティリティが付属しています。EJB コンテナにデプロイするために .jar ファイルをコンパイルする場合は、weblogic.ejbc を使用して、コンテナ クラスを生成する必要があります。ejbc は、デフォルトでは javac をコンパイラとして使用します。パフォーマンスを向上させるには、-compiler フラグを使用して別のコンパイラ（Symantec の sj など）を指定します。
詳細については、「WebLogic Server EJB のユーティリティ」を参照してください。
UNIX でのコンパイル
UNIX マシンでJSP ファイルをコンパイルしている際に、以下のようなエラー メッセージを受信することがあります。
failed: java.io.IOException: Not enough space
その場合には、次の解決策のいずれか、またはすべてを試みてください。
set rlim_fd_max = 4096
set rlim_fd_cur = 1024
-native フラグを使って、JVM の起動時にネイティブ スレッドを使用します。
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 Clusters ユーザーズ ガイド』を参照してください。
警告: すべてのアプリケーションおよび環境上のボトルネックを解決した場合、新しいサーバをクラスタに追加すると、直線的なスケーラビリティが実現されます。ベンチマークまたは初期コンフィグレーション テストを実行するときには、単一サーバ環境における問題を分離してから、クラスタ化環境に移行してください。
マルチプロセッサ マシンを使用する場合、クラスタ化された WebLogic Server インスタンスと使用可能な CPU の数との比率も考慮する必要があります。WebLogic Server には、クラスタ内のサーバ インスタンス数に関する制限はありません。したがって、Sun Microsystems, Inc. の 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 ドメインのモニタ」を参照してください。
|
|
|