Mise en commun de connexion SQL Server avec Microsoft. Data.SqlClient

Microsoft. Le pooling de connexions Data.SqlClient réutilise des connexions physiques authentifiées. SqlConnection.Open Ou OpenAsync vérifie un pool pour détecter une connexion utilisable. Close, Dispose ou DisposeAsync la réinitialise et la remet. Cette approche évite une connexion réseau, une authentification et une configuration de session pour chaque opération.

Le pooling est activé par défaut. Utilisez ce schéma d’application :

await using var connection = new SqlConnection(connectionString);
await connection.OpenAsync(cancellationToken);

using var command = new SqlCommand(sql, connection);
await command.ExecuteNonQueryAsync(cancellationToken);

Ouvrez tard, libérez tôt, et laissez le pool gérer les connexions physiques. Ne gardez pas un SqlConnection ouvert à l’échelle mondiale.

Comprendre les clés de la piscine

Une connexion ne peut être réutilisée qu’à partir du pool correspondant. La clé du pool inclut plus que le serveur de destination.

Input Comportement du pool
Chaîne de connexion Le texte doit correspondre exactement. Les différences d’ordre des mots-clés créent des pools séparés, même lorsque les paramètres effectifs sont équivalents.
Authentification intégrée Windows L’identité Windows fait partie de la clé. La même chaîne utilisée sous différentes identités crée des pools différents.
SqlCredential L’instance d’objet fait partie de la clé. Des instances séparées créent des pools distincts même lorsqu’elles contiennent le même nom d’utilisateur et mot de passe.
SqlConnection.AccessToken La valeur du jeton d’accès fait partie de la clé. Remplacer des chaînes de jetons peut créer de nouveaux pools et laisser les connexions authentifiées avec d’anciens tokens dans des pools existants.
SqlConnection.AccessTokenCallback La fonction de rappel fait partie de la clé. Réutilisez la même instance de rappel pour les connexions qui devraient partager un pool. La valeur du jeton retourné n’est pas la clé du pool.
Fournisseur de contexte SSPI personnalisé L’instance du fournisseur participe à la configuration de la connexion. Réutilisez une instance de fournisseur pour des connexions qui devraient se regrouper.
Transaction ambiante Les connexions inscrites utilisent des subdivisions propres à chaque transaction au sein du pool correspondant.

La base de données, le mode d’authentification, les options de chiffrement, le nom de l’application, les options de pooling et toutes les autres valeurs de chaîne de connexion contribuent à travers la chaîne exacte.

Construis une chaîne de connexion canonique et réutilise-la. Évitez les valeurs par requête dans Application Name, Workstation ID, ou d’autres mots-clés.

Choisissez des API de jetons qui peuvent se pooler

Pour les jetons d’accès Microsoft Entra ID, utilisez un mode d’authentification fourni par Microsoft. Data.SqlClient ou un fichier stable AccessTokenCallback.

AccessTokenCallbacka été introduit dans Microsoft. Data.SqlClient 5.2. Le pilote l’appelle lorsqu’il a besoin d’un jeton et peut demander un jeton actualisé pour un pool réutilisé. Gardez le rappel déterministe pour les paramètres d’authentification fournis par le pilote, et réutilisez la même instance de délégué.

Lorsque le code définit directement AccessToken :

  • La chaîne de jetons devient partie intégrante de la clé du pool.
  • L’application gère l’expiration et le renouvellement des jetons.
  • Une connexion physique regroupée peut survivre au jeton utilisé pour la créer.
  • On peut appeler ClearPool après avoir remplacé un jeton expiré si ce pool ne peut plus être utilisé en toute sécurité.

Ne créez pas de nouvelle lambda de rappel ni de nouvel objet d’identification pour chaque requête. Les différences d’identité d’objet peuvent fragmenter les pools.

Microsoft.Data.SqlClient 7.0 introduit SspiContextProvider pour la négociation personnalisée de Kerberos ou NTLM. Considérez le fournisseur comme une configuration de connexion à l’échelle de l’application, et non comme un état propre à chaque requête.

Taille de chaque bassin

Ces options de chaîne de connexion contrôlent un pool :

Mot clé Par défaut Effect
Pooling true Permet ou désactive le pooling.
Min Pool Size 0 Fixe le nombre minimum de connexions physiques que le pool conserve après sa création.
Max Pool Size 100 Définit le nombre maximal de connexions physiques dans le pool.
Connect Timeout 15 secondes Définit combien de temps Open il faut attendre lorsqu’aucune connexion utilisable n’est disponible.
Load Balance Timeout 0 secondes Une connexion est supprimée lorsqu’elle est renvoyée au pool si son ancienneté dépasse la valeur configurée. Connection Lifetime est un alias.

Le pool crée des connexions à mesure que la demande augmente jusqu’à atteindre Max Pool Size. Lorsque toutes les connexions sont utilisées, les ouvertures ultérieures attendent le retour d’une connexion. Si l’attente dépasse Connect Timeout, l’ouverture échoue.

