エンジンのパフォーマンスをテストする際の推奨事項

BizTalk エンジンのパフォーマンスをテストする際は、次のガイドラインに従ってください。

読み込み動作プロファイルを把握する 3 つのロード テストが示したように、時間の経過と同時に処理されるメッセージの観点から読み込みのプロファイルを把握することが重要です。 この点の理解を深めると、システムの容量のテストや調整をより正確に行うことができます。 ピークのスループット要件だけを把握している場合、最も保守的なアプローチは、維持できる最大のスループットがピーク時の負荷と同じかそれよりも高くなるように、システムの容量を調整することです。 ただし、負荷の最大値と最小値を予測できる場合、回復するシステムの最適化を最大値で行うことをお勧めします。これによって、全体の展開が小さく低コストになります。

パフォーマンスを早期にテスト するソリューションの機能の設計とテストに多大な労力を費やし、実稼働ハードウェアのパフォーマンスをテストするために最後の最後まで待つというトラップに陥らないようにしてください。 開発サイクルでできるだけ早く必要なロード プロファイルをシミュレートするパフォーマンス テストをシステム上で実行します。 設計またはアーキテクチャの設定を変更する必要がある場合、このことを早く把握すると、調整やテストを再度行う時間が確保されます。

パフォーマンスのテスト時に予想されるロード プロファイルをエミュレートする これには、次の 2 つの主要なコンポーネントがあります。

1. 時間の経過と共にロード プロファイルをエミュレートする。

2. 可能な限り、評価に十分な時間をかけてテストを実行する。

   一般的に使用される日次サイクルで運用している場合、持続性を検証するため、少なくとも 1 日の間パフォーマンス テストを実行する必要があります。 テスト時間が長いほど効果的です。

   運用環境の構成をエミュレートする たとえば、ポートの数と種類、ホストとホスト インスタンスの構成、データベース構成、アダプターのセットアップなどです。 構成の変更がパフォーマンスに大きな影響を与えないと仮定しないでください。

   実際のメッセージを使用 するメッセージのサイズとメッセージの複雑さはパフォーマンスに影響するため、運用環境で表示する予定のメッセージ スキーマとインスタンスを確認してテストしてください。

   パフォーマンス テスト中に通常の操作をエミュレートする ロード テストには含まれていませんでしたが、定期的なデータベース クエリ、バックアップ、消去などの標準的な操作アクティビティは、持続可能なスループットに影響するため、パフォーマンスと容量テストの実行中にこれらのタスクを実行していることを確認してください。 実稼働環境で DTA 追跡と BAM 追跡を使用する予定の場合は、それも含めます。

   MessageBox の I/O サブシステムの速度は、重要な成功要因です 実行されたロード テストでは、このビルドアウト専用の MessageBox データベース ファイル用の高速記憶域ネットワークが使用されます。この場合でも、クリーンアップ ジョブは、SQL データ ファイルのアイドル時間を 0 に近い状態に追い込むことができました。 I/O サブシステムは、運用システムのボトルネックによくなります。 SQL の I/O を最適化する一般的な方法は、可能な場合、データベース データ ファイルとログ ファイルを別々の物理ドライブに格納することです。

   SQL エージェントがすべての MessageBox サーバーで実行されていることを確認 します明らかに、SQL エージェントが実行されていない場合、クリーンアップ ジョブは実行されないため、これらのジョブが実行されていることを確認してください。

   スプールの深さは重要なインジケーターです 他のインジケーターに関係なく、このメジャーを使用すると、システムがオーバードライブされているかどうかを迅速かつ簡単に評価できます。