J'adore modifier le code SQL Server pour améliorer les performances, mais il existe parfois des scénarios dans lesquels, même après avoir réglé le code, les index et la conception d'une tâche utilisateur à partir de l'application prennent plus de temps que l'expérience attendue de l'utilisateur final. Lorsque cela se produit, l'interface utilisateur doit soit attendre la fin du processus, soit proposer une autre manière de gérer la tâche. Le traitement asynchrone fourni par Service Broker convient parfaitement à bon nombre de ces scénarios et permet d'effectuer le traitement en arrière-plan de la tâche de longue durée séparément de l'interface utilisateur, ce qui permet à l'utilisateur de continuer à travailler immédiatement sans attendre que la tâche soit réellement exécutée. . Au cours de mes prochains articles, j'espère créer une série sur la façon dont vous pouvez tirer parti de Service Broker avec les explications appropriées et des exemples de code en cours de route pour faciliter l'exploitation des capacités de Service Broker sans problèmes de mise en œuvre.
Méthodes d'exécution du traitement asynchrone
Il existe plusieurs façons de gérer un processus de longue durée, mais déjà réglé. Le code de l'application peut également être réécrit pour utiliser un BackgroundWorker, le ThreadPool d'arrière-plan ou une solution basée sur un thread écrit manuellement dans .NET qui effectue l'opération de manière asynchrone. Cependant, cela permet à un nombre illimité de ces processus de longue durée d'être soumis par l'application, à moins qu'un travail de codage supplémentaire ne soit effectué pour suivre et limiter le nombre de processus actifs. Cela signifie que l'application aura un impact potentiel sur les performances, ou que la sous-charge atteindra une limite et reviendra à l'attente précédente que nous essayions d'empêcher à l'origine.
J'ai également vu ce type de processus se transformer en tâches SQL Agent liées à une table utilisée pour stocker les informations à traiter. Ensuite, le travail est soit planifié pour s'exécuter périodiquement, soit démarré par l'application à l'aide de sp_start_job lorsqu'une modification est stockée pour traitement. Cependant, cela ne permet qu'une exécution en série des processus de longue durée, car SQL Agent ne permet pas d'exécuter un travail plusieurs fois simultanément. Le travail devrait également être conçu pour gérer les scénarios dans lesquels plusieurs lignes entrent dans la table de traitement afin que le bon ordre de traitement se produise et que les soumissions suivantes soient traitées séparément.
L'utilisation de Service Broker pour le traitement asynchrone dans SQL Server résout en fait les limitations des méthodes mentionnées précédemment pour gérer le traitement asynchrone. L'implémentation du courtier permet la mise en file d'attente de nouvelles tâches pour un traitement asynchrone en arrière-plan, et permet également le traitement parallèle des tâches qui ont été mises en file d'attente jusqu'à une limite configurée. Cependant, contrairement au niveau application qui doit attendre lorsque la limite est atteinte, la solution de courtage met simplement en file d'attente le nouveau message reçu et lui permet d'être traité lorsque l'une des tâches de traitement en cours se termine - cela permet à l'application de continuer sans attendre.
Configuration d'un agent de service de base de données unique
Alors que les configurations de Service Broker peuvent devenir complexes, pour un traitement asynchrone simple, il vous suffit de connaître les concepts de base pour créer une configuration de base de données unique. Une seule configuration de base de données nécessite uniquement :
- Création de deux types de messages
- Un pour demander le traitement asynchrone
- Un pour le message de retour lorsque le traitement est terminé
- Un contrat utilisant les types de message
- Définit quel type de message est envoyé par le service initiateur et quel type de message est renvoyé par le service cible
- Une file d'attente, un service et une procédure d'activation pour la cible
- La file d'attente assure le stockage des messages envoyés au service cible par le service initiateur
- La procédure d'activation automatise le traitement des messages de la file d'attente
- Renvoie un message terminé au service initiateur lorsqu'il termine le traitement d'une tâche demandée
- Gère les types de messages système http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog et http://schemas.microsoft.com/SQL/ServiceBroker/Error
- Une file d'attente, un service et une procédure d'activation pour l'initiateur
- La file d'attente fournit le stockage des messages envoyés au service
- La procédure d'activation est facultative mais automatise le traitement des messages de la file d'attente
- Traite le message terminé vers le service cible et met fin à la conversation
- Gère les types de messages système http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog et http://schemas.microsoft.com/SQL/ServiceBroker/Error
En plus de ces composants de base, je préfère utiliser une procédure stockée wrapper pour créer une conversation et envoyer des messages entre les services de courtage afin de garder le code propre et de faciliter la mise à l'échelle si nécessaire en implémentant la réutilisation de la conversation ou l'astuce de 150 conversations expliquée dans le livre blanc de l'équipe SQLCAT. Pour de nombreuses configurations de traitement asynchrone simples, ces techniques d'optimisation des performances peuvent ne pas avoir besoin d'être implémentées. Cependant, en utilisant une procédure stockée wrapper, il devient beaucoup plus facile de modifier un seul point dans le code, au lieu de modifier chaque procédure qui envoie un message à l'avenir, si cela devenait nécessaire.
Si vous n'avez pas examiné Service Broker, il peut fournir une autre méthode pour effectuer un traitement découplé de manière asynchrone afin de résoudre un certain nombre de scénarios possibles. Dans mon prochain article, nous passerons en revue le code source d'un exemple d'implémentation et expliquerons où des modifications spécifiques devraient être apportées pour tirer parti du code pour le traitement asynchrone.
