パフォーマンス (Service Broker)
Service Broker アプリケーションのパフォーマンスは、通常 2 つの要素によって決まります。
指定した期間内に到着するメッセージの数
アプリケーションが各メッセージを処理する速度
この 2 つの要素を監視することが、アプリケーションのパフォーマンスを把握する手掛かりとなります。
Service Broker は、そのアクティビティに関する情報を提供するパフォーマンス カウンタのセットを備えています。また、Service Broker では、SQL Server エラー ログおよび Windows アプリケーション イベント ログに重大なエラーを記録します。パフォーマンス カウンタ、動的管理ビュー、および Service Broker のトレース イベントの詳細については、「監視 (Service Broker)」を参照してください。
Service Broker ストアド プロシージャのチューニング
Service Broker を使用するストアド プロシージャのチューニングは、ほとんどの場合、他のストアド プロシージャのチューニングと違いはありません。ただし、いくつか注意事項があります。
まず、WAITFOR 句を使用してください。メッセージが予測可能な間隔で到着することはまれです。ストアド プロシージャがメッセージを処理する速度とほぼ同じ速度でメッセージが到着するサービスでも、処理できるメッセージがなくなってしまうタイミングがあります。したがって、プロシージャでは、RECEIVE ステートメントまたは GET CONVERSATION GROUP ステートメントに WAITFOR 句を指定する必要があります。WAITFOR を指定しないと、処理できるメッセージがキュー上に存在しない場合に、これらのステートメントは即座に復帰します。ストアド プロシージャの実装によっては、プロシージャがステートメント全体の処理を繰り返して不必要にリソースを消費したり、プロシージャが終了して直後に再びアクティブ化され、単純に処理を続行するより多くのリソースを消費したりすることがあります。
RECEIVE ステートメントまたは GET CONVERSATION GROUP ステートメントに WAITFOR 句を指定すると、予測不可能なタイミングにも対応することができます。アプリケーションがバックグラウンド サービスとして連続実行される場合、WAITFOR ステートメントにタイムアウトを指定しません。アプリケーションが Service Broker からアクティブ化される場合、またはスケジュールされたジョブとして実行される場合は、500 ミリ秒など、短い時間のタイムアウトを指定します。WAITFOR ステートメントを使用するアプリケーションでは、メッセージの間隔が予測できない場合でも効率のよい処理ができます。同様に、短時間のタイムアウト後に終了するアクティブ化されたアプリケーションでは、処理するメッセージがない場合リソースを消費しません。
Service Broker では、1 つのアプリケーションで一度に 1 つのインスタンスのみが、メッセージ交換グループの識別子を共有するメッセージ交換のメッセージを受け取ることを保証しています。同期をロックするメッセージ交換グループを利用するようアプリケーションを設計してください。アプリケーションが状態を維持する場合、メッセージ交換グループの識別子を利用して、メッセージ交換の状態を識別することを検討してください。同じトランザクション内で、1 つのメッセージ交換グループの複数のメッセージを処理します。ただし、一般に、特定のトランザクション内では単一のメッセージ交換グループのメッセージのみを処理します。これによって、メッセージ交換グループの数が比較的少ない場合でも、アプリケーションの複数のインスタンスがメッセージを処理できます。
さらに、メッセージの保有期間は使用しないでください。メッセージにある最も重要な情報を保存するログ テーブルを個別に管理すると、パフォーマンスが向上します。送受信されるメッセージそのものがアプリケーションで必要なイベントにのみ、メッセージの保有期間を使用してください。
次に、タスクが完了する時点でメッセージ交換を終了してください。Service Broker では、アクティブなメッセージ交換ごとに状態を維持します。個々のメッセージ交換に関連する状態の総量がさほど大きくなくても、メッセージ交換を終了しないアプリケーションがあると、時間の経過と共にパフォーマンスが悪化する可能性があります。
最後に、常にトランザクションを短くしてください。たとえば、サービスのメッセージ交換のパターンとして、同じメッセージ交換グループでやり取りするメッセージの量が多い場合、各トランザクションで処理されるメッセージの数を制限すると、全体のスループットが向上します。