フラッドゲート ロード テスト

このトピックの情報は、「 エンジンの MST を測定するためのテスト シナリオ」で説明されているテストを参照します。

フラッドゲート イベントの原因

1 日に数個の大きなピーク ( フラッドゲート イベントとも呼ばれます) のメッセージがシステムに到着するシナリオがいくつかあります。 これらのピークの合間のスループットは非常に低くなっています。 このようなタイプのシナリオの例を次に示します。

• 証券取引で、市場の開始時や終了時など

• 銀行システムで、1 日の終わりに行われる当日取引の照合時など

  その他のタイプのイベントにより、フラッドゲート イベントに似たバックログ動作が発生する場合もあります。 たとえば、パートナーの送信アドレスがオフラインになり、そのアドレスに宛てたメッセージを再送信または保留する必要が生じた場合、バックログが蓄積されます。 パートナーがオンラインに戻ると、再送信する必要のある保留メッセージが多く蓄積されているので、別のタイプのフラッドゲート イベントが発生します。 次のシステム テストでこの動作を示します。

フラッドゲート イベントのシミュレーション

このテストでは、維持可能な最大スループットの約半分でシステムを初期駆動しました。これは非常に安定したスループットです。 次に、フラッドゲート イベントをシミュレートするために、短時間に約 410 メッセージ/秒で送信するように負荷生成ツールを構成しました (オーバードライブ テストと同様)。 1 秒間に受信したメッセージとスプールの深さを測定するロード プロファイルの結果を以下に示します。

フラッドゲート ロード テストのロード プロファイル

このグラフから、フラッドゲート イベントの発生中に、スプール テーブルに急速にバックログが蓄積されたことがわかります。 ただし、イベントの発生は比較的短時間で、その後の受信レートは維持可能な最大受信レート以下になったので、クリーンアップ ジョブを実行して、システム受信障害を引き起こさずにイベントから回復することができました。 このテストでは、メッセージ ボックスは SQL Server 2005 に格納されていました。このテストの開始から終了までの時間は約 45 分でした。

もちろん、どのシステムも違うので「走行距離は変わる」。復旧できることを確認する最善の方法は、運用環境に入る前に代表的な負荷でテストすることです。

参照

エンジンの MST を測定するためのテスト シナリオ
BizTalk Server パフォーマンス チューニングのための設定ダッシュボードの使用
オーバードライブ ロード テスト
維持可能なロード テスト