エンジンの MST を測定するためのテスト シナリオ
このセクションでは、BizTalk システムを次の 3 つの負荷レベルで起動したときの効率性を測定するために実装したテスト シナリオについて説明します。
持続可能なロード テスト。 これらのテストの目的で、持続可能な負荷については、「 持続可能なパフォーマンスとは」のトピックで説明されています。
オーバードライブ ロード テスト。 オーバードライブの負荷は、MST を超える一貫した負荷として定義されます。
Floodgate ロード テスト。 フラッドゲート荷重は、MST を超える断続的な負荷ピークを伴う低負荷として定義されます。
このトピックでは、テスト ハードウェアの構成、テスト シナリオ、および各テスト結果について説明します。
重要
読者は、このセクションに含まれる情報が発行日の時点で扱われた問題に関するマイクロソフトの現在の見解を示していることに注意する必要があります。 市場の状況とテクノロジの変化に対応する必要があるため、マイクロソフトでは、発行日以降に示された情報の正確性は保証できません。
テスト システム構成
このテスト シナリオで使用するハードウェアを次に示します。
6 台の BizTalk サーバー。 それぞれデュアル 3 GHz プロセッサおよび 2 GB RAM を搭載。 各サーバーはローカル ディスクを使用しています。 2 台の BizTalk Servers に受信ホストのインスタンス、2 台に送信ホストのインスタンス、2 台にオーケストレーションの処理に使用するホストのインスタンスを構成します。
マスター MessageBox データベースと MessageBox 以外のデータベースの 1 つのSQL Server。 8 個の 2 GHz プロセッサと 4 GB RAM を搭載。 このサーバーはファイバー経由で高速 SAN ディスク サブシステムに接続されています。 メッセージの公開は無効にしてあります。
パブリッシュされるメッセージ ボックス データベース用の 3 つの SQL Server。 4 個の 2 GHz プロセッサと 4 GB RAM を搭載。 これらのサーバーは、それぞれファイバー経由で高速 SAN ディスク サブシステムに接続されています。 メッセージ ボックス データベースのデータおよびトランザクション ログ ファイルは、独立したストレージ エリア ネットワーク (SAN) に論理単位数 (LUN) として格納されています。
ドライバー クライアント コンピューターを読み込みます。 デュアル 3 GHz プロセッサおよび 2 GB RAM を搭載。 このサーバーは、BizTalk システムをテストするための負荷を生成するときに使用します。
ロード テストで使用するトポロジを次の図に示します。
ロード テストに使用するトポロジ
テスト シナリオ
テスト シナリオは非常に単純です。 負荷生成ツール LoadGen 2007 をロード ドライバー サーバーにインストールし、ファイル アダプターによって監視される共有に、ファイルのコピーを送信します。 負荷生成ツールにより、入力ファイル インスタンスのコピーがファイル共有に均等に配布されます。
Note
LoadGen をダウンロードします。 MSMQ アダプターで LoadGen を使用する方法については、「 MSMQ での LoadGen 2007 の使用」を参照してください。
BizTalk ファイル アダプターは、ファイル共有を監視してメッセージをメッセージ ボックスに公開するように構成されています。 受信図形と送信図形のみを含んでいる簡単なオーケストレーションで、公開されたメッセージをサブスクライブします。 オーケストレーションによってメッセージ ボックスに公開されたメッセージは、ファイル送信ポートで取得されて共通の共有に送信され、SAN で定義されます。 出力 SAN 共有に到着したファイルは、テストの実行中にファイルがこの共有に蓄積されるのを回避するために、直ちに削除されます。
シナリオには、受信場所、オーケストレーション、送信ポート、および追跡用にそれぞれ 1 つずつ合計 4 つのホストが定義されました。 エンジン バックログの動作を観察するために、テストの実行中は追跡をすべて無効にします。 追跡は既定でパイプラインとオーケストレーションでのみ有効になっているため、BizTalk 管理では使用するオーケストレーションとパイプラインに対して追跡を明示的に無効にします。
これらのテストでは、追跡を無効にして主要なメッセージ ボックスの動作を分離するため、追跡ホストのインスタンスは作成されません。
使用するスキーマは単純で、テストに使用したインスタンス ファイルのサイズはすべて 10 KB です。 受信ドキュメントには XMLReceive パイプラインを使用しています。テスト シナリオを単純にし、メッセージ ボックスの動作の観察に重点を置くため、マッピング コンポーネントや送信コンポーネントを使用していません。
テストで測定するパラメーター
このテストで測定するパラメーターは次のとおりです。
測定するプライマリ テスト パラメーター
以下のパラメーターは、MST を測定するときに使用するプライマリ インジケーターです。
BizTalk:MessageBox:General Counters パフォーマンス オブジェクトで使用できるスプール サイズ カウンターによって測定される MessageBox バックログ。 メッセージ ボックス バックログは持続性を示す重要なインジケーターです。 メッセージ ボックス バックログが無限に増え続けると、必ず問題が発生します。 そのため、メッセージ ボックス データベース バックログの深さを長期間監視して、持続性を評価します。
spool という名前の MessageBox テーブルには、システム内の各メッセージのレコードが含まれます (アクティブまたはガベージ コレクションを待機しています)。 このテーブル内の行数や 1 秒間に受信されるメッセージ数を監視しながら、システム負荷を増やすと簡単に維持可能な最大スループットを測定できます。 この測定値は、 スプール テーブルの深さまたはスプール の 深さとも呼ばれます。
BizTalk:Messaging パフォーマンス オブジェクトで使用できる Documents received/Sec カウンターによって測定された、1 秒あたりに受信したドキュメントの数。
測定するセカンダリ テスト パラメーター
次のパラメーターは、MST を測定するときに評価されるセカンダリ インジケーターです。 これらのパラメーターは、スプールの深さや 1 秒あたりの受信ドキュメント数というプライマリ インジケーターに影響を与える場合があります。
LogicalDisk パフォーマンス オブジェクトで使用可能な %Idle Time カウンターによって測定される、MessageBox データとトランザクション ファイル ディスクの物理ディスクのアイドル時間。
Processor パフォーマンス オブジェクトで使用できる %Processor Time カウンターによって測定される MessageBox サーバーの CPU 使用率 (%)。
SQLServer:Locks パフォーマンス オブジェクトで使用できる Lock Timeouts/sec カウンターによって測定される MessageBox データベースの 1 秒あたりのロック タイムアウト数。
削除されたメッセージに関連付けられたメッセージ ボックス テーブルをクリーンアップする SQL エージェント ジョブの直前のジョブ実行時間 (秒単位)。 これは、BizTalk:MessageBox:General Counters パフォーマンス オブジェクトで使用できる MsgBox Msg Cleanup(Purge Jobs) カウンターによって測定されます。
削除されたメッセージ部分に関連付けられたメッセージ ボックス テーブルをクリーンアップする SQL エージェント ジョブの直前のジョブ実行時間 (秒単位)。 これは、BizTalk:MessageBox:General Counters パフォーマンス オブジェクトで使用できる MsgBox パーツ クリーンアップ (消去ジョブ) カウンターによって測定されます。
維持可能な最大スループットを特定するテストを行う最には、スプール テーブルが無制限に拡大し始める時点まで入力負荷を増やします。
Note
負荷をいくら生成してもスプール テーブルが無制限に拡大しない場合、システムで最も低速な部分は処理/送信側ではなく、受信側であるということになります。