パフォーマンス結果について
テストに使用されるシステムは、フランクフルトおよびアムステルダムのOracle Cloud Infrastructure (OCI)リージョン全体で構成されたOracle Fusion Middleware (FMW)ストレッチ・クラスタです。
WebLogicドメインは、異なる場所に分散した5つのノードで構成され、様々なトポロジ(データベースと同じ可用性ドメインで実行されているサーバー、同じリージョン内の異なる可用性ドメインで実行されているサーバー、および異なるリージョンに配置されているサーバー)のパフォーマンス比較を可能にします。
これらのストレス・テストは、SOA Fusion Order Demo (FOD)をサンプルSOAアプリケーションとして使用して実行されました。オーダーの完了時に、Java Message Service (JMS)メッセージをUniform Distributed Destination (UDD)宛先に挿入するようにFODデモが変更されました。この例はデータベース集中型で、ファイル・アダプタやJMSアダプタなど、複数のSOAアダプタを使用します。また、メディエータ、Business Process Execution Language (BPEL)、ルール・エンジンおよび複数のWebLogic機能などの様々なSOAコンポーネントも含まれます。
次の図は、テストに使用されるFMWストレッチ・クラスタ環境を示しています。
fmw-stretched-performance-env-oracle.zip
この環境内のネットワーク間の実際の待機時間値は次のとおりです。
| ホスト間 | 平均レイテンシ(RTT、ミリ秒) |
|---|---|
| 同じ可用性ドメインに存在 | 0.3 |
| 同じリージョン内にあるが、可用性ドメインが異なる | 0.6 |
| 異なる地域(フランクフルトとアムステルダム) | 6.5 |
ストレス・テストのレビュー
テストされた構成の一部を次に示します。
- 2つのノードを稼働させてクラスタをストレスにし、サーバー間およびいずれかのサーバー間で異なる待機時間をデータベースに適用します。
- 個々のサーバーのストレス・テスト。各サーバーは、データベースに対して異なる待機時間を持ちます。
- データベース(ローカルのみ)と、両方のサーバーがデータベースからリモートに配置されている(リモートのみ)両方のサーバーでテストを実行します。
- 各リージョンで2つのノードがアクティブなクラスタをストレスします。
構成ごとに、異なるワークロードがテストされました。すべてのワークロード・リクエストは、まずフロント・エンドに送信され、そこでOracle WebLogic Serverインスタンス間で(グローバル・ロード・バランシング、ローカル・ロード・バランサ、Webサーバーを介して)分散されます。ワークロード・カテゴリ(低、中、高)は、各設定のアクティブ・ノードの数に依存し、データベースの同時実行性の制限によって制約されます。たとえば、80の同時仮想ユーザーは、実行中のノードが4つある場合はWebLogicサーバーのワークロードが低いとみなされ、アクティブなノードが1つのみの場合は高いワークロードとみなされます。ただし、データベースの観点では、ワークロードは同じままです。わかりやすくするために、使用されるワークロードは次のとおりです。
- 低ワークロード(WebLogicサーバー当たり20の同時仮想ユーザー、システム内の同時仮想ユーザー数は最大40)
- 中程度のワークロード(WebLogicサーバー当たり40から60の同時仮想ユーザー、システム内の同時仮想ユーザー合計最大120)
- 高いワークロード(WebLogicサーバーごとに80の同時仮想ユーザー、システムで最大160の同時仮想ユーザー)
ストレス・テストの結果に基づいて、次の結論が得られます。
- クラスタ全体のパフォーマンス
2台のサーバーを持つクラスタにおけるクラスタ全体のパフォーマンス(WebLogicスループット、トランザクション/秒(TX/秒))
- 両方のサーバーが同じ可用性ドメイン(AD)にある場合(参照として取得): 100%
- 各サーバーが異なるADの場合: ~100%
- 1つのサーバーが別のリージョン(6.5ms往復時間(RTT)): 90-95%
- 両方のサーバーがDBとは異なるリージョンにある場合(6.5ms RTT): 85-95%
- サーバーごとのパフォーマンス
サーバーごとのパフォーマンス(WebLogicスループット、TX/秒)
- DBと同じADのサーバー(参照)の場合: 100%
- 他のADのサーバーの場合: 98-99%
- 他のリージョンのサーバーの場合: 85-90%
- アクティブなデータ・ソース接続の数
アクティブなデータ・ソース接続の数は、データベースへの待機時間が長くなるにつれて増加します。ワークロードに依存しますが、リージョン2のサーバーは、データベースと同じ場所に配置されたサーバーよりも最大2xのアクティブ接続を表示します。WebLogicデータ・ソースおよびデータベース・セッションのサイズを正しく設定するには、この点を考慮してください。
- JTAトランザクション
JTAトランザクションは、データベースに対するレイテンシが高くなるサーバーでは、より長い期間アクティブのままです。より長い期間アクティブなままのトランザクションは、失敗の影響を受ける可能性が高くなります。したがって、これらのシステムでは、トランザクション・ログでJDBC永続ストアが使用されることが特に重要になります。サーバー障害の場合は、サービスの移行が実行され、リカバリが自動的に行われます。
- リージョン間のレイテンシ
6.5ms RTTのリージョン間のレイテンシ、およびFMWストレッチ・クラスタに対するこのドキュメントによって提供されるベスト・プラクティスの実装の場合:
- ストレッチされたクラスタ(10%)を使用したパフォーマンス低下は低くなります。
- 各リージョンに1つのサーバーがあり、リモート・リージョンに両方のサーバーがあるクラスタについても、同様のパフォーマンスが低下します。これは、クラスタ内通信も待機時間の影響を受けるためです。
- AD間のレイテンシ
AD間のレイテンシ(0.6ms)は、SOA FODシステムの全体的なパフォーマンスに大きく影響しません。
ノート:
前述のすべてを考慮し、多くのテストでパフォーマンス・ペナルティが確認されたため、Oracleでは、サイト間のレイテンシ(RTT)が10ミリ秒を超えるOracle Fusion Middlewareストレッチ・クラスタはサポートされません。システムは問題なく動作する可能性がありますが、トランザクション時間は大幅に増加します。レイテンシが10ミリ秒(RTT)を超えると、デプロイメントおよびJT、Webサービスまたはアプリケーション・タイムアウトに使用されるOracle Coherenceクラスタでも問題が発生します。これにより、このプレイブックに示されているソリューションは、主にサイトまたはリージョン間のレイテンシが低い場合に適しています。
2つのノードを持つクラスタを強調表示する場合、次のチャートは、サーバーが配置されている場所に応じて、クラスタの全体的なパフォーマンスを示します。参照(100%)は、両方のサーバーがデータベースと同じADで実行されている場合です。
2つのノードがあるクラスタを強調表示する場合、次のチャートは、データベースとコロケートされているサーバーのパフォーマンスと比較して、データベースとコロケートされていない(他のADまたはリモート・リージョンにある)サーバーのパフォーマンスを示します。
2つのノードを持つクラスタを強調表示する場合、これらのチャートには、各サーバーのアクティブなデータ・ソース接続の数(平均)が表示されます。1つのサーバーは常にデータベース(site1)とコロケートされ、もう1つのサーバーはデータベース(site2)と異なるレイテンシ値になります。
データベース・レイテンシが異なる単一サーバーに負荷をかけると、中負荷から高負荷のときにデータベースと共存するサーバーと比較して、次のパフォーマンス結果が得られます。参照(100%)は、サーバーがデータベースと同じADにある場合です。
データベースに対する待機時間が異なる単一のサーバーを強調表示する場合、これは中から高のストレスの下のアクティブ・データ・ソース接続です。
データベースの待機時間が異なる単一のサーバーに負荷をかける場合、次の図は、データベースに対する様々な待機時間の平均JTAアクティブ時間を示しています。
データベース(ローカルのみ)と同じリージョンにある両方のサーバーと、データベースとは異なるリージョンにある両方のサーバーがあるクラスタ(リモートのみ)のパフォーマンスを比較する場合、次のパフォーマンス結果が確認されます。参照(100%)は、ローカル専用のクラスタです。
次の図は、両方のサーバーがデータベースと同じリージョンで実行されている(ローカルのみ)クラスタと、両方のサーバーがデータベースとは異なるリージョンで実行されている(リモートのみ)クラスタのJTA TX平均アクティブ時間を示しています。
レビュー開始時刻
データ・ソースの初期容量設定に従って、異なる遅延が予想されます。デフォルトでは、ほとんどのOracle Fusion Middleware (FMW)データ・ソースは、接続プールにゼロの初期容量を使用します。ただし、通常のランタイム操作中のシステムの応答時間を短縮するために、初期プール容量を増やすと有益な場合があります。ただし、ストレッチされたクラスタでは、データベースにリモートに存在するサーバーは、初期プール容量が大きいほど、起動時のレイテンシが増加します。
通常の操作中にレスポンス時間を最適化し、開始時間を最小化して理想的な初期容量設定を決定するには、バランスのとれた決定が必要です。初期容量はデータ・ソース(接続プール)レベルで構成されているため、これらの設定は、クラスタ内のすべてのサーバー(データベースに対してローカルなサーバーおよびリモートのサーバー)の起動時間に影響します。
次のグラフは、すべてのデータ・ソースの様々な初期サイズ値(合計で11のデータ・ソース)について、データベースのレイテンシが増加するにつれてWebLogicサーバーの起動時間を示します。
JMSサービス移行時間の確認
ただし、リージョン1からリージョン2へのサービス移行操作にかかる時間は、データベースへのレイテンシにより長くなる可能性があります。この増加は、他のリージョンのデータベース内の永続ストアからメッセージが読み取られるため、他のサーバーでのメッセージのリカバリに要した時間が原因です。
永続ストアに多数の保留中のメッセージがある場合、増分は大きくなります。サイズがそれぞれ2.7KBのJMSメッセージの場合、次の図は、永続ストアの1つに多数の保留メッセージ(約8000)があり、サービスがデータベースとコロケートされたサーバーから別のサーバーに移行され、宛先サーバーとデータベースのレイテンシが異なる場合のJMSサービスの移行時間を示しています。
次の図は、宛先サーバーとデータベース間の異なるレイテンシに対して、多数の保留メッセージ(約8000)があるサービス移行時間の増分(%)を示しています。参照(100%)は、サービスがデータベースと同じ可用性ドメイン(AD)のサーバーに移行する場合です。
次の図は、同じケースの移行時間を示していますが、宛先サーバーとデータベース間の待機時間が異なる保留中のメッセージ数が少ない(約50)場合を示しています。
次の図は、宛先サーバーとデータベース間のレイテンシが異なる保留中のメッセージ数が少ないJMSサービス移行時間の増分(%)を示しています(約50)。参照(100%)は、サービスがデータベースと同じADのサーバーに移行する場合です。
SOAコンポジットのデプロイメント時間のレビュー
コンポジットをデプロイする場合(最初のバージョンをデプロイする場合、または新しいバージョンに更新する場合)、コンポジットはリージョン2のサーバーよりもリージョン1のサーバーにデプロイできますが、クラスタのすべてのメンバーで使用可能になるまで正式にはアクティブ化されません。
次の図は、サーバー起動時にコンポジットをサーバーにロードするのに要した時間の増加を示しています。データベースへのレイテンシは、データベースと同じ可用性ドメイン(AD)に存在するサーバーへのロードに要した時間と比較されます。コンポジット・サイズは365KBです。
次の図は、Oracle WebLogic Scripting Tool (WLST)コマンドを使用したコンポジットのデプロイにかかる時間が長くなり、データベースへのデプロイを実行するサーバーとのレイテンシが異なります。
サイト間のトラフィックの確認
ただし、この分離は非決定的です(たとえば、2つのサイト間でJava Message Service (JMS)呼出しが発生する可能性があるフェイルオーバー・シナリオの余地があります)。つまり、一般的なアプリケーションでは、ほとんどのトラフィックがOracle WebLogic Serverインスタンスとデータベース間で発生します。これは、Oracle Fusion Middleware (FMW)ストレッチ・クラスタ・トポロジのパフォーマンスの鍵となります。この図は、ストレス・テスト中のリージョン2のWebLogicサーバーとリージョン1の異なるアドレス間のトラフィックの割合を示しています。90%を超えるトラフィックが、リージョン1にあるサーバーとデータベースの間で発生することに注意してください。
サイト間のIPごとのトラフィックの量を取得するには、iftopツールを使用します。たとえば:
sudo iftop -i ens3 -F <remote_site_CIDR> -n -t -s 900次の図は、ストレス・テスト中のリージョン2のWebLogicサーバーとリージョン1の異なるアドレス間のトラフィックの割合を示しています。
