19 WebLogic Tuxedo Connector のチューニング

WebLogic Tuxedo Connector (WTC) によって、WebLogic Server アプリケーションと Tuxedo サービス間の相互運用性が提供されます。WTC では、WebLogic Server クライアントが Tuxedo サービスを呼び出し、Tuxedo クライアントがサービス要求に応じて WebLogic Server エンタープライズ JavaBean (EJB) を呼び出すことができます。『Oracle Fusion Middleware Oracle WebLogic Server のインフォメーション ロードマップ』の「WebLogic Tuxedo Connector」を参照してください。

以下の節では、WTC アプリケーションから最高のパフォーマンスを引き出すための方法を示します。

• コンフィグレーションのガイドライン

• ベスト プラクティス

コンフィグレーションのガイドライン

WebLogic Tuxedo Connector のコンフィグレーションを行う際には、以下のガイドラインに従ってください。

• コンフィグレーションには複数の WTC サービスを設定できる。

• 1 つのサーバ インスタンスには WTC サービスを 1 つだけ対象指定できる。

• WTC では接続プール機能がサポートされない。WTC では要求は多重化されますが、単一の物理的接続を使用します。

• コンフィグレーションの変更は以下のように実装される。

  • セッションまたは接続のコンフィグレーション (ローカル AP、リモート AP、パスワード、およびリソース) を、セッションまたは接続の確立前に変更した場合。変更は受け入れられ、新しいセッションまたは接続に実装されます。

  • セッションまたは接続のコンフィグレーション (ローカル AP、リモート AP、パスワード、およびリソース) を、セッションまたは接続の確立後に変更した場合。変更は受け入れられますが、接続が切断されるか再接続されるまで既存のセッションまたは接続に実装されません。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「WTC サービスの割り当て」を参照してください。

  • インポート済みサービスやエクスポート済みサービスのコンフィグレーションを変更した場合。変更は受け入れられ、次回の着信要求または発信要求に実装されます。この方法は、処理中の要求が不明な状態のままになるためお勧めしません。

  • tBridge のコンフィグレーションを変更した場合。デプロイされた WTC サービスを変更すると常に例外が発生します。tBridge のコンフィグレーションを変更する前には、必ず WTC サービスの対象指定を解除するようにします。対象指定を解除してコンフィグレーションを変更した後には、必ず WTC サービスを対象指定して変更を実装します。

ベスト プラクティス

この節では、WTC 使用時のベスト プラクティスを紹介します。

• 接続ポリシーをコンフィグレーションする場合、ON_STARTUP と INCOMING_ONLY を使用する。ON_STARTUP と INCOMING_ONLY は常に一対のものとされます。たとえば、WTC リモート アクセス ポイントが ON_STARTUP でコンフィグレーションされている場合、Tuxedo ドメイン コンフィグレーションの DM_TDOMAIN セクションではリモート アクセス ポイントが INCOMING_ONLY としてコンフィグレーションされている必要があります。この場合、WTC は常にセッションの開始者として機能します。『Oracle Fusion Middleware Oracle WebLogic Server Tuxedo Connector 管理ガイド』の「アクセス ポイント間の接続のコンフィグレーション」を参照してください。

• ON_DEMAND 接続ポリシーは使用しないようにする。推奨される接続ポリシーは ON_STARTUP および INCOMING_ONLY です。これを設定すると ON_DEMAND ルーティング セマンティクスにより、サービス要求障害の発生するおそれが減少します。『Oracle Fusion Middleware Oracle WebLogic Server Tuxedo Connector 管理ガイド』の「アクセス ポイント間の接続のコンフィグレーション」を参照してください。

• リンクレベルのフェイルオーバ、サービス レベルのフェイルオーバ、およびアプリケーション設計時のロード バランシングといった WTC の機能の使用を検討する。『Oracle Fusion Middleware Oracle WebLogic Server Tuxedo Connector 管理ガイド』の「フェイルオーバとフェイルバックのコンフィグレーション」を参照してください。

• WebLogic Server クラスタを使用した追加的なロード バランシングおよびフェイルオーバの使用を検討する。WTC を WebLogic Server クラスタ内で使用する方法は以下のとおりです。

  • WebLogic Server クラスタのすべてのノードに WTC インスタンスをコンフィグレーションする。

  • 各クラスタ ノードの各 WTC インスタンスを必ず同じコンフィグレーションとする。

  『Oracle Fusion Middleware Oracle WebLogic Server Tuxedo Connector 管理ガイド』の「クラスタ環境における Oracle WebLogic Tuxedo Connector の管理方法」を参照してください。

• WTC から Tuxedo への接続にインターネットを使用する場合、以下のセキュリティ設定を使用する。

  • Security の値を DM_PW に設定する。『Oracle Fusion Middleware Oracle WebLogic Server Tuxedo Connector 管理ガイド』の「リモート アクセス ポイントの認証」を参照してください。

  • リンクレベルの暗号化を有効にして、min-encrypt-bits パラメータを 40、max-encrypt-bits パラメータを 128 に設定する。『Oracle Fusion Middleware Oracle WebLogic Server Tuxedo Connector 管理ガイド』の「リンクレベルの暗号化」を参照してください。

