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