20 WebLogic Tuxedo Connectorのチューニング

この章では、WebLogic Tuxedo Connector (WTC)アプリケーションのパフォーマンスを最大にする方法について説明します。WebLogic Tuxedo Connector (WTC)では、WebLogic ServerアプリケーションとTuxedoサービスの相互運用性が実現されます。WTCを使用すると、サービス・リクエストに応じて、WebLogic ServerクライアントがTuxedoサービスを呼出し、TuxedoクライアントがWebLogic Server Enterprise Java Beans (EJBs)を呼出すことができます。『Oracle WebLogic Serverインフォメーション・ロードマップ』のWebLogic Tuxedo Connectorに関する項を参照してください。

• 構成のガイドライン

• ベスト・プラクティス

構成のガイドライン

WebLogic Tuxedo Connectorの構成を行う際には、次のガイドラインに従ってください。

• 構成には複数のWTCサービスを設定できます。

• 1つのサーバー・インスタンスにはWTCサービスを1つだけターゲット指定できます。

• WTCでは接続プール機能がサポートされません。WTCではリクエストは多重化されますが、単一の物理的接続を使用します。

• 構成の変更は次のように実装されます。

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

  • 接続/セッションの確立後に、セッション/接続構成(ローカルAP、リモートAP、パスワードおよびリソース)を変更。変更は受け入れられますが、接続を切離して再接続しないかぎり既存の接続/セッションに実装されません。Oracle WebLogic Server管理コンソール・ヘルプの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 WebLogic Server WebLogic Tuxedo Connector管理ガイド』のアクセス・ポイント間の接続の構成に関する項を参照してください。

• ON_DEMANDの接続ポリシーを使用しないでください。望ましい接続ポリシーは、ON_STARTUPとINCOMING_ONLYです。これにより、ON_DEMANDのルーティング・セマンティクスによるサービス・リクエストの失敗の可能性が低減します。『Oracle WebLogic Server WebLogic Tuxedo Connector管理ガイド』のアクセス・ポイント間の接続の構成に関する項を参照してください。

• アプリケーションを設計するときに、リンク・レベル・フェイルオーバー、サービス・レベル・フェイルオーバーおよびロード・バランシングなどのWTC機能の使用を考慮してください。『Oracle WebLogic Server WebLogic Tuxedo Connector管理ガイド』のフェイルオーバーとフェイルバックの構成に関する項を参照してください。

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

  • WebLogic ServerクラスタのすべてのノードにWTCインスタンスを構成します。

  • 各クラスタ・ノードの各WTCインスタンスで同じ構成にする必要があります。

  『Oracle WebLogic Server WebLogic Tuxedo Connector管理ガイド』のWebLogic Tuxedo Connectorのクラスタリングされた環境での管理方法に関する項を参照してください。

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

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

  • Link-level暗号化を有効にして、min-encrypt-bitsパラメータを40に設定し、max-encrypt-bitsを128に設定します。『Oracle WebLogic Server WebLogic Tuxedo Connector管理ガイド』のLink-Level暗号化に関する項を参照してください。

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

  • 『Oracle WebLogic Server WebLogic Tuxedo Connectorプログラマーズ・ガイド』の アプリケーション・エラー管理に関する項を参照してください。

  • 『Oracle WebLogic Server WebLogic Tuxedo Connector管理ガイド』のシステム・レベル・デバッグ設定に関する項を参照してください。

• TypedFML32バッファ内に埋め込まれたTypedFML32バッファを使用しないでください。『Oracle WebLogic Server WebLogic Tuxedo Connectorプログラマーズ・ガイド』のWebLogic Tuxedo ConnectorにおけるFMLの使用に関する項を参照してください。

• アプリケーションへの負荷が大きい場合、より多くのリモートTuxedoアクセス・ポイントを構成し、そのアクセス・ポイント間でWTCの作業負荷をロード・バランスしてください。『Oracle WebLogic Server WebLogic Tuxedo Connector管理ガイド』のフェイルオーバーとフェイルバックの構成に関する項を参照してください。

• トランザクション・アプリケーションを使用するときに、同じリモート・アクセス・ポイントから利用可能な同じトランザクションにリモート・サービスを含めるようにしてください。『Oracle WebLogic Server WebLogic Tuxedo Connectorプログラマーズ・ガイド』のWebLogic Tuxedo Connector JATMIトランザクションに関する項を参照してください。

• ゲートウェイからサービスをディスパッチするときに利用可能なクライアント・スレッド数によって、同時に実行しているサービス数が制限される場合があります。利用可能なスレッド数を増やすWebLogic Tuxedo Connector属性は存在しません。サービスを呼出すときに適切なスレッド・モデルを使用します。『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)の間で適切にロード・バランシングするよう構成する方法を示します。

表20-1 ロード・バランシングの正しい構成の例

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

次の例は、ロード・バランシングのリクエストを不適切に構成した場合です。この構成では、service1に対して同じ複合キーが使用されます。

表20-2 ロード・バランシングの誤った構成の例

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