Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’applique à :
SQL ServerAzure SQL Managed Instance
Les performances d'une application Service Broker se définissent généralement par rapport à deux facteurs :
- Nombre de messages arrivant dans une période spécifiée
- Vitesse à laquelle l’application traite chaque message
Le suivi de ces deux facteurs est indispensable pour pouvoir évaluer les performances d'une application.
Service Broker fournit à cet effet un jeu de compteurs de performances qui fournit des informations sur ses activités. Service Broker enregistre également des erreurs graves dans le journal des erreurs SQL Server et dans le journal des événements de l’application Windows. Pour plus d’informations, consultez les articles suivants :
- Vues de gestion dynamique liées à Service Broker (Transact-SQL)
- SQL Server, objet Broker Statistics
- Broker, catégorie d’événement
Paramétrer une procédure stockée Service Broker
En règle générale, le réglage d’une procédure stockée qui utilise Service Broker n’est pas différent du réglage d’une autre procédure stockée. Toutefois, il existe d’autres considérations.
Tout d’abord, utilisez la WAITFOR clause. Les messages arrivent souvent à intervalles imprévisibles. Même dans un service où les messages arrivent à peu près au même rythme que la procédure stockée traite les messages, il peut arriver qu’aucun message ne soit disponible. Par conséquent, la procédure doit utiliser une WAITFOR clause avec une RECEIVE instruction ou une GET CONVERSATION GROUP instruction. Sans WAITFOR, ces instructions retournent immédiatement lorsqu’il n’existe aucun message disponible dans la file d’attente. En fonction de l'implémentation de la procédure stockée, la procédure peut ensuite effectuer une boucle dans l'instruction, consommant des ressources inutilement, ou elle peut se terminer uniquement pour être réactivée peu de temps après, ce qui consomme plus de ressources que de simplement continuer à s'exécuter.
Vous permettez la non-prévisibilité dans la synchronisation en utilisant la clause WAITFOR avec la déclaration RECEIVE ou GET CONVERSATION GROUP. Si votre application s’exécute en continu en tant que service en arrière-plan, vous ne spécifiez pas de délai d’expiration dans l’instruction WAITFOR . Si votre application est activée par Service Broker ou s’exécute en tant que travail planifié, vous spécifiez un délai d’attente court ; par exemple, 500 millisecondes. Une application qui utilise l’instruction WAITFOR gère correctement les intervalles imprévisibles entre les messages. De même, une application activée qui se termine après un court délai d’attente ne consomme pas de ressources lorsqu’il n’y a pas de messages à traiter.
Service Broker s'assure qu'une seule instance d'une application à la fois peut recevoir les messages des conversations partageant un identificateur de groupe de conversations. Concevez vos applications afin de tirer parti du verrouillage des groupes de conversations pour la synchronisation. Si votre application gère l'état, envisagez d'utiliser l'identificateur de groupe de conversations pour déterminer l'état de la conversation. Traitez plusieurs messages d'un groupe de conversations dans la même transaction. Il est cependant recommandé, en règle générale, de ne traiter que les messages d'un groupe de conversations unique dans une transaction donnée. Ceci permet de s'assurer que plusieurs instances de l'application peuvent traiter des messages, même lorsque le nombre de groupes de conversations est relativement faible.
Par ailleurs, évitez au maximum d'utiliser la rétention de messages. L'exploitation d'une table de journal distincte qui enregistre les informations les plus importantes d'un message améliore les performances. Utilisez la rétention des messages uniquement lorsque votre application requiert les messages exacts envoyés et reçus.
Mettez fin ensuite aux conversations lorsque la tâche est terminée. Service Broker gère l'état de chaque conversation active. Bien que la quantité d’état d’une conversation particulière soit petite, une application qui ne termine pas les conversations peut souffrir de performances réduites au fil du temps.
Privilégiez enfin les transactions courtes. Par exemple, si le modèle de conversation du service implique un grand nombre de messages sur le même groupe de conversations, la limitation du nombre de messages traités dans chaque transaction peut améliorer le débit global.