次の方法で共有

DTA 追跡の MST を測定するためのテスト シナリオ

  • [アーティクル]

これらが実際にはどのように機能するのかを示すために、および追跡における維持可能な最大スループット (MST) を測定する簡単な手法を紹介するために、ここでは、追跡の MST が測定されているテスト シナリオを提供します。 関連する手法が提供されるだけでなく、示されるデータを基に他のシステムの追跡パフォーマンスを測定することもできます。

重要

読者は、このトピックに含まれる情報が発行日の時点で扱われた問題に関するマイクロソフトの現在の見解を示していることに注意する必要があります。 市場の状況とテクノロジの変化に対応する必要があるため、マイクロソフトでは、発行日以降に示された情報の正確性は保証できません。

テスト シナリオのトポロジと構成

テスト シナリオのトポロジと構成を次の図に示します。 これは、4 つの MessageBox データベース サーバー、専用の BizTalkDTADb データベース サーバー、および BizTalk Serverを実行している合計 7 台のサーバーを備えた、大きなビルド アウトです。 図に描かれている BAM サーバーは、このテスト シナリオでは使用されなかったことに注意してください。

BizTalkDTADb の維持可能なスループット

パフォーマンス トポロジの追跡 の追跡

ハードウェア仕様 (BizTalk Server)

  • CPU: デュアル 3 GHz (キャッシュ: L2: 512 KB/L3: 1 MB)

  • メモリ: 2 GB の RAM

  • HDD: 2 X 32 GB/15 K

    ハードウェア仕様 (SQL Server)

  • CPU: Quad 2 GHz (L2: 512 KB/L3: 1 MB)

  • メモリ: 4 GB の RAM

  • HDD: 2 X 32 GB/15 K + SAN

    次の図は、テスト シナリオ アーキテクチャの概要を示しており、その要素を以下に示します。

  • TP = トラック ポイント。イベントやメッセージ プロパティなど、一部の要素が追跡されるポイントです。

  • MB = メッセージ本文。メッセージ本文が追跡されるポイントです。

    次のソリューション アーキテクチャは、以下の 3 つの主な構成コンポーネントでの追跡構成を示しています。

  • 既定の DTA 追跡。 BizTalk Serverがインストールされている場合、図のすべてのイベント トラック ポイントは既定でオンになります。

  • メッセージのプロパティ。 受信パイプラインの逆アセンブラー (DA) コンポーネントに関連付けられている追跡ポイントは、受信メッセージの 10 プロパティの追跡を表しています。 追跡用にプロパティを昇格する方法の詳細については、「 プロパティの昇格」を参照してください。

  • メッセージ本文。 図中の 2 つのメッセージ本文 (MB) ポイントは、メッセージ本文を追跡するポイントを表しています。 メッセージ本文の追跡を設定する方法の詳細については、「 BizTalk 成果物の管理と追跡」を参照してください。

    テスト シナリオ アーキテクチャ

    パフォーマンス シナリオ

テスト手法

ファイル アダプターは送受信の両方で使用しました。 負荷生成ツール LoadGen 2007 を使用して、メッセージを受信ファイル共有に配信しました。 特定のレートでファイルを配信するように LoadGen ツールを構成することで、追跡 MST レベルの調査中に負荷を変更できるようにしました。 LoadGen ツールの詳細については、「 Microsoft BizTalk LoadGen 2007 ツールの使用」を参照してください。

このテストでは、BizTalkDTADb データベースでの 24 時間保持の要件を前提としました。 したがって、24 時間を経過したデータはすべてデータベースから削除されました。 アーカイブと削除を行う SQL ジョブは、アーカイブしたデータのみを削除するように設計されているので、このプロセスの間に失われるデータは一切ありません。

この要件でシステムについて十分なテストを行うには、最低でも 25 時間の負荷を実行して、アーカイブと削除のサイクルが少なくとも 1 回は含まれるようにする必要がありました。 システムが維持可能であることを確かめるために、48 時間継続で負荷を実行して最初のアーカイブ後にシステムを 24 時間監視することを選択しました。 最初の 24 時間は、定常状態のシミュレートを目的とするアーカイブ (24 時間ごと) の対象になる経過時間のデータを形成するために使われました。 次の 24 時間では、システムを監視してすべてのプロセス (たとえば、TDDS、アーカイブ、および削除) でスループットが維持できているかどうかを判断しました。

