Gestion des performances (Service Broker)
Les performances d'une application Service Broker se définissent généralement par rapport à deux facteurs :
- le nombre de messages arrivant dans un laps de temps spécifié ;
- la 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 les erreurs graves dans le journal des erreurs SQL Server et le journal d'événements des applications Windows. Pour plus d'informations sur les compteurs de performances, les vues de gestion dynamique et les événements de trace pour Service Broker, consultez Analyse Service Broker.
Réglage d'une procédure stockée Service Broker
Globalement, le réglage d'une procédure stockée utilisant Service Broker et celui d'une procédure stockée classique sont similaires. Il existe toutefois quelques points supplémentaires à prendre en considération.
Il convient tout d'abord d'utiliser la clause WAITFOR. Les messages arrivent souvent à intervalles imprévisibles. Même dans un service où la fréquence d'arrivée des messages coïncide plus ou moins avec la vitesse de leur traitement par la procédure stockée, il arrive parfois qu'aucun message ne soit disponible. Ceci est la raison pour laquelle la procédure doit intégrer une clause WAITFOR dans une instruction RECEIVE ou une instruction GET CONVERSATION GROUP. Sans WAITFOR, ces instructions sont retournées immédiatement lorsqu'aucun message n'est disponible dans la file d'attente. Selon la mise en œuvre instaurée pour la procédure stockée, cette procédure peut s'exécuter en boucles par l'intermédiaire de l'instruction et consommer des ressources inutilement, ou se fermer uniquement pour se réactiver peu de temps après, ce qui consomme davantage de ressources que si elle continuait simplement de s'exécuter.
Vous palliez à ce problème de synchronisme en utilisant la clause WAITFOR avec l'instruction RECEIVE ou GET CONVERSATION GROUP. Si votre application s'exécute en continu comme service d'arrière plan, ne précisez aucun délai d'attente dans l'instruction WAITFOR. Si elle est activée par Service Broker, ou s'exécute en tant que tâche planifiée, indiquez un délai d'attente court, par exemple 500 millisecondes. Une application qui utilise l'instruction WAITFOR avec finesse arrive à gérer les intervalles imprévisibles entre les messages. De même, une application activée qui se ferme après un court délai d'attente ne consomme pas de ressource lorsqu'il n'y a aucun message à 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 de messages uniquement dans le cas où votre application nécessite les messages exacts qui ont été 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. Même si le nombre d'états pour une conversation particulière est faible, une application qui ne met pas un terme aux conversations peut, avec le temps, altérer ses performances.
Privilégiez enfin les transactions courtes. Par exemple, si la trame d'une conversation pour le service implique un nombre important de messages dans le même groupe de conversations, le fait de limiter le nombre de messages traités dans chaque transaction peut améliorer la capacité de traitement générale.
Voir aussi
Autres ressources
Conversation Group Locks
Message Retention
Rubriques relatives aux procédures de surveillance et de paramétrage des performances