Ne relancez Max Pool Size pas avant de vérifier :

  • Chaque connexion et lecteur est disposé sur tous les chemins.
  • Les commandes et transactions se terminent rapidement.
  • La charge de travail des requêtes n’est ni bloquée ni saturée.
  • La limite de connexions à la base de données peut prendre en charge Max Pool Size multiplié par chaque pool de connexions dans chaque instance d’application.

Un positif Min Pool Size permet de maintenir les connexions ouvertes pendant les périodes d’inactivité. Utilisez-le uniquement lorsque les mesures justifient des connexions chaudes. Cela fonctionne généralement contre des conceptions de cloud à l’échelle à zéro, à l’auto-pause sans serveur et aux clouds burstable.

Avec le système par Load Balance Timeout=0défaut, le nettoyage périodique supprime normalement les connexions inutilisées au-dessus Min Pool Size après environ quatre à huit minutes, ou le pool les supprime lorsqu’il détecte que la connexion serveur est coupée. Considérez cet intervalle comme un comportement d’implémentation, pas comme une garantie d’inactivité par connexion. Le pool n’envoie pas de requête de validation avant chaque checkout car ce aller-retour enlève une grande partie du bénéfice du pooling.

Gérer les périodes de blocage de l’authentification

Après un délai d’authentification ou un autre échec d’authentification, le pool peut entrer dans une période de blocage. Pendant cette période, les tentatives d’ouverture correspondantes relancent l’exception originale sans effectuer une autre tentative d’authentification.

La première période de blocage dure cinq secondes. Après un autre échec, la période double pour atteindre une minute.

Pool Blocking Period Contrôle ce comportement :

Valeur Comportement
Auto Active le blocage pour les terminaux SQL Server ordinaires et le désactive pour les suffixes Azure SQL reconnus. Un nom DNS personnalisé peut ne pas recevoir le comportement Azure.
AlwaysBlock Activez la période de blocage pour chaque terminaison.
NeverBlock Désactive la période de blocage.

Conservez Auto, sauf si la stratégie de nouvelle tentative définie pour l’application exige un autre choix. Désactiver la période de blocage peut transformer un problème d’identifiants, de pare-feu ou de panne en une tempête d’authentification.

La période de blocage est distincte de la logique de réessayage configurable. Un fournisseur de tentatives qui ouvre le même pool pendant une période de blocage reçoit l’exception mise en cache.

Gérer la durée de vie de la connexion et l'effacement

Le pool efface automatiquement le pool concerné lorsqu’il détecte une erreur fatale, comme un basculement. Le pool ferme les connexions inactives et jette les connexions empruntées à leur retour.

Utilisez les API d’effacement pour une configuration connue ou une limite d’identifiants définie :

  • ClearPool Efface le pool associé à une SqlConnection configuration.
  • ClearAllPoolsefface tous les pools Microsoft. Data.SqlClient dans le domaine du processus ou de l’application.

Le pool ferme les connexions inactives dans un pool vidé. Le pool marque les connexions actuellement utilisées pour qu’il les jette lorsqu’elles sont retournées.

Vider les pools permet aux ouvertures ultérieures d’effectuer des connexions physiques. Ne l’utilisez pas comme entretien périodique, gestionnaire d’erreurs général, ou substitut à la suppression des connexions.

Load Balance Timeout Permet un renouvellement progressif selon l’âge. Utilisez-le lorsqu’un service de déploiement ou de cluster nécessite que les anciennes connexions physiques disparaissent avec le temps. Confirmez que la valeur choisie n'entraîne pas un nombre excessif de connexions forcées.

Comprendre les transactions

Avec System.Transactions.Transaction.Current, valeur par défaut, une connexion ouverte dans Enlist=true est automatiquement inscrite dans cette transaction.

Lorsqu’une connexion associée à une transaction se ferme, le pool de connexions la place dans un sous-ensemble propre à la transaction. Une ouverture ultérieure sous la même transaction peut la réutiliser. La connexion physique ne revient au pool général qu’une fois la transaction terminée.

Les transactions implicites de longue durée ou abandonnées peuvent donc :

  • Exclure les connexions physiques du pool commun.
  • Consommez la capacité du pool après la fermeture de la connexion logique.
  • Maintenez les verrous du serveur et l’état de transaction actifs.

Gardez les transactions limitées, complétez-les explicitement, et surveillez les connexions de stase. Définissez Enlist=false seulement lorsque la connexion doit rester en dehors d’une transaction ambiante.

Prévenir la fragmentation des pools