• エラー条件をアプリケーションで管理し解釈するメカニズムをアプリケーション ロジックで提供する必要がある。

  • 『Oracle Fusion Middleware Oracle WebLogic Server Tuxedo Connector プログラマーズ ガイド』の「アプリケーション エラーの管理」を参照。

  • 『Oracle Fusion Middleware Oracle WebLogic Server Tuxedo Connector 管理ガイド』の「システム レベルのデバッグ設定」を参照。

• 組み込みの TypedFML32 バッファを TypedFML32 バッファ内で使用しないようにする。『Oracle Fusion Middleware Oracle WebLogic Server Tuxedo Connector プログラマーズ ガイド』の「Oracle WebLogic Tuxedo Connector での FML の使用」を参照してください。

• アプリケーションで負荷の大きな状況を扱う場合、リモートの Tuxedo アクセス ポイントをさらにコンフィグレーションして、アクセス ポイント間で WTC が作業負荷をロード バランスするように設定することを検討する。『Oracle Fusion Middleware Oracle WebLogic Server Tuxedo Connector 管理ガイド』の「フェイルオーバとフェイルバックのコンフィグレーション」を参照してください。

• トランザクション対応のアプリケーションを使用している場合、同じトランザクションに関与するリモート サービス群を同じリモート アクセス ポイントから利用できるようにすることを試みる。『Oracle Fusion Middleware Oracle WebLogic Server Tuxedo Connector プログラマーズ ガイド』の「Oracle WebLogic Tuxedo Connector JATMI トランザクション」を参照してください。

• ゲートウェイからサービスをディスパッチするときに使用できるクライアント スレッドの数によって、同時に実行できるサービスの数が制限されることがあります。WebLogic Tuxedo Connector には、利用可能なスレッド数を増加させる属性はありません。サービスを呼び出す場合は、適切なスレッド モデルを使用してください。「スレッド管理」および『Oracle Fusion Middleware Oracle WebLogic Server サーバ環境のコンフィグレーション』の「ワーク マネージャを使用したスケジューリング済み作業の最適化」を参照してください。

• WebLogic Server のリリース 9.2 以降には高度なルーティング アルゴリズムがあり、トランザクションのパフォーマンスを向上させることができる。特に、2 フェーズ コミット (2PC) トランザクションに複数の Tuxedo サービス要求が関与する場合、パフォーマンスが向上します。アプリケーションが Tuxedo ドメインに対してサービスを一度だけ要求する場合、以下の WebLogic Server コマンドライン パラメータを設定してこの機能を無効にできます。

  -Dweblogic.wtc.xaAffinity=false
  

• コンストラクタ TypedFML32 をバッファ内のオブジェクトの最大数を使用して呼び出す。最大数の予測が困難な場合でも、適切な数を指定するとパフォーマンスが向上します。フィールド数に 1.33 を乗算すると、おおよその最大数を算出できます。

  
  

  注意 : このパフォーマンスに関するヒントは TypedFML バッファ タイプには当てはまりません。

  
  

  次に例を示します。

  TypedFML32 バッファ タイプにフィールドが 50 ある場合、最大数は 63 になります。コンストラクタ TypedFML32(63, 50) を呼び出す方が TypedFML32() を呼び出すよりもパフォーマンスが良くなります。

  TypedFML32 バッファ タイプにフィールドが 50 あってそれぞれが最大 10 回まで繰り返せる場合、コンストラクタ TypedFML32(625, 50) を呼び出す方が TypedFML32() を呼び出すよりもパフォーマンスが良くなります。

• WTC クライアントと相互運用するサーバとして働く Tuxedo アプリケーションをコンフィグレーションする場合、並行処理の実施を検討する。並行処理は、さまざまな Tuxedo マシン上にさまざまなサーバを入念にコンフィグレーションすると可能になる場合があります。

• Tuxedo アプリケーションにおけるデータベース アクセスのデッドロックの可能性に注意する。デッドロックは Tuxedo アプリケーションを注意深くコンフィグレーションすることで回避できます。

• WTC のロード バランシングまたはサービス レベルのフェイルオーバを使用している場合、WTC トランザクション アフィニティを無効化しないことを推奨。

• 発信要求をロード バランシングする場合、インポート済みサービスを複数のエントリと共に異なるキーを使用してコンフィグレーションする。インポート済みサービスでは、各レコードがユニークであるかどうかを複合キーを使用して判断します。複合キーは「サービス名 + ローカル アクセス ポイント + リモート アクセス ポイント リストのプライマリ ルート」で構成されています。

  以下の例に、service1 に対する要求を TDomainSession(WDOM1,TUXDOM1) と TDomainSession(WDOM1,TUXDOM2) の間で適切にロード バランシングするようコンフィグレーションする方法を示します。

表 19-1 適切にコンフィグレーションされたロード バランシングの例

ResourceName	LocalAccessPoint	RemoteAccessPointList	RemoteName
service1	WDOM1	TUXDOM1	TOLOWER
service1	WDOM1	TUXDOM2	TOLOWER2

以下の例は、ロード バランシングの要求を不適切にコンフィグレーションした場合です。このコンフィグレーションでは、service1 に対して同じ複合キーが使用されます。

表 19-2 不適切にコンフィグレーションされたロード バランシングの例

ResourceName	LocalAccessPoint	RemoteAccessPointList	RemoteName
service1	WDOM1	TUXDOM1	TOLOWER
service1	WDOM1	TUXDOM1	TOLOWER