| Oracle® Fusion Middleware Oracle WebLogic Server サーバ環境のコンフィグレーション 11g リリース 1 (10.3.1) B55510-01 |
|
 戻る |
 次へ |
| Oracle® Fusion Middleware Oracle WebLogic Server サーバ環境のコンフィグレーション 11g リリース 1 (10.3.1) B55510-01 |
|
戻る |
次へ |
WebLogic Server では、アプリケーションがどのような優先順位で作業を実行するかをコンフィグレーションできます。ユーザが定義したルールと実際の実行時パフォーマンスのモニタ結果に基づいて、アプリケーションのパフォーマンスが最適化され、サービス レベル アグリーメントが維持されます。アプリケーションに適用するルールや制約を定義するには、ワーク マネージャを定義し、これを WebLogic Server ドメインにグローバルに適用するか、特定のアプリケーション コンポーネントに適用します。
以前のバージョンの WebLogic Server では、複数の実行キューで処理を実行していました。クラスの異なる作業を優先順位や順序の要件に基づいて別々のキューで実行することで、デッドロックを回避していました。デフォルトの実行キュー (weblogic.kernel.default) に加え、内部管理トラフィック専用にあらかじめコンフィグレーションされたキュー (weblogic.admin.HTTP、weblogic.admin.RMI など) がありました。
ユーザは、デフォルト キューのスレッドの数を変更することでスレッドの使用状況を制御したり、特定のアプリケーションが全体のシステム負荷に関係なく一定数のスレッドにアクセスできるようカスタム実行キューをコンフィグレーションしたりできました。
このバージョンの WebLogic Server では、1 つのスレッド プールですべてのタイプの作業を実行するようになりました。作業の優先順位は、ユーザが定義するルールと実行時のメトリックに基づいて決定されます。メトリックとしては、実際に要求を実行するのにかかった時間、要求をプールに出し入れする割合、などがあります。
共通スレッド プールのサイズは、スループットが最大になるように自動的に変更されます。キューは、スループットを長期間にわたってモニタし、その履歴に基づいてスレッド数を調整するかどうかを決定します。たとえば、スループットの統計値の履歴に基づき、スレッド数を増やすことでスループットが向上すると判断されると、スレッド数が自動的に増やされます。同様に、統計値に基づいてスレッドを減らしてもスループットが悪化しないと判断されると、スレッド数が自動的に減らされます。この新しい方式により、管理者は、カスタムの実行キューをコンフィグレーション、モニタ、チューニングする際の手間や複雑さを避けて、より簡単に処理リソースを割り当てたり、パフォーマンスを管理したりできるようになりました。
WebLogic Server では、管理者が定義したパラメータと実行時の実際のパフォーマンスおよびスループットを考慮にいれた実行モデルに基づいて、作業の優先順位が決定されてスレッドが割り当てられます。
管理者は、一連のスケジューリング ガイドラインをコンフィグレーションし、それらを 1 つまたは複数のアプリケーションに関連付けたり、特定のアプリケーション コンポーネントに関連付けたりできます。たとえば、スケジューリング ガイドラインのセットを 1 つのアプリケーションに関連付け、別のガイドラインのセットを別のアプリケーションに関連付けることができます。実行時には、これらのガイドラインに基づいて、保留中の作業やキューに入っている要求が実行スレッドに割り当てられます。
アプリケーション内の作業を管理するには、以下のうち 1 つまたは複数のワーク マネージャ コンポーネントを定義します。
フェア シェア要求クラス
応答時間要求クラス
最小スレッド数制約
最大スレッド数制約
容量制約
コンテキスト要求クラス
これらのコンポーネントの詳細については、「要求クラス」または「制約」を参照してください。
これらのワーク マネージャ コンポーネントを使用してアプリケーションのパフォーマンスを制御するには、アプリケーションのデプロイメント記述子でコンポーネントの名前を参照します。また、これらすべてのコンポーネント (コンテキスト要求クラスを除く。「コンテキスト要求クラス」を参照) をカプセル化したワーク マネージャを定義し、このワーク マネージャの名前をアプリケーションのデプロイメント記述子で参照することもできます。複数のワーク マネージャを定義することも可能です。ワーク マネージャの適正数は、WebLogic Server でホストするアプリケーション全体でいくつの個別要求プロファイルが存在するかによって異なります。
ワーク マネージャは、次のいずれかのコンフィグレーション ファイルまたは WebLogic Administration Console を使用して、ドメイン レベル、アプリケーション レベル、およびモジュール レベルでコンフィグレーションできます。
config.xml - config.xml で指定したワーク マネージャは、ドメイン内のアプリケーションまたはアプリケーション コンポーネントに関連付けることができる。
weblogic-application.xml - アプリケーション レベルで指定したワーク マネージャは、そのアプリケーション、またはそのアプリケーションのコンポーネントに関連付けることができる。
weblogic-ejb-jar.xml または weblogic.xml - コンポーネント レベルで指定したワーク マネージャは、そのコンポーネントに関連付けることができる。
weblogic.xml - Web アプリケーション用のワーク マネージャを指定できる。
コード リスト 2-1 に、ワーク マネージャの定義の例を示します。
コード リスト 2-1 ワーク マネージャ スタンザ
<work-manager> <name>highpriority_workmanager</name> <fair-share-request-class> <name>high_priority</name> <fair-share>100</fair-share> </fair-share-request-class> <min-threads-constraint> <name>MinThreadsCountFive</name> <count>5</count> </min-threads-constraint> </work-manager>
コード リスト 2-1 のワーク マネージャを Web アプリケーションのディスパッチ ポリシーで参照するには、コード リスト 2-2 のコードを Web アプリケーションの web.xml ファイルに追加します。
コード リスト 2-2 Web アプリケーションでのワーク マネージャの参照
<init-param> <param-name>wl-dispatch-policy</param-name> <param-value>highpriority_workmanager</param-value> </init-param>
ワーク マネージャで定義および使用できるコンポーネントについては、以降の節で説明します。
要求クラスは、要求へのスレッドの割り当てに使用するスケジューリング ガイドラインを表現します。要求クラスを使用すると、優先順位の高い作業が優先順位の低い作業より後に送信された場合でも、優先順位の高い作業を優先順位の低い作業より前にスケジューリングすることができます。WebLogic Server では、各モジュールが要求を完了するのにかかる時間が考慮されます。
要求クラスにはいくつかのタイプがあり、それぞれ条件の異なったスケジューリング ガイドラインを表現します。1 つのワーク マネージャに、要求クラスを 1 つだけ指定することもできます。
fair-share-request-class - 要求の処理に必要な平均スレッド使用時間を指定する。
たとえば、WebLogic Server で 2 つのモジュールを実行しているとします。ModuleA のワーク マネージャでは fair-share-request-class が 80 に設定されており、ModuleB のワーク マネージャでは fair-share-request-class が 20 に設定されています。
各モジュールで切れ目なく要求を処理している状態 (つまり、要求数がスレッドの数を超えている状態) が続く間は、スレッド使用時間の 80% が ModuleA に、20% が ModuleB に割り当てられます。
|
注意 : フェアシェア要求クラスの値は、割合ではなく相対値で指定します。したがって、上の例で要求クラスを 400 と 100 に設定しても相対値としては同じです。 |
response-time-request-class - 応答時間の目標値をミリ秒単位で指定する。応答時間の目標値は、個々の要求には適用されません。代わりに、そのクラスの要求の許容可能な待機時間を、観察された平均スレッド使用時間から減算することで算出し、そのクラスの要求の平均的な待機が許容可能な待機時間に比例するように要求をスケジューリングします。
たとえば、前の例のように ModuleA と ModuleB があり、応答時間の目標値がそれぞれ 2000 ミリ秒と 5000 ミリ秒に設定されており、個々の要求の実際のスレッド使用時間が応答時間の目標値よりも短いとします。応答と要求の間に「思考時間」による遅延がないとすると、各モジュールで切れ目なく要求を処理している状態 (つまり、要求数がスレッドの数を超えている状態) が続く間は、ModuleA と ModuleB に対する要求は平均応答時間が 2 対 5 の割合になるようにスケジューリングされます。ModuleA と ModuleB の実際の平均応答時間は応答時間の目標値より長くなったり短くなったりしますが、設定されている目標値の常分数または倍数になります。たとえば、ModuleA の要求の平均応答時間が 1,000 ミリ秒である場合、ModuleB の要求の平均応答時間は 2,500 ミリ秒になります。
context-request-class - コンテキスト情報 (現在のユーザ、現在のユーザのグループなど) に基づいて要求クラスを要求に割り当てる。
たとえば、コード リスト 2-3 の context-request-class では、要求の subject および role プロパティの値に基づいて要求クラスが要求に割り当てられます。
コンテキスト要求クラスを使用すると、アプリケーションのデプロイメント記述子で、ユーザのコンテキストに基づいて要求クラスを定義できます。次に例を示します。
コード リスト 2-3 コンテキスト要求クラス
<work-manager> <name>responsetime_workmanager</name> <response-time-request-class> <name>my_response_time</name> <goal-ms>2000</goal-ms> </response-time-request-class> </work-manager> <work-manager> <name>context_workmanager</name> <context-request-class> <name>test_context</name> <context-case> <user-name>system</user-name> <request-class-name>high_fairshare</request-class-name> </context-case> <context-case> <group-name>everyone</group-name> <request-class-name>low_fairshare</request-class-name> </context-case> </context-request-class> </work-manager>
|
注意 : Web アプリケーションのワーク マネージャがコンテキスト要求クラスを参照している場合、最初のユーザ呼び出しはデフォルトの要求クラスを通じて実行され、同じセッションの以降の呼び出しはユーザ定義の要求クラスを通じて実行されます。 |
制約を使用すると、要求を実行するために割り当てられるスレッドの最小数と最大数、および WebLogic Server が要求を拒否し始めるまでにキューに入れたり実行したりできる要求の総数を定義できます。
以下のタイプの制約を定義できます。
max-threads-constraint - 制約対象の作業セットからの要求を実行する同時スレッドの数を制限する。デフォルトは無制限です。たとえば、最大スレッド数が 10 に定義された制約を 3 つのエントリ ポイントで共有するとします。このスケジューリング ロジックでは、統合された 3 つのエントリ ポイントからの要求を 10 個以下のスレッドで実行します。
max-threads-constraint は、要求が依存するリソース (たとえば接続プール) の可用性の観点から定義できます。
max-threads-constraint は、要求クラスによるスレッドのフェア シェアの実現や応答時間の目標値の達成を妨げることがあります。いったん制約条件が満たされると、同時実行の数が制限値を下回るまで、このタイプの要求はスケジューリングされません。制限値を下回ると、フェア シェアまたは応答時間の目標値に基づいて作業がスケジューリングされます。
min-threads-constraint - 制約対象の要求に割り当てられるスレッドの数を保証することでデッドロックを回避する。デフォルトはゼロです。min-threads-constraint の値を 1 に設定すると、ピアから同期的に呼び出されるレプリケーション更新要求などの場合に便利です。
min-threads-constraint によってフェア シェアが向上するとは限りません。このタイプの制約は、主にサーバ インスタンスがデッドロック状態に近づいたときに効果を発揮します。このような場合は、最近サービス クラス内の要求がフェア シェアを超えていた場合でも、この制約によって要求がスケジューリングされます。
capacity - サーバは容量に達したときにのみ要求を拒否する。デフォルトは -1 です。容量には、制約対象の作業セットからの全要求 (キューにある要求と実行中の要求) が含まれる。個々の容量しきい値を超えた場合、またはグローバル容量を超えた場合に作業が拒否されます。この制約は、グローバル キューのしきい値とは無関係。
スタック スレッドに応じて、スタック スレッド ワーク マネージャ コンポーネントを定義できます。このコンポーネントを使用すると、ワーク マネージャを停止したり、アプリケーションを管理モードにしたり、サーバ インスタンスを障害が発生したものとしてマークしたりできます。
たとえば、コード リスト 2-4 で定義するワーク マネージャは、2 つのスレッドが 30 秒を超えてスタックすると停止します。
基本的に、ワーク マネージャには 3 つのタイプがあります。各タイプは、スコープおよび定義と使用のされ方によって特徴付けられます。
スレッド管理を処理し、自動チューニングを実行するため、WebLogic Server ではデフォルトのワーク マネージャが実装されています。このワーク マネージャは、アプリケーションのデプロイメント記述子で他のワーク マネージャが指定されていない場合に、アプリケーションによって使用されます。
多くの状況下において、デフォルトのワーク マネージャはほとんどのアプリケーション要件を十分に満たしていると考えられます。WebLogic Server のスレッド処理アルゴリズムは、デフォルトで各アプリケーションに、そのアプリケーション自身のフェア シェアを割り当てます。各アプリケーションは、スレッドに対して同等の優先順位を与えられており、スレッドを独占することはできないようになっています。
デフォルトのワーク マネージャの動作をオーバーライドするには、default というグローバル ワーク マネージャを作成およびコンフィグレーションします。これにより、WebLogic Server のデフォルトのスレッド処理動作を制御できます。
|
注意 : デフォルトのワーク マネージャをオーバーライドすると、すべてのインスタンスがオーバーライドされます。 |
サーバにデプロイされているすべてのアプリケーションおよびモジュールで使用できるグローバル ワーク マネージャを、WebLogic Administration Console または config.xml で作成することができます。
アプリケーションは、グローバルに定義されたワーク マネージャをテンプレートとして使用します。各アプリケーションは、そのアプリケーションと関連付けられた作業を処理する、自身のインスタンスを作成し、その作業を他のアプリケーションから分離します。そうすることで、同じディスパッチ ポリシーを使用している 2 つのアプリケーションに向かうトラフィックを処理できます。各アプリケーションの作業を別個に処理することで、別のアプリケーションのスレッド管理に影響を及ぼすことなく、アプリケーションを停止できます。各アプリケーションには、専用のワーク マネージャ インスタンスが実装されていますが、基底となるコンポーネントは共有されます。
グローバル スコープのワーク マネージャに加えて、特定のアプリケーションまたはモジュールのみで使用できるワーク マネージャを作成することもできます。アプリケーション スコープのワーク マネージャは、WebLogic Administration Console と以下の記述子で定義できます。
weblogic-application.xml
weblogic-ejb-jar.xml
weblogic.xml
ワーク マネージャが明示的に割り当てられていないアプリケーションでは、デフォルトのワーク マネージャが使用されます。
ワーク マネージャにメソッドを割り当てるには、デプロイメント記述子で <dispatch-policy> 要素を使用します。下位互換性を維持するため、<dispatch-policy> でカスタム実行キューも指定できるようになっています。例については、コード リスト 2-2 を参照してください。
ワーク マネージャ、要求クラス、および制約では、以下が必要になります。
定義。ワーク マネージャ、要求クラス、および制約は、Administration Console を使用してドメインのコンフィグレーション内にグローバルに定義するか (Administration Console の [環境｜ワーク マネージャ])、上に挙げたデプロイメント記述子のいずれかを使用して定義します。どちらの場合も、それぞれに名前を割り当てます。
マッピング。デプロイメント記述子で、ワーク マネージャ、要求クラス、または制約のいずれかを、その名前を使用して参照します。
weblogic-ejb-jar.xml - weblogic-enterprise-bean の既存の dispatch-policy タグの値は、名前付きの dispatch-policy にできます。下位互換性のため、ExecuteQueue を指定することもできます。また、現在の isolation-level タグのように、dispatch-policy、max-threads、または min-threads を使用して、メソッドのリストに名前付きの (または制約が数値で名前がない) ポリシーおよび制約を指定することも可能です。
この節では、さまざまなデプロイメント記述子を使用したワーク マネージャの定義例を示します。
必要に応じて、各デプロイメント記述子のスキーマも参照してください。
weblogic-ejb-jar.xml schema-http://xmlns.oracle.com/weblogic/weblogic-ejb-jar/1.0/weblogic-ejb-jar.xsd
weblogic-application.xml schema-http://xmlns.oracle.com/weblogic/weblogic-application/1.0/weblogic-application.xsd
weblogic.xml スキーマ - 『Oracle Fusion Middleware Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「weblogic.xml デプロイメント記述子の要素」を参照してください。
コード リスト 2-5 ワーク マネージャのエントリを含む weblogic-ejb-jar.xml
<weblogic-ejb-jar xmlns="http://xmlns.oracle.com/weblogic/weblogic-ejb-jar" xmlns:j2ee="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-ejb-jar http://xmlns.oracle.com/weblogic/weblogic-ejb-jar/1.0/weblogic-ejb-jar.xsd"> <weblogic-enterprise-bean> <ejb-name>WorkEJB</ejb-name> <jndi-name>core_work_ejb_workbean_WorkEJB</jndi-name> <dispatch-policy>weblogic.kernel.System</dispatch-policy> </weblogic-enterprise-bean> <weblogic-enterprise-bean> <ejb-name>NonSystemWorkEJB</ejb-name> <jndi-name>core_work_ejb_workbean_NonSystemWorkEJB</jndi-name> <dispatch-policy>workbean_workmanager</dispatch-policy> </weblogic-enterprise-bean> <weblogic-enterprise-bean> <ejb-name>MinThreadsWorkEJB</ejb-name> <jndi-name>core_work_ejb_workbean_MinThreadsWorkEJB</jndi-name> <dispatch-policy>MinThreadsCountFive</dispatch-policy> </weblogic-enterprise-bean> <work-manager> <name>workbean_workmanager</name> </work-manager> <work-manager> <name>stuckthread_workmanager</name> <work-manager-shutdown-trigger> <max-stuck-thread-time>30</max-stuck-thread-time> <stuck-thread-count>2</stuck-thread-count> </work-manager-shutdown-trigger> </work-manager> <work-manager> <name>minthreads_workmanager</name> <min-threads-constraint> <name>MinThreadsCountFive</name> <count>5</count> </min-threads-constraint> </work-manager> <work-manager> <name>lowpriority_workmanager</name> <fair-share-request-class> <name>low_priority</name> <fair-share>10</fair-share> </fair-share-request-class> </work-manager> <work-manager> <name>highpriority_workmanager</name> <fair-share-request-class> <name>high_priority</name> <fair-share>100</fair-share> </fair-share-request-class> </work-manager> <work-manager> <name>veryhighpriority_workmanager</name> <fair-share-request-class> <name>veryhigh_priority</name> <fair-share>1000</fair-share> </fair-share-request-class> </work-manager>
これらの EJB は、依存するリソース (接続プールおよびアプリケーション スコープの接続プール) のインスタンスが存在する限り、なるべく多くのスレッドを取得するようにコンフィグレーションされています。
コード リスト 2-6 接続プール ベースの最大スレッド数制約を含む weblogic-ejb-jar.xml
<weblogic-ejb-jar xmlns="http://xmlns.oracle.com/weblogic/weblogic-ejb-jar" xmlns:j2ee="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-ejb-jar http://xmlns.oracle.com/weblogic/weblogic-ejb-jar/1.0/weblogic-ejb-jar.xsd"> <weblogic-enterprise-bean> <ejb-name>ResourceConstraintEJB</ejb-name> <jndi-name>core_work_ejb_resource_ResourceConstraintEJB</jndi-name> <dispatch-policy>test_resource</dispatch-policy> </weblogic-enterprise-bean> <weblogic-enterprise-bean> <ejb-name>AppScopedResourceConstraintEJB</ejb-name> <jndi-name>core_work_ejb_resource_AppScopedResourceConstraintEJB </jndi-name> <dispatch-policy>test_appscoped_resource</dispatch-policy> </weblogic-enterprise-bean> <work-manager> <name>test_resource</name> <max-threads-constraint> <name>pool_constraint</name> <pool-name>testPool</pool-name> </max-threads-constraint> </work-manager> <work-manager> <name>test_appscoped_resource</name> <max-threads-constraint> <name>appscoped_pool_constraint</name> <pool-name>AppScopedDataSource</pool-name> </max-threads-constraint> </work-manager> </weblogic-ejb-jar>
コード リスト 2-7 CommonJ ワーク マネージャを含む weblogic-ejb-jar.xml
CommonJ の使い方については、「WebLogic Server での CommonJ の使い方」および CommonJ の Javadoc を参照してください。
コード リスト 2-8 weblogic-application.xml
<weblogic-application xmlns="http://xmlns.oracle.com/weblogic/weblogic-application" xmlns:j2ee="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-application http://xmlns.oracle.com/weblogic/weblogic-application/1.0/weblogic-application.xsd"> <max-threads-constraint> <name>j2ee_maxthreads</name> <count>1</count> </max-threads-constraint> <min-threads-constraint> <name>j2ee_minthreads</name> count>1</count> </min-threads-constraint> <work-manager> <name>J2EEScopedWorkManager</name> </work-manager> </weblogic-application>
この Web アプリケーションは、コード リスト 2-8 で定義したエンタープライズ アプリケーションの一部としてデプロイされます。この Web アプリケーションの記述子では、2 つのワーク マネージャを定義しています。どちらのワーク マネージャも、アプリケーションの weblogic-application.xml ファイルで定義した同じ最大スレッド数制約 (j2ee_maxthreads) を参照しています。応答時間要求クラスは、ワーク マネージャごとに異なっています。
コード リスト 2-9 Web アプリケーション記述子
<weblogic xmlns="http://xmlns.oracle.com/weblogic" xmlns:j2ee="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/weblogic http://xmlns.oracle.com/weblogic/1.0/weblogic.xsd"> <work-manager> <name>fast_response_time</name> <response-time-request-class> <name>fast_response_time</name> <goal-ms>2000</goal-ms> </response-time-request-class> <max-threads-constraint-name>j2ee_maxthreads </max-threads-constraint-name> </work-manager> <work-manager> <name>slow_response_time</name> <max-threads-constraint-name>j2ee_maxthreads </max-threads-constraint-name <response-time-request-class> <name>slow_response_time</name> <goal-ms>5000</goal-ms> </response-time-request-class> </work-manager> </weblogic>
コード リスト 2-10 の記述子は、context-request-class を使用してワーク マネージャを定義します。
コード リスト 2-10 Web アプリケーション記述子
<?xml version="1.0" encoding="UTF-8"?> <weblogic-web-app xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app" xmlns:j2ee="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-web-app http://xmlns.oracle.com/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd"> <work-manager> <name>foo-servlet-1</name> <request-class-name>test-fairshare2</request-class-name> <max-threads-constraint> <name>foo-mtc</name> <pool-name>oraclePool</pool-name> </max-threads-constraint> </work-manager> <work-manager> <name>foo-servlet</name> <context-request-class> <name>test-context</name> <context-case> <user-name>anonymous</user-name> <request-class-name>test-fairshare1</request-class-name> </context-case> <context-case> <group-name>everyone</group-name> </context-request-class> </work-manager> </weblogic-web-app>
この節では、実行キューとの下位互換性を有効にし、実行キューの代わりにワーク マネージャを使用するようアプリケーションを移行する方法について、説明します。
WebLogic Server バージョン 8.1 では、スレッド管理の処理のために実行キューを実装していました。実行キューを使用すると、スレッド プールを作成して、作業負荷の処理方法を決定できました。WebLogic Server は、引き続き下位互換性のために実行キューを提供しています。これは主に、アプリケーションの移行を支援するためです。ただし、新しいアプリケーションを開発する際には、ワーク マネージャを利用して、より効率的にスレッド管理を行うことが必要です。
実行キューの有効化は、次のようにして行うことができます。
コマンドライン オプション -Dweblogic.Use81StyleExecuteQueues=true を使用する
config.xml のカーネル MBean を介して Use81StyleExecuteQueues プロパティを設定
実行キューを有効化すると、すべてのワーク マネージャのコンフィグレーションとスレッドの自動チューニングが無効化されます。実行キューは WebLogic Server 8.1 の場合とまったく同じように動作します。『Oracle Fusion Middleware Oracle WebLogic Server パフォーマンス チューニング ガイド』の「WebLogic 8.1 のスレッド プール モデルの使用」を参照してください。
有効化されたワーク マネージャは、以下のルールに基づき、実行キューに変換されます。
ワーク マネージャで最小スレッド数制約または最大スレッド数制約が実装されている場合、実行キューはワーク マネージャと同じ名前で作成される。実行キューのスレッド数は、制約で定義された値に基づいています。
ワーク マネージャで制約が実装されていない場合、グローバル デフォルト実行キューが使用される。
ワーク マネージャには、WorkManagerMBean コンフィグレーション MBean を使用してアクセスすることができます。詳細については、「WorkManagerMBean」を参照してください。
WorkManagerMBean へは、アプリケーションのワーク マネージャへのアクセス方法に応じて、実行時ツリーまたはコンフィグレーション ツリーでアクセスします。
ワーク マネージャがモジュール レベルで定義されている場合、対応する ComponentRuntimeMBean を介して、WorkManagerRuntime MBean が使用できる。
ワーク マネージャがアプリケーション レベルで定義されている場合、ApplicationRuntime を介して、WorkManagerRuntime が使用できる。
ワーク マネージャが config.xml 内でグローバルに定義されている場合、各アプリケーションは、専用のワーク マネージャ インスタンスを作成する。各アプリケーションには、アプリケーション レベルで使用できる、専用の対応する WorkManagerRuntime があります。
WebLogic Server ワーク マネージャでは、管理者がサーブレットおよび EJB に対してディスパッチ ポリシーを設定できるよう、サーバ レベルのコンフィグレーションを提供しています。
WebLogic Server はまた、アプリケーション内からプログラム的に作業を処理するための方法も用意しています。これは、CommonJ API を通じて提供されます。Weblogic Server は、CommonJ 仕様の commonj.work パッケージおよび commonj.timers パッケージを実装しています。
WebLogic Server における CommonJ の実装に関する特定的な情報については、CommonJ の Javadoc を参照してください。
CommonJ の WebLogic Server 実装を使用すると、アプリケーションは、WebLogic Server でコンフィグレーション済みの複数のワーク マネージャを使用して、1 つの要求のタスクを複数の作業項目に分割し、その作業項目を割り当てて、同時に実行することができます。作業項目を同時に実行する必要のないアプリケーションでも、コンフィグレーション済みのワーク マネージャを使用することができます。それには、デプロイメント記述子でワーク マネージャを参照または作成するか、Java EE コネクタの場合は JCA API を使用します。
WebLogic Server 実装と CommonJ 仕様の相違点をいくつか、以下に示します。
RemoteWorkItem インタフェースは、CommonJ 仕様によって提供された任意指定のインタフェースであり、WebLogic Server ではサポートされていない。WebLogic Server では、独自のクラスタ ロード バランシングおよびフェイルオーバ ポリシーを実装しています。作業負荷管理は、これらのポリシーに基づいて行われます。
WebLogic CommonJ タイマーの動作は、java.util.Timer とは異なる。WebLogic CommonJ タイマーは、実行が所定期間の 2 倍を超えると、それ以上の遅延を防止するため、いくらかの期間をスキップします。java.util.Timer は、このような処理を行いません。
WebLogic Server ワーク マネージャにアプリケーションからアクセスするにはディスパッチ ポリシーを使用する必要がありますが、CommonJ ワーク マネージャはアプリケーションから直接アクセスできます。次のサンプル コードに、JNDI を使用して CommonJ ワーク マネージャをルックアップする方法を示します。
InitialContext ic = new InitialContext();
commonj.work.WorkManager wm =
(commonj.work.WorkManager)ic.lookup("java:comp/env/wm/myWM");
CommonJ ワーク マネージャの使い方の詳細については、CommonJ の Javadoc を参照してください。
外部定義した CommonJ ワーク マネージャは、WebLogic Server ワーク マネージャにマッピングできます。たとえば、次の例のように、記述子 ejb-jar.xml で定義した CommonJ ワーク マネージャがあるとします。
<resource-ref> <res-ref-name>minthreads_workmanager</res-ref-name> <res-type>commonj.work.WorkManager</res-type> <res-auth>Container</res-auth> <res-sharing-scope>Shareable</res-sharing-scope> </resource-ref>
これを WebLogic Server ワーク マネージャにリンクさせるには、WebLogic Server の記述子 (たとえば weblogic-ejb-jar.xml) の name 要素を完全に一致させます。
<work-manager> <name>minthreads_workmanager</name> <min-threads-constraint> <count>5</count> </min-threads-constraint> </work-manager>
この手順は、web.xml に定義した resource-ref と同様です。WebLogic Server ワーク マネージャは、モジュール記述子 (たとえば weblogic-ejb-jar.xml や weblogic.xml) またはアプリケーション記述子 (weblogic-application.xml) で定義できます。
