ボトルネックの調査
このトピックでは、ボトルネックを調査するための推奨されるプロセスについて説明します。
問題の原因は何ですか?
ボトルネックの原因は、ハードウェアまたはソフトウェアに関連している可能性があります。 リソースの使用が不足している場合、通常はボトルネックを示します。 ボトルネックは、ハードウェアの制限、非効率的なソフトウェア構成、またはその両方によって発生する可能性があります。
ボトルネックの特定では、あるボトルネックを緩和すると次のボトルネックが見つかることもまれではなく、作業を積み重ねが必要になります。 こうしたボトルネックの特定と緩和について科学的に説明することがこのトピックの目的です。 システムは、短期間なら最大限の性能を発揮できます。 しかし、スループットを維持するには、そのシステムの最も遅いコンポーネントの速度でしか処理できなくなる場合もあります。
反復的アプローチを使用したテスト
ボトルネックは、システムのエンドポイント (入退出) または中央 (オーケストレーション/データベース) で発生する可能性があります。 ボトルネックが分離されたら、構造化されたアプローチを使用してソースを特定します。 ボトルネックが緩和された後は、システムの他の場所で新しいボトルネックが発生していないことを確認するために、パフォーマンスをもう一度測定することが重要です。
ボトルネックを特定して修正するプロセスは、反復的な方法で行う必要があります。 一度に 1 つのパラメーターのみを変更し、各テストの実行中にまったく同じ手順を繰り返し、パフォーマンスを測定して、1 つの変更の影響を確認します。 一度に複数のパラメーターを変更すると、変更の効果がわからなくなってしまう可能性があります。
たとえば、パラメーター 1 を変更すると、パフォーマンスが向上する可能性があります。 ただし、パラメーター 2 をパラメーター 1 の変更と組み合わせて変更すると、悪影響を及ぼす可能性があり、パラメーター 1 を変更する利点が無効になる可能性があります。 これにより、net zero 効果が発生し、パラメーター 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 を追加したりできます。 この方法では、ドキュメントの解析やマッピングなどのリソースを集中的に使用するタスクを高速化できます。 スケールアウトは、デプロイにサーバーを追加するプロセスです。 スケールアップまたはスケールアウトの決定は、ボトルネックの種類と構成されているアプリケーションによって異なります。 スケールアップまたはスケールアウトを利用できるようにするには、アプリケーションを一から構築する必要があります。次のガイダンスでは、発生したボトルネックに基づいてハードウェア展開トポロジを変更する方法について説明します。
スケールアップ とは、アップグレードされたハードウェアで BizTalk ソリューションを実行する (CPU やメモリの追加など) ことを意味します。 1) スケールアウトのコストが高すぎる場合、または 2) スケールアウトしてもボトルネックを解決できない場合は、スケールアップを調べておく必要があります。 たとえば、より高速なコンピューターでタスクを実行すると、大きなメッセージの変換と処理に費やされる時間を大幅に短縮できます。
アプリケーション プラットフォームをスケールアウトするには、BizTalk ノードを BizTalk Server グループに追加し、それらを使用してソリューションの 1 つ以上の部分を実行します。 1) 送信、受信、処理、追跡ホストを分離する必要がある場合、または 2) メモリ、I/O、またはネットワーク I/O リソースが 1 台のサーバーに対して最大になる場合は、スケールアウトを確認する必要があります。 負荷は複数のサーバーに分散できます。ただし、BizTalk Server グループに新しいノードを追加すると、MessageBox データベースのロック競合が増加する可能性があります。
では、スケールアップまたはスケールアウトする必要がありますか? プラットフォームをスケールアップすると、1 つのタスク (メッセージ マッピングなど) の実行速度が速くなるため、BizTalk ソリューションの待機時間を短縮できます。 スケールアウトすると、複数のマシンにワークロードを分散できるため、BizTalk ソリューションの最大のサステナブルなスルートプットとスケーラビリティを向上させることができます。