La fragmentation des pools crée de nombreux petits pools au lieu de quelques pools réutilisables. Les causes courantes sont les suivantes :

  • Différences d’ordre de mots-clés ou d’alias dans les chaînes de connexion.
  • Une chaîne de connexion par client, utilisateur, requête ou base de données.
  • Authentification intégrée sous de nombreuses identités Windows.
  • Nouvelles instances de SqlCredential, de fonction de rappel du jeton d’accès ou de fournisseur SSPI par requête.
  • Des jetons d’accès direct qui changent à chaque rafraîchissement.
  • Noms d’applications à haute cardinalité ou identifiants de poste de travail.

Normaliser les chaînes de connexion avec SqlConnectionStringBuilder et centraliser la création de connexions.

Si l’application se connecte intentionnellement à de nombreuses bases de données ou identités, incluez le nombre de pools résultant dans la planification de la capacité. Ne lancez USE pas avec un nom de base de données non fiable pour effondrer des pools. L’isolation de la base de données, les permissions, l’état de la session et le comportement de réinitialisation du pool doivent rester explicites.

Prendre en compte les rôles des applications et l’état de la session

Le pool réinitialise l’état de session réutilisable de SQL Server avant d’assigner une connexion physique à une autre connexion logique. Le code de l’application doit toujours définir tout état de session requis dans son unité de travail.

Les rôles d'application SQL Server activés avec sp_setapprole ne peuvent pas être réinitialisés en toute sécurité pour le pooling ordinaire. Privilégiez les utilisateurs de base de données, les utilisateurs autonomes, les rôles, la sécurité au niveau des lignes ou un autre modèle d’autorisation. Si un rôle applicatif est inévitable, utilisez un motif de renversement documenté basé sur des cookies ou désactivez le pooling pour ce chemin isolé après les tests.

Éliminez les lecteurs, terminez ou annulez les transactions, et ne laissez pas les commandes tourner lorsque la connexion se ferme. Ne comptez pas sur la persistance des tables temporaires ou d’un autre état de session d’une connexion logique à l’autre.

Utilisez des modèles de pooling hébergés dans le cloud

Pour Azure App Service, Azure Functions, conteneurs, Kubernetes et autres hôtes à échelle horizontale :

  • Calculez les connexions possibles à la base de données à travers toutes les instances, processus, clés de pool et répliques.
  • Utilisez une identité gérée ou un callback stable de jeton d’accès au lieu de faire tourner des chaînes de jetons dans les objets de connexion.
  • Conserver Min Pool Size=0, sauf si une exigence mesurée en matière de démarrage à froid justifie le maintien des sessions.
  • Attendez-vous à ce qu’une nouvelle instance commence avec un pool vide.
  • Gardez les chaînes de connexion identiques entre les instances qui servent la même charge de travail.
  • Limitez les tentatives de connexion et les nouvelles tentatives afin d’éviter des pics de connexions synchronisées lors du basculement ou de la montée en charge horizontale.
  • Défini MultiSubnetFailover=true pour Azure SQL et d’autres points de terminaison TCP multi-adresses supportés.

Les pools de connexions sont locaux au processus de demande. Ils ne sont pas partagés entre instances d’application, conteneurs ou hôtes.

Diagnostiquer le comportement du pool

Utilisez les compteurs de diagnostic SqlClient pour observer :

  • Les connexions et déconnexions dures, qui représentent les connexions physiques des serveurs.
  • Les connexions et déconnexions souples, qui représentent le paiement et le retour du pool.
  • Des connexions actives et gratuites en pool.
  • Des groupes et des piscines actifs.
  • Connexions de stase.
  • Connexions récupérées lorsque le code de l’application n’a pas libéré la connexion logique.

Corrélez les compteurs clients avec les sessions SQL Server, les attentes, les blocages et les limites de ressources. Un délai d’expiration du pool peut signifier une fuite de connexion, des requêtes lentes, des transactions bloquées, une concurrence trop importante, une fragmentation du pool ou une limite de capacité de base de données.

Utilisez le traçage de source d’événement pour des traces ciblées sur le pooler. Le traçage est trop détaillé. Activez-le pour une fenêtre de diagnostic délimitée et protégez toutes les métadonnées de connexion capturées.

Liste de contrôle de production

  • Gardez le pooling activé.
  • Réutilisez une chaîne de connexion canonique par charge de travail et base de données.
  • Éliminez les connexions, commandes, lecteurs et transactions sur chaque chemin.
  • Réutilisez les instances des informations d’identification, des fonctions de rappel de jeton et des fournisseurs SSPI.
  • Définissez des délais d’expiration de connexion et des commandes non illimités.
  • Dimensionnez le budget total de connexion pour chaque instance applicative.
  • Surveillez les connexions physiques, le nombre de pools, les connexions disponibles, les blocages et les délais d’attente.
  • Effacez les pools uniquement pour un identifiant, un jeton ou une limite de configuration que le fournisseur ne peut pas détecter, ou lorsque les diagnostics confirment que des connexions obsolètes subsistent.
  • Testez sous charge la montée en charge horizontale, le basculement et le comportement d’actualisation des informations d’identification avant la mise en production.

Contenu connexe

  • Last updated on