このトピックでは、ボトルネックを調査するための推奨されるプロセスについて説明します。
問題の原因は何ですか?
ボトルネックの原因は、ハードウェアまたはソフトウェアに関連している可能性があります。 リソースの使用が不足している場合、通常はボトルネックを示します。 ボトルネックは、ハードウェアの制限、非効率的なソフトウェア構成、またはその両方によって発生する可能性があります。
ボトルネックの特定は増分プロセスであり、1 つのボトルネックを緩和することで、次のボトルネックが検出される可能性があります。 これらのボトルネックを特定して緩和する科学は、このトピックの目的です。 システムがピーク時に短時間実行される可能性があります。 ただし、持続可能なスループットのために、システムは最も遅いパフォーマンスのコンポーネントと同じくらい速く処理できます。
反復的アプローチを用いたテスト
ボトルネックは、システムのエンドポイント (入退出) または中央 (オーケストレーション/データベース) で発生する可能性があります。 ボトルネックが分離されたら、構造化されたアプローチを使用してソースを特定します。 ボトルネックが緩和されたら、パフォーマンスをもう一度測定して、システムの他の場所に新しいボトルネックが導入されていないことを確認することが重要です。
ボトルネックを特定して修正するプロセスは、反復的に行う必要があります。 一度に 1 つのパラメーターのみを変更し、各テストの実行中にまったく同じ手順を繰り返し、パフォーマンスを測定して、1 つの変更の影響を確認します。 一度に複数のパラメーターを変更すると、変更の効果が隠される可能性があります。
たとえば、パラメーター 1 を変更すると、パフォーマンスが向上する可能性があります。 ただし、パラメーター 2 をパラメーター 1 の変更と組み合わせて変更すると、悪影響を及ぼす可能性があり、パラメーター 1 を変更する利点が無効になる可能性があります。 これにより、純ゼロ効果が発生し、パラメーター 1 の変化の影響に対して偽陰性が発生し、パラメーター 2 の変化の影響に対して偽陽性が発生します。
一貫性のテスト
設定を変更した後のパフォーマンス特性の測定は、変更の影響を検証するために行う必要があります。
ハードウェア- ハードウェアを変更すると動作が一貫性がなく、誤解を招く結果が生じる可能性があるため、一貫性のあるハードウェアを使用してください。 たとえば、ノート PC を使用して BizTalk ソリューションのパフォーマンスをテストすることはできません。
テスト実行時間 - 結果が持続可能であることを確認するために、一定の最小期間のパフォーマンスを測定します。 テストを長期間行うことで、システムは最初のウォームアップ/ランプアップ期間を経て、すべてのキャッシュが満たされ、データベーステーブルが期待される数値に達します。また、定義済みのしきい値に達した場合、スループットを調整するための十分な時間が確保されます。 このアプローチは、最適な持続可能なスループットを発見するのに役立ちます。
テスト パラメーター – テストの実行からテストの実行まで、テスト パラメーターを変更しないでください。 たとえば、マップの複雑さやドキュメント サイズが異なると、スループットと待機時間の結果が異なる場合があります。
クリーン状態 - テストが完了したら、次のテストを実行する前に、テスト環境の状態がクリーンであることを確認します。 たとえば、履歴データは、実行時のスループットに影響を与えるデータベース内に構築できます。 サービス インスタンスをリサイクルすると、メモリ、データベース接続、スレッドなどのキャッシュされたリソースを解放するのに役立ちます。 テスト環境では、「テスト 環境で MessageBox データベースからデータを手動で消去する方法 (https://go.microsoft.com/fwlink/?LinkId=158064)」の説明に従って、bts_CleanupMsgbox ストアド プロシージャを作成して実行できます。 このスクリプトは、実行間のメッセージ ボックスに関して、BizTalk Server テスト環境を新しい状態に戻すことを目的としています。 このスクリプトでは、実行中のすべてのインスタンスとそのインスタンスに関するすべての情報 (状態、メッセージ、サブスクリプションを含む) が削除されますが、すべてのアクティブ化サブスクリプションが残されるため、オーケストレーションを再登録したり、ポートを送信したりする必要はありません。 このツールは、実稼働システムではサポートされていないことに注意してください。
パフォーマンス テストとチューニング - このテスト カテゴリの目的は、アプリケーションのパフォーマンスとスループットを最大化し、システムの最大持続可能なスループット (MST) を見つけることです。 最大の持続可能なパフォーマンスの計画と測定の詳細については、「 持続的なパフォーマンスの計画 (https://go.microsoft.com/fwlink/?LinkId=158065)」および 「持続可能なパフォーマンスとは」を 参照してください。(https://go.microsoft.com/fwlink/?LinkId=132304)。
MST は、運用環境でシステムが無期限に処理できるメッセージ トラフィックの最大負荷です。 運用環境に移行する前に、すべての BizTalk アプリケーションのパフォーマンスとスループットをテストする必要があります。 少なくとも、最も一般的な使用シナリオを表す代表的な一連のテスト ケースを実行する必要があります。 運用環境の特性に一致する別の環境で、予想される負荷とピーク時の負荷に対してテストすることをお勧めします。 この環境には、監視エージェント、ウイルス対策ソフトウェアなど、企業の標準サービスがすべてインストールされ、実行されている必要があります。
また、実行中の他の BizTalk アプリケーションと共に、運用環境の同じハードウェアで新しい BizTalk アプリケーションをテストすることをお勧めします。 これらの他の BizTalk アプリケーションでは、BizTalk Server、SQL Server、ネットワーク I/O、ディスク I/O に負荷がかかります。 さらに、1 つの BizTalk アプリケーションによって、別のアプリケーションがスロットルされる可能性があります (スプールの深さが大きすぎる場合など)。 すべての BizTalk アプリケーションは、運用環境に入る前にパフォーマンス/ストレス テストを行う必要があります。 さらに、システムがピーク時の負荷から回復するまでにかかる時間を決定する必要があります。 次のピーク負荷が発生する前にシステムがピーク負荷から完全に復旧しない場合は、問題が発生しています。 システムはさらに遅れていき、完全に回復することはできなくなるでしょう。
期待値: スループットと待機時間
デプロイされたシステムから一定のスループットや待機時間が予想されます。 高スループットと低待機時間を同時に実現しようとすると、システムに対して反対の要求が発生します。 適切な待機時間で最適なスループットを期待できます。 スループットが向上すると、システムの負荷 (CPU 消費量の増加、ディスク I/O の競合の増加、メモリの負荷、ロックの競合の増加など) が増加します。 この状況は、待機時間に悪影響を及ぼす可能性があります。 システムの最適な容量を検出するには、ボトルネックを特定して最小限にすることをお勧めします。
データベースに存在する完了したインスタンスがボトルネックの原因となる可能性があります。 ボトルネックが発生すると、パフォーマンスが低下する可能性があります。 システムにドレインに十分な時間を与えることは、問題の解決に役立ちます。 バックログのビルドアップの原因を発見し、問題の解決に役立てるのが重要です。
バックログの原因を検出するには、履歴データを分析し、パフォーマンス カウンターを監視します (使用パターンを検出し、バックログのソースを診断します)。 一般に、バックログは、大量のデータが夜間にバッチ処理される場合に発生する可能性があります。 システムの容量とバックログから回復する機能を検出すると便利な場合があります。 この情報は、オーバードライブ シナリオを処理するためのハードウェア要件と、予期しないスループットの急増を処理するためにシステム内で対応するバッファー 領域の量を見積もるのに役立ちます。
パフォーマンス カウンターの監視は、実行時に発生する可能性がある潜在的なボトルネックを解決するのに役立ちます。 ただし、CPU またはメモリのボトルネックの原因がソリューションを構成するカスタム コンポーネントの 1 つである可能性があると思われる場合は、パフォーマンス テスト中に Visual Studio Profiler や ANTS Performance Profiler などのプロファイリング ツールを使用して、問題を生成するクラスを確実に絞り込んで非アクティブ化することを強くお勧めします。 明らかに、アプリケーションのプロファイリングはパフォーマンスを妨げます。 したがって、これらのテストは、メモリ消費、CPU 使用率、または待機時間を引き起こすコンポーネントの削減に重点を置き、これらのテスト中に収集された数値を破棄する必要があります。
最適な持続可能なスループットを実現するためにシステムをチューニングするには、デプロイされたアプリケーション、システムの長所と短所、および特定のシナリオの使用パターンを深く理解する必要があります。 ボトルネックを発見し、確実に最適な持続可能なスループットを予測する唯一の方法は、運用環境で使用される内容と密接に一致するトポロジで徹底的なテストを行う方法です。 特定のユース ケースに対してロード テストとストレス テストを実行する場合、ボトルネックの原因を絞り込むには、単一の成果物 (受信場所、送信ポート、オーケストレーション) を個別のホスト インスタンスに分離し、パフォーマンス モニター ツール内に適切なカウンターを設定することが重要です。
このセクションの他のトピックでは、そのトポロジを定義するプロセスについて説明し、ボトルネックを軽減して回避する方法に関するガイダンスを提供します。
スケーリング
ボトルネックは、デプロイされたトポロジのさまざまな段階で発生する可能性があります。 一部のボトルネックは、環境のスケールアップまたはスケールアウトによって対処できます。 スケールアップは、既存のコンピューターをアップグレードするプロセスです。 たとえば、BizTalk Server コンピューターを 4 プロセッサ コンピューターから 8 プロセッサ コンピューターにアップグレードしたり、既存の CPU を置き換えて RAM を追加したりできます。 この方法では、ドキュメントの解析やマッピングなど、リソースを集中的に使用するタスクを高速化できます。 スケールアウトとは、デプロイにサーバーを追加するプロセスです。 スケールアップまたはスケールアウトの決定は、ボトルネックの種類と構成されているアプリケーションによって異なります。 スケールアップまたはスケールアウトを利用できるようにするには、アプリケーションをゼロから構築する必要があります。次のガイダンスでは、発生したボトルネックに基づいてハードウェア展開トポロジを変更する方法について説明します。
スケールアップ とは、アップグレードされたハードウェア (CPU やメモリの追加など) で BizTalk ソリューションを実行することです。 1) スケールアウトのコストが高すぎる場合、または 2) スケールアウトしてもボトルネックの解決に役立たない場合は、スケールアップを見てください。 たとえば、より高速なコンピューターでタスクを実行すると、大きなメッセージの変換と処理に費やされる時間を大幅に短縮できます。
アプリケーション プラットフォームをスケールアウトするには、BizTalk ノードを BizTalk Server グループに追加し、それらを使用してソリューションの 1 つ以上の部分を実行します。 1) 送信、受信、処理、追跡ホストを分離する必要がある場合、または 2) メモリ、I/O、またはネットワーク I/O リソースが 1 つのサーバーに対して最大になったときに、スケールアウトを確認する必要があります。 負荷は複数のサーバーに分散できます。ただし、BizTalk Server グループに新しいノードを追加すると、メッセージ ボックス データベースのロックの競合が増加する可能性があります。
では、スケールアップまたはスケールアウトする必要がありますか? プラットフォームをスケールアップすると、単一のタスク (メッセージ マッピングなど) の実行速度が速くなるため、BizTalk ソリューションの待機時間を短縮できます。 スケールアウトにより、ワークロードを複数のマシンに分散できるため、持続可能な最大のスルートプトと BizTalk ソリューションのスケーラビリティを向上させることができます。