次の方法で共有

DTA 追跡の MSTを特定するためのヒントとテクニック

  • [アーティクル]

定義上、MST とは、一定の負荷を使用してシステム パフォーマンスを再現可能な形で測定するベンチマークです。 MST を測定することは、次のような場合に特に有用です。

  1. システムからの最も短い待機時間が必要な場合。 MST を超えるとシステムでバックログが発生して、メッセージの待機時間が長くなります。 バックログは、たとえ一時的なものであっても、待機時間に直接的な悪影響を及ぼします。 したがって、システムの MST を知ることで、個々のメッセージ処理の待機時間が大幅に増加する (構成によっては秒単位から分単位に変わるなど) 前の段階で期待できる絶対的な最大スループットがわかります。

  2. 他のシステムと比較する場合。 たとえば、他のシステム (このトピックやケース スタディのシナリオ、または同じ環境内の別のシステムなど) と比べて期待した MST を達成できているかどうかを検証する場合は、一定の入力を使用して MST を測定すると、明確かつ再現可能な比較のための基準を得ることができます。

    ただし、言うまでもなく、MST の測定には時間がかかります。 したがって、その長期にわたる測定に実際に取りかかる前に、そのメリットを評価する必要があります。 ほとんどの実稼働システムは、MST で測定されるような一定の入力を受けることはありません。実際の負荷は時間の経過と共に変化します。 実稼働に先立ってシステムを保証するためには、最終的にはこのロード プロファイルをテストする必要があります。 さいわい、実稼働のロード プロファイルの持続性は、MST の測定に使用されるのと同じ手法を使用して評価できます。 BizTalkDTADb データベースのデータ保有期間を 1 つ以上含めた期間、ロード プロファイルを実行して、主要業績評価指標 (KPI) を観察します。

    テスト実行は、MST の場合もロード プロファイルの場合も、空の BizTalkDTADb データベースを使用して開始することが重要です。 BizTalkDTADb データベースに格納されているデータは時間に依存するため、テスト実行のたびに新しく取得し直さないと正しい結果が得られません。 このことが原因で、データ保有期間によっては、MST を測定するために要する時間が大幅に増加することもあります。 この問題を軽減するには、テスト実行の間に負荷を "その場で" 調整します。これにより、より短時間で MST に照準を合わせることができます。

    たとえば、最初の保有期間を過ぎたときに、スループットを上げる余地がまだあることが KPI によって示されていた場合は (ディスク アイドル時間がまだゼロになっていないなど)、徐々に負荷を増加させてその効果を観察することができます。 ただし、このようにして MST の推定値を見直した後は、空の BizTalkDTADb データベースを使用してテスト実行を開始して、その推定値を検証することが重要です。

Recommendations

BizTalk Serverの追跡システム アーキテクチャでは、さまざまな情報を追跡でき、慎重に管理および監視する必要があります。 MST によって示されるシステムのパフォーマンスに最も影響を与える要因を以下に示します。

  • システムの目的のスループット。

  • システムでメッセージおよびサービスの各インスタンスに対して追跡される情報の量。 これにより、BizTalkDTADb データベースのサイズが増加する早さが決まります。したがって、遅延を回避するためには BizTalkDTADb データベースのデータをどのくらいの頻度で削除する必要があるかも決まります。

  • BizTalkDTADb データベースのデータを保持する期間 (データ保有期間)。 この期間が長くなると BizTalkDTADb データベースが肥大化し、スループットに影響します。

  • BizTalkDTADb データベースのデータを削除するだけでなくアーカイブも行うか、BizTalkDTADb データベースのサイズを維持するために削除のみを行うか。

    BizTalk Serverで追跡するための最大の持続可能なスループットを見つけるプロセスには、次の 3 つの主要業績評価指標が含まれます。

  • DTAdb データ ファイルのディスク サブシステムの物理的なディスク アイドル時間

  • スプールの深さ

  • BizTalkDTADb データの深さ

    次の状態になるように、これら 3 つの主要業績評価指標を監視することにより、システムの MST を測定することも、実稼働プロファイルのスループットを検証することもできます。

  • 安定したスプールと trackingdata テーブルの深さ

  • ゼロに近い (ただし継続的にゼロにはならない) BizTalkDTADb データベース データ ファイルのディスクの物理的なアイドル時間

    DTA 追跡機能の使用はパフォーマンスに影響します。 既定の追跡では、実稼働環境のソリューションにとっては必要以上のデータが追跡されますが、問題解決の情報が豊富に得られるため、開発や初期のテストおよびデバッグが容易になります。 したがって、開発と初期テストの間は既定の追跡をオンのままにしておくことをお勧めします。 BizTalk に展開されたソリューションが安定し、実稼働の保証 (パフォーマンス テストなど) の準備が整ったら、実稼働環境で追跡する必要がある情報の量と BizTalkDTADb データベースに保持する必要がある期間を慎重に検討して、それに応じた調整を行うことをお勧めします。

    たとえば、否認不可または問題解決を目的としてメッセージ本文を追跡する必要がない場合は、メッセージ本文の追跡はオンにしないでください。 この点を説明するために、「 DTA 追跡の MST を測定するためのテスト シナリオ」で説明されているシナリオ例では、追跡構成のメッセージ本文追跡コンポーネントが削除されたときに、MST が 2 倍の 40 メッセージ/秒になりました。

    また、問題が発生したとしても、たいていは (必ずとは言えませんが) メッセージがメッセージ ボックス データベースに保留されているので、メッセージ本文を追跡しなくてもそれを取得して調べることができます。

    システムに加える負荷の持続性に注目します。

  • 通常の保守アクティビティが生じても、システムで実稼働のロード プロファイルを無期限に維持できるか。

  • システムでバックログが保持されるような事態 (BizTalkDTADb データベースの計画内または計画外の停止など) が発生した場合はどうなるか。

    最悪のシナリオに基づいて目標を設定し、その目標に向けてテストを行うことをお勧めします。 たとえば、定期的に行われる計画的メンテナンスのサイクルによって BizTalkDTADb データベースがオフラインになることがわかっている場合は、テスト実行の間にその停止状態をエミュレートして、結果のバックログから回復するシステムの能力を評価します。

参照

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