Planification des notifications
Pour utiliser efficacement les notifications de requêtes, vous devez déterminer si votre application peut tirer parti des notifications de requêtes et si les requêtes que votre application utilise prennent en charge les notifications. Il vous faudra ensuite définir la stratégie que votre application suivra pour s'abonner aux notifications ou en recevoir.
Les notifications de requêtes constituent un moyen efficace de réduire les va-et-vient vers la base de données si les données de la requête changent relativement peu souvent, si l'application ne demande pas une mise à jour instantanée en cas de modification des données et si la requête répond aux exigences et aux limites présentées dans Création d'une requête pour notification. Bien des applications Web répondent à ces critères et peuvent donc tirer parti des notifications de requêtes.
Les scénarios ne profitent pas tous des notifications de requêtes. Les notifications de requêtes sont utiles lorsqu'une application lit fréquemment les données de la base de données, mais que les mises à jour des données sont plutôt rares. Par exemple, un catalogue en ligne sera consulté plus fréquemment qu'il ne sera mis à jour. En revanche, pour un panier d'achat en ligne, le contenu d'un panier particulier pourra être mis à jour assez souvent et, dans ce cas, les notifications de requêtes n'apportent pas autant d'avantages.
Les notifications de requêtes sont plus efficaces lorsqu'une application émet des requêtes qui partagent une structure commune et ne se distinguent que par les valeurs des paramètres. Par exemple :
SELECT ProductNumber, Name FROM Production.Product WHERE ListPrice < 300
SELECT ProductNumber, Name FROM Production.Product WHERE ListPrice < 500
Dans ce cas, les abonnements aux notifications de requêtes partagent le même modèle interne pour les deux notifications ; la charge placée sur SQL Server est donc moindre que s'il s'agissait de deux notifications avec une structure de requête différente. Sachez, toutefois, que les paramètres des requêtes sont conservés. Bien que les requêtes partagent un modèle, l'ajout d'un élément à un ListPrice de 350 engendre une notification sur la deuxième requête, mais pas sur la première.
Lorsque les notifications de requêtes sont actives sur une table, les mises à jour apportées à la table sont plus coûteuses. Le Moteur de base de données réalise un travail supplémentaire pour vérifier les abonnements et, le cas échéant, générer des notifications. En réutilisant les modèles internes, il est possible de diminuer la charge par abonnement. Veillez par conséquent à n'activer les notifications de requêtes que pour les applications soumettant des requêtes de structure similaire. Une application qui soumet des requêtes de structure différente ne doit pas faire appel aux notifications de requêtes.
Par exemple, une application qui affiche les articles d'un catalogue, classés par gamme de prix, soumet des requêtes de même structure. Dans ce cas, le Moteur de base de données peut réutiliser le modèle interne pour chaque requête, et les notifications de requêtes permettent d'optimiser les performances. En revanche, une application qui permet la création d'un état à la demande soumet des requêtes de structure variable. Mieux vaut, dans ce cas, ne pas recourir aux notifications de requêtes.
Le Moteur de base de données conserve un modèle interne aussi longtemps qu'il est utilisé par un abonnement enregistré au minimum. Le Moteur de base de données limite le nombre de modèles internes différents sur une table particulière. Une fois cette limite atteinte, le Moteur de base de données n'enregistre plus les abonnements susceptibles d'engendrer la création d'un modèle. En revanche, le Moteur de base de données génère immédiatement un message indiquant que l'abonnement n'a pas pu être enregistré.
Planification d'une stratégie efficace de notifications de requêtes
Les notifications de requêtes fonctionnent généralement très bien lorsque le nombre total de notifications est faible à modéré, et lorsque l'application ne nécessite pas de notifications immédiates en cas de modifications des données. Le scénario typique d'invalidation de cache Web répond à ce modèle et convient généralement bien à l'utilisation de notifications de requêtes. Les notifications de requêtes peuvent ne pas convenir à certaines applications, notamment lorsque les notifications doivent être reçues avec un temps de réponse inférieur à une seconde, lorsque l'infrastructure réseau n'est pas à la fois rapide et fiable, ou lorsque le nombre de notifications est très important.
Lorsque vous utilisez des notifications de requêtes, testez et ajustez votre application à l'échelle et à l'environnement dans lesquels elle fonctionnera une fois déployée. Envisagez un scénario d'usage avec la plus importante charge prévue et prévoyez des rafales d'activité importante s'il s'agit d'une éventualité.
Si vous avez besoin de notifications de requêtes fiables avec un temps de réponse inférieur à une seconde, les techniques à utiliser sont les mêmes que celles utilisées pour la création d'une application OLTP hautes performances.
Assurez-vous que votre application ne maintient pas de verrous pour une durée supérieure à une fraction de seconde. Par exemple, n'exécutez pas de transactions multi-instructions à partir d'un client appartenant à un réseau dont les performances sont peu fiables.
Identifiez et éliminez les zones réactives dans vos tables de données utilisateur.
Les tables internes de notifications de requêtes sont souvent analysées de façon séquentielle pour chaque mise à jour d'une table utilisateur associée, pour laquelle vous avez défini des notifications de requêtes. Si le verrou de niveau table maintenu sur la table interne de notifications de requêtes peut créer un goulot d'étranglement, envisagez de partitionner la table utilisateur de notifications de requêtes en plusieurs tables séparées, afin de réduire le nombre de notifications devant être évaluées à chaque modification de données.
Si vos requêtes de notification possèdent une durée de vie courte et utile, envisagez d'utiliser un délai d'expiration avec le constructeur SqlDependency qui soit largement inférieur à la valeur par défaut de 5 jours (par exemple, une minute). Cela peut réduire grandement le nombre de lignes dans les tables internes de notifications de requêtes. Ceci, peut, à son tour, réduire le temps nécessaire au traitement de ces tables, ainsi que la contention de verrouillage.
Solutions alternatives aux notifications de requêtes
Si vous avez besoin d'un temps de réponse rapide et hautement prédictible pour les notifications de modification de données dans un environnement où les taux de mise à jour de données sont élevés et les notifications de requêtes en attente de traitement nombreuses, envisagez d'autres solutions, telles que les suivantes :
Créez un déclencheur AFTER UPDATE dans la table actuellement surveillée, utilisant SQL Server Service Broker pour envoyer un message à l'entité qui nécessite la notification. À cette fin, vous pouvez, par exemple, ajouter une colonne à la table que vous souhaitez, avec une indication de l'entité devant recevoir la notification de modification, ou bien joindre la table primaire à la deuxième table contenant les informations sur l'entité qui nécessite la notification.
Utilisez une solution de couche Application personnalisée ne nécessitant pas de notifications de requêtes. Par exemple, configurez une notification de manière à ce qu'elle provienne entièrement d'une application intergicielle (middleware) qui conserve les données actuellement surveillées dans une collection d'objets de mémoire principale. Votre application peut générer une notification lorsqu'un objet est modifié d'une façon qui réponde à vos critères de notification.
Utilisez le cache Windows Server AppFabric, qui prend en charge un système de notifications de modifications, à l'aide d'un cache d'objets en mémoire et de fonctions de rappel que vous inscrivez auprès des objets.