Pooling di connessioni SQL Server con Microsoft. Data.SqlClient

Microsoft. Il pooling di connessioni Data.SqlClient riutilizza connessioni fisiche autenticate. SqlConnection.Open Oppure OpenAsync controlla una piscina per una connessione utilizzabile. Close, Dispose, oppure DisposeAsync lo resetta e lo restituisce. Questo approccio evita una connessione di rete, l'autenticazione e l'impostazione di sessione per ogni operazione.

Il pooling è abilitato di default. Usa questo schema applicativo:

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

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

Apri fino a tardi, smalti in anticipo e lascia che la piscina gestisca le connessioni fisiche. Non tenerne uno SqlConnection aperto a livello globale.

Comprendere le chiavi della piscina

Una connessione può essere riutilizzata solo dal suo pool di corrispondenza. La chiave del pool include più del server di destinazione.

Input Comportamento del pool
Stringa di connessione Il testo deve corrispondere esattamente. Le differenze nell'ordine delle parole chiave creano pool separati, anche quando le impostazioni effettive sono equivalenti.
Autenticazione integrata di Windows L'identità di Windows fa parte della chiave. La stessa stringa usata sotto identità diverse crea pool diversi.
SqlCredential L'istanza dell'oggetto fa parte della chiave. Istanze separate creano pool separati anche quando contengono lo stesso nome utente e password.
SqlConnection.AccessToken Il valore del token di accesso fa parte della chiave. Sostituire le stringhe di token può creare nuovi pool e lasciare le connessioni autenticate con i vecchi token in pool esistenti.
SqlConnection.AccessTokenCallback Il richiamo è parte della chiave. Riutilizza la stessa istanza di callback per connessioni che dovrebbero condividere un pool. Il valore del token restituito non è la chiave del pool.
Fornitore di contesto SSPI personalizzato L'istanza provider partecipa alla configurazione della connessione. Riutilizza un'istanza di provider per connessioni che dovrebbero essere aggregate.
Transazione ambientale Le connessioni arruolate utilizzano suddivisioni specifiche per transazione all'interno del pool di corrispondenza.

Il database, la modalità di autenticazione, le opzioni di crittografia, il nome dell'applicazione, le opzioni di pooling e ogni altro valore della stringa di connessione contribuiscono attraverso la stringa esatta.

Costruisci una stringa di connessione canonica e riutilizzala. Evita i valori per richiesta in Application Name, Workstation ID, o altre parole chiave.

Scegli API di token che possano fare pool

Per i token di accesso Microsoft Entra ID, utilizza una modalità di autenticazione fornita da Microsoft. Data.SqlClient o un file stabile AccessTokenCallback.

AccessTokenCallbackè stato introdotto in Microsoft. Data.SqlClient 5.2. Il driver lo chiama quando ha bisogno di un token e può richiedere un token aggiornato per un pool riutilizzato. Mantieni il callback deterministico per i parametri di autenticazione forniti dal driver e riutilizza la stessa istanza delegata.

Quando il codice si imposta AccessToken direttamente:

  • La stringa di token diventa parte della chiave del pool.
  • L'applicazione possiede la scadenza e l'aggiornamento dei token.
  • Una connessione fisica aggregata può sopravvivere al token usato per crearla.
  • Chiama ClearPool dopo aver sostituito un token scaduto se quel pool non può più essere usato in sicurezza.

Non creare un nuovo oggetto lambda o credenziale di callback per ogni richiesta. Le differenze di identità degli oggetti possono frammentare i pool.

Microsoft. Data.SqlClient 7.0 aggiunge SspiContextProvider per negoziazione personalizzata di Kerberos o NTLM. Tratta il provider come configurazione di connessione con ambito applicativo, non come stato per richiesta.

Dimensiona ogni piscina

Queste opzioni di stringa di connessione controllano un pool:

Keyword Predefinito Effect
Pooling true Abilita o disabilita il pooling.
Min Pool Size 0 Stabilisce il numero minimo di connessioni fisiche che il pool mantiene dopo la sua creazione.
Max Pool Size 100 Imposta il numero massimo di connessioni fisiche nel pool.
Connect Timeout 15 secondi Stabilisce quanto tempo Open aspettare quando non c'è una connessione utilizzabile.
Load Balance Timeout 0 Secondi Scarta una connessione quando torna nel pool se la sua età supera il valore configurato. Connection Lifetime è un alias.

Il pool crea connessioni man mano che la domanda cresce fino a raggiungere Max Pool Size. Quando tutte le connessioni sono in uso, le aperture successive attendono il ritorno di una connessione. Se l'attesa supera Connect Timeout, l'apertura fallisce.