追跡動作についての理解から、持続性を判断するために監視する必要がある主要業績評価指標 (KPI) は、通常、次のごくわずかであることがわかります。

  • BizTalkDTADb データベース データ ファイルの物理ディスクアイドル時間。 物理的なディスク アイドル時間が 0 に近ければ、BizTalkDTADb データベースに追跡データの流入、アーカイブ アクティビティ、削除アクティビティのいずれかまたはすべてが浸透していることを示す望ましい状態です。

  • trackingdata テーブルの深さ。 trackingdata テーブルが単調拡大を始めた場合、つまり、無制限に大きくなり続ける場合は、現在のスループット レートでは、TDDS で BizTalkDTADb データベースにデータを持続可能な速さで挿入できないことを明示しています。

  • スプールの深さ。 スプールの増大につながる可能性のある要因はいくつかあります。 スプールの増大を招く可能性のある状況の 1 つは、追跡メッセージの本文をメッセージ ボックス データベースから BizTalkDTADb データベースにコピーする SQL ジョブが遅延している場合です。 追跡する必要があるメッセージは、BizTalkDTADb データベースに正常にコピーされるまでメッセージ ボックス データベースから削除する (メッセージ ボックスのクリーンアップ ジョブによる) ことができないので、コピー ジョブが遅延すると、スプールの増大を招くことになります。

    ほとんどのシステムでは、負荷状況下でこの 3 つの業績評価指標のみを監視すれば、負荷が維持可能かどうかを判断する十分な情報を得られます。

    維持可能な負荷状況下での主要業績評価指標

    Tracking データベース Perf_Monitor_Tracking_dbのパフォーマンス監視

    サンプル シナリオを使用して毎秒 20 メッセージが受信される負荷の下で、生成されたパフォーマンス グラフに示されているように、48 時間分の主要業績評価指標を得ました。 このグラフから、持続性を示す以下の傾向がわかります。

  • BizTalkDTADbdata の深さ (黒い線)。 3 つの公開メッセージ ボックス データベースでは、24 時間の時点での最初のアーカイブの後も、trackingdata テーブルの深さは安定し、上昇傾向が続いていないことがわかります。

  • スプールの深さ (青い線) スプールの深さはこの実行をとおしてとても安定しており、アーカイブと削除によりリソースが使用されていても、追跡メッセージ (各メッセージのサイズは 10 KB) が BizTalkDTADb データベースに遅延することなくコピーされていることが示されています。

  • BizTalkDTADb データベース データ ファイル 物理ディスクアイドル時間 (赤い線) 最初の 24 時間は、アーカイブと削除が実行されることはなく、BizTalkDTADb データベースにデータが蓄積されるにつれて TDDS によるデータの挿入などディスク I/O が増加します。 これは、物理的なディスク アイドル時間の安定した低下としてはっきりと示されています。

    実行から 24 時間が経過すると、I/O アイドル時間の明確な低下が観察されます。これは、アーカイブと消去で行う作業が初めて行われる時刻と一致します。 最初のアーカイブの後、消去は 24 時間より前のデータを消去するために 1 分ごとに実行する作業を行います (システムにはまだ負荷が存在することを覚えておいてください)。その結果、アイドル時間がほぼゼロになります。

    ここで重要な点は、最初のアーカイブが行われた後、つまり、システムが最初の "ライブ BizTalkDTADb データベース データ保有期間" ウィンドウを通過した後、システムが MST またはその近くにあるときにディスクアイドル時間が非常にゼロに近いということです。 これは、BizTalkDTADb データベースのボトルネックが、ほとんどの場合ディスク I/O サブシステムの速度であるためです。

    システムのベースラインとして追跡を無効にして MST を測定することは、多くの場合で有益です。 このテストでの例として、追跡をすべて無効にした状態での MST は毎秒 290 メッセージで、これは上記の機能や DTA データ保有期間で追跡を有効にしたシステムの MST の何倍にもなります。 このことから、追跡を有効にしたシステムは、あまり活用されていないことがわかります。 つまり、毎秒 20 メッセージの MST の追跡のサポートだけが必要な場合は、毎秒 290 メッセージの処理が可能なシステムを構築する必要はありません。言い換えれば、BizTalkDTADb データベースのハードウェアを変更しない場合は、毎秒 20 メッセージのスループットを実現するのに必要とされる BizTalk データベース サーバーとメッセージ ボックス データベース サーバーの数は、このシナリオのものよりはるかに少ないと考えられます。

維持可能な最大スループットの調査

これで、MST で実行されているシステムの KPI がどのようなものであるかがわかったので、サンプル シナリオの毎秒 20 メッセージ の MST に至った過程を確認して検討しましょう。 その過程は単純な繰り返しで、以下に示すような "バイナリ サーチ" アプローチです。

  • 開始点を選択します。 BizTalk Serverでのパフォーマンス テストの経験がない限り、他のシステムで達成された内容に関する情報を自分で利用する必要があります。

    たとえば、このトピックのサンプル シナリオのハードウェア、構成、ソリューションについてのアーキテクチャはすべて提供してきました。 そのアーキテクチャと有効にした追跡の種類 (既定 + 10 プロパティ + 10 KB のメッセージ本文) や 24 時間の DTA データ保有期間で得られた MST (毎秒20 メッセージ) を使用して、アーキテクチャとセットアップや要件を比較します。

    少なくとも、ソリューションの MST が、このテストで得られた値より高くなるか低くなるかを見積もる必要があります。 さまざまな技術的なケース スタディを使用して、システムを比較することもできます。

  • 推定 MST 負荷の下でシステムを実行し、KPI を監視します。 通常、推定 MST の高い側から開始することで、MST を見つけるためにかかる時間を短縮できます。 高い値からの開始により、MST を下回っていることがわかるのにかかる時間 (つまり、少なくとも 1 つのデータ保有期間の満了) よりも早く KPI が飽和状態 (特に ディスク I/O) に達します。

  • MST 推定と繰り返しを調整します。 テストの実行結果を見て、MST の推定値を調整し、新しい推定値で再度テストします。

参照

維持できる最大の追跡スループットの測定
DTA 追跡のパフォーマンス特性について
DTA 追跡の MST を特定するためのヒントとテクニック
追跡データベースのサイズに関するガイドライン