Non alzate Max Pool Size prima di aver controllato:

  • Ogni connessione e lettore è disposto su ogni percorso.
  • Comandi e transazioni si concludono puntualmente.
  • Il carico di lavoro delle query non è bloccato né saturo.
  • Il limite di connessione al database può essere trattato Max Pool Size moltiplicato per ogni pool in ogni istanza applicativa.

Un positivo Min Pool Size mantiene aperte le connessioni durante i periodi di inattività. Usalo solo quando le misurazioni giustificano connessioni calde. Di solito funziona contro design di cloud a scala a zero, auto-pausa serverless e cloud burstable.

Con il valore predefinito Load Balance Timeout=0, la pulizia periodica normalmente rimuove le connessioni inutilizzate sopra Min Pool Size dopo circa quattro-otto minuti, oppure il pool le rimuove quando rileva che la connessione server è interruta. Considera quell'intervallo come un comportamento di implementazione, non come una garanzia di inattività per ogni connessione. Il pool non invia una query di validazione prima di ogni checkout perché quel viaggio di andata e ritorno elimina gran parte del beneficio del pooling.

Gestire i periodi di blocco dell'autenticazione

Dopo un timeout di autenticazione o un altro fallimento dell'autenticazione, il pool può entrare in un periodo di blocco. Durante quel periodo, i tentativi aperti corrispondenti rilanciano l'eccezione originale senza effettuare un altro tentativo di autenticazione.

Il primo periodo di blocco dura cinque secondi. Dopo un altro fallimento, il periodo raddoppia fino a un minuto.

Pool Blocking Period Controlla questo comportamento:

Valore Behavior
Auto Abilita il blocco per i normali endpoint SQL Server e lo disabilita per i suffissi Azure SQL riconosciuti. Un nome DNS vanity potrebbe non ricevere il comportamento Azure.
AlwaysBlock Abilita il periodo di blocco per ogni endpoint.
NeverBlock Disabilita il periodo di blocco.

Tieni Auto a meno che il progetto di ritenti misurati dell'applicazione non richieda una scelta diversa. Disabilitare il periodo di blocco può trasformare un problema di credenziali, firewall o interruzione in una tempesta di autenticazione.

Il periodo di blocco è separato dalla logica di ritenti configurabili. Un fornitore di ritentativi che apre lo stesso pool durante un periodo di blocco riceve l'eccezione nella cache.

Gestire la durata della connessione e la cancellazione

Il pool cancella automaticamente il pool interessato quando riconosce un errore fatale, come un failover. Il pool chiude le connessioni inattive e scarta quelle già prese quando ritornano.

Usa le API di clearing per una configurazione o un confine di credenziali noto:

  • ClearPool libera il pool associato a una configurazione SqlConnection .
  • ClearAllPoolscancella ogni pool Microsoft. Data.SqlClient nel processo o nel dominio applicativo.

La piscina chiude le connessioni inattive in una piscina libera. Il pool segna le connessioni attualmente in uso, quindi le scarta quando le restituisce.

Svuotare i pool fa sì che si aprono più tardi l'accesso fisico. Non usarlo come manutenzione periodica, come gestore generale di errori o come sostituto per lo smaltimento delle connessioni.

Load Balance Timeout Fornisce un cambio graduale in base all'età. Usalo quando un servizio di distribuzione o clusterizzato necessita che le vecchie connessioni fisiche abbandonino nel tempo. Conferma che il valore scelto non causi connessioni rigide eccessive.

Transazioni

Con , il valore predefinito, una connessione aperta all'interno System.Transactions.Transaction.Current si Enlist=trueregistra automaticamente in quella transazione.

Quando una connessione arruolata si chiude, il pool la colloca in una suddivisione specifica per transazione. Un'apertura successiva con la stessa transazione può riutilizzarla. La connessione fisica non ritorna al pool generale finché la transazione non si completa.

Le transazioni ambient lunghe o abbandonate possono quindi:

  • Tieni fuori i connessioni fisiche dal pool generale.
  • Consuma la capacità del pool dopo la chiusura della connessione logica.
  • Mantieni attivi i blocchi dei server e lo stato delle transazioni.

Mantieni le transazioni limitate, completale esplicitamente e monitora le connessioni di stasi. Enlist=false impostato solo quando la connessione deve rimanere al di fuori di una transazione ambientale.

Prevenire la frammentazione del pool

La frammentazione dei pool crea molti piccoli pool invece di pochi pool riutilizzabili. Le cause più comuni includono:

  • Stringhe di connessione, ordine delle parole chiave o differenze tra alias.
  • Una stringa di connessione per ogni cliente, utente, richiesta o database.
  • Autenticazione integrata sotto molte identità Windows.
  • Nuova SqlCredential, access token callback o istanze di provider SSPI per richiesta.
  • Token di accesso diretto che cambiano ad ogni aggiornamento.
  • Nomi di applicazioni ad alta cardinalità o ID di workstation.

Normalizzare le stringhe di connessione con SqlConnectionStringBuilder e centralizzare la creazione di connessioni.

Se l'applicazione si collega intenzionalmente a molti database o identità, includere il conteggio del pool risultante nella pianificazione della capacità. Non eseguire USE un nome di database non affidabile per collassare i pool. L'isolamento del database, i permessi, lo stato della sessione e il comportamento di reset del pool devono rimanere espliciti.

Conto dei ruoli delle applicazioni e dello stato della sessione

Il pool resetta lo stato della sessione SQL Server riutilizzabile prima di assegnare una connessione fisica a un'altra connessione logica. Il codice applicativo dovrebbe comunque impostare lo stato di sessione richiesto all'interno della sua unità di lavoro.

I ruoli applicativi SQL Server attivati non sp_setapprole possono essere resettati in modo sicuro per il pool ordinario. Preferisci utenti di database, utenti contenuti, ruoli, sicurezza a livello di riga o altro design di autorizzazione. Se un ruolo applicativo è inevitabile, utilizzare un pattern di inversione documentato basato su cookie o disabilitare il pooling per quel percorso isolato dopo i test.

Elimina i lettori, completa o annulla le transazioni e non lasciare i comandi in esecuzione quando la connessione si chiude. Non affidarti a tabelle temporanee o a altri stati di sessione che sopravvivono tra connessioni logiche.

Usa modelli di pooling ospitati nel cloud

Per Servizio app di Azure, Funzioni di Azure, container, Kubernetes e altri host scalati orizzontalmente:

  • Calcola le possibili connessioni al database tra tutte le istanze, processi, chiavi di pool e repliche.
  • Usa un'identità gestita o un callback stabile di token di accesso invece di ruotare le stringhe di token negli oggetti di connessione.
  • Conserva Min Pool Size=0 a meno che un requisito misurato di partenza a freddo non giustifichi le sessioni mantenute.
  • Aspettati che una nuova istanza inizi con un pool vuoto.
  • Mantieni le stringhe di connessione identiche tra istanze che servono lo stesso carico di lavoro.
  • Binding connection tenta e ritenta per evitare raffiche di login sincronizzate durante il failover o la scale-out.
  • Impostato MultiSubnetFailover=true per Azure SQL e altri endpoint TCP multi-indirizzo supportati.

I pool di connessione sono vicini al processo di domanda. Non sono condivise tra istanze applicative, container o host.

Diagnosi del comportamento del pool

Usa i contatori diagnostici SqlClient per osservare:

  • Connessioni e disconnessioni fische, che rappresentano connessioni server fisiche.
  • Soft connect e disconnection, che rappresentano il check-out e il reso del pool.
  • Connessioni attive e libere in pool.
  • Gruppi e piscine attive.
  • Connessioni di stasi.
  • Recupero connessioni dove il codice applicativo non eliminava la connessione logica.

Correla i contatori client con sessioni SQL Server, attese, blocchi e limiti di risorse. Un timeout del pool può significare una perdita di connessione, query lente, transazioni bloccate, troppa concorrenza, frammentazione del pool o un limite di capacità del database.

Usa il tracciamento delle sorgenti eventi per le tracce mirate del pooler. Il tracciamento è prolisso. Abilitalo per una finestra diagnostica limitata e proteggi eventuali metadati di connessione catturati.

Elenco di controllo per la produzione

  • Mantieni il pooling attivato.
  • Riutilizza una stringa di connessione canonica per ogni carico di lavoro e database.
  • Elimina connessioni, comandi, lettori e transazioni su ogni percorso.
  • Riutilizza credenziali, token callback e istanze del provider SSPI.
  • Imposta timeout di connessione finita e comandi.
  • Dimensiona il budget totale di connessione per ogni istanza applicativa.
  • Monitora connessioni fische, numeri di pool, connessioni libere, stasi e timeout.
  • Libera i pool solo per una credenziale, un token o un confine di configurazione che il provider non può rilevare, o quando la diagnostica conferma che le connessioni sono obsolete.
  • Scala di carico del test, failover e comportamento di aggiornamento delle credenziali prima della produzione.

Contenuti correlati

  • Last updated on