Agrupación de conexiones de SQL Server con Microsoft.Data.SqlClient

La agrupación de conexiones de Microsoft.Data.SqlClient reutiliza conexiones físicas autenticadas. SqlConnection.Open O OpenAsync revisa una piscina para ver si hay una conexión utilizable. Close, Dispose, o DisposeAsync reinicia y lo devuelve. Este enfoque evita una conexión de red, autenticación y configuración de sesión para cada operación.

El pooling está activado por defecto. Utiliza este patrón de aplicación:

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

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

Abre hasta tarde, deshazte con antelación y deja que la piscina gestione las conexiones físicas. No dejes uno SqlConnection abierto a nivel global.

Entiende las claves de la piscina

Una conexión solo puede reutilizarse desde su grupo correspondiente. La clave del pool incluye más que el servidor de destino.

La base de datos, el modo de autenticación, las opciones de cifrado, el nombre de la aplicación, las opciones de agrupación y todos los demás valores de cadena de conexión contribuyen a través de la misma cadena.

Crea una cadena de conexión canónica y reutilízala. Evita valores por solicitud en Application Name, Workstation ID, u otras palabras clave.

Elige APIs de token que puedan agruparse

Para los tokens de acceso de Microsoft Entra ID, utilice un modo de autenticación proporcionado por Microsoft.Data.SqlClient o una versión estable AccessTokenCallback.

AccessTokenCallbackfue introducido en Microsoft. Data.SqlClient 5.2. El controlador lo invoca cuando necesita un token y puede solicitar un token renovado para un pool reutilizado. Mantén la callback determinista para los parámetros de autenticación que proporciona el controlador y reutiliza la misma instancia delegada.

Cuando el código asigna AccessToken directamente:

• La cadena de tokens pasa a formar parte de la clave del pool.
• La aplicación es responsable de la expiración y actualización del token.
• Una conexión física agrupada puede sobrevivir al token utilizado para crearla.
• Invoca ClearPool después de reemplazar un token caducado si ese grupo ya no puede seguir utilizándose de forma segura.

No crees un nuevo objeto lambda de callback o credencial para cada solicitud. Las diferencias de identidad de objetos pueden fragmentar los pools.

Microsoft.Data.SqlClient 7.0 añade SspiContextProvider para la negociación personalizada de Kerberos o NTLM. Trata al proveedor como una configuración de conexión de ámbito de aplicación, no como estado por petición.

Dimensionar cada pool

Estas opciones de cadena de conexión controlan un pool:

El pool crea conexiones a medida que la demanda crece hasta alcanzar Max Pool Size. Cuando todas las conexiones están en uso, las aperturas posteriores esperan a que una conexión regrese. Si la espera supera Connect Timeout, la apertura falla.

No subas Max Pool Size antes de comprobar:

• Cada conexión y lector se liberan en todas las rutas de ejecución.
• Los comandos y transacciones terminan rápidamente.
• La carga de trabajo de las consultas no está bloqueada ni saturada.
• El límite de conexiones a la base de datos puede gestionar Max Pool Size multiplicado por cada pool de cada instancia de la aplicación.

Un positivo Min Pool Size mantiene las conexiones abiertas durante los periodos de inactividad. Úsalo solo cuando las mediciones justifiquen conexiones cálidas. Normalmente va en contra de las arquitecturas con escalado a cero, la pausa automática en entornos serverless y las arquitecturas cloud con capacidad de ráfaga.

Con el valor predeterminado de Load Balance Timeout=0, la limpieza periódica normalmente elimina las conexiones no utilizadas por encima de Min Pool Size al cabo de entre cuatro y ocho minutos aproximadamente, o el pool las elimina cuando detecta que la conexión con el servidor se ha interrumpido. Trata ese intervalo como un comportamiento de implementación, no como una garantía de inactividad por conexión. El pool no envía una consulta de validación antes de cada checkout porque ese viaje de ida y vuelta elimina gran parte del beneficio del pooling.

Gestionar los periodos de bloqueo de autenticación

Tras un tiempo de espera de autenticación u otro fallo de autenticación, el pool puede entrar en un periodo de bloqueo. Durante ese periodo, los intentos abiertos coincidentes relanzan la excepción original sin realizar otro intento de autenticación.

El primer periodo de bloqueo dura cinco segundos. Tras otro fallo, el periodo se duplica hasta un minuto.

Pool Blocking Period Controla este comportamiento:

Mantenlo Auto a menos que el diseño de reintentos medidos de la aplicación requiera una elección diferente. Desactivar el periodo de bloqueo puede convertir un problema de credencial, cortafuegos o interrupciones en una tormenta de autenticación.

El periodo de bloqueo es independiente de la lógica de reintentos configurable. Un proveedor de reintentos que abre el mismo grupo durante un periodo de bloqueo recibe la excepción almacenada en caché.

Gestionar la vida útil y el borrado de la conexión

El pool elimina automáticamente el pool afectado cuando detecta un error fatal, como un failover. La piscina cierra las conexiones inactivas y descarta las conexiones prestadas cuando regresan.

Utiliza las APIs de limpieza para una configuración o límite de credenciales conocida:

• ClearPool limpia el pool asociado a una SqlConnection configuración.
• ClearAllPoolsBorra todos los pools de Microsoft. Data.SqlClient en el dominio del proceso o aplicación.

La piscina cierra las conexiones inactivas en una piscina despejada. El pool marca las conexiones que están en uso actualmente para que las descarte cuando las devuelve.

Borrar los grupos provoca que las aperturas posteriores requieran inicios de sesión físicos. No lo uses como mantenimiento periódico, como controlador general de errores ni como sustituto de la liberación de conexiones.

Load Balance Timeout proporciona una rotación gradual basada en la edad. Úsalo cuando un servicio de despliegue o en clúster necesite que las conexiones físicas antiguas se abandonen con el tiempo. Confirma que el valor elegido no cause conexiones duras excesivas.

Descripción de las transacciones

Con System.Transactions.Transaction.Current, el valor predeterminado, una conexión abierta dentro de Enlist=true se incorpora automáticamente a esa transacción.

Cuando se cierra una conexión asociada, el grupo de conexiones la coloca en una subdivisión específica de la transacción. Una apertura posterior bajo la misma transacción puede reutilizarla. La conexión física no vuelve al pool general hasta que la transacción se completa.

Por tanto, las transacciones de entorno prolongadas o abandonadas pueden:

• Mantén las conexiones físicas fuera del conjunto general.
• Consume la capacidad del pool después de que se cierre la conexión lógica.
• Mantén activos los bloqueos del servidor y el estado de la transacción.

Mantén las transacciones limitadas, complétalas explícitamente y supervisa las conexiones inactivas. Configura Enlist=false solo cuando la conexión debe permanecer fuera de una transacción ambiental.

Prevenir la fragmentación de la piscina

La fragmentación de las piscinas crea muchas piscinas pequeñas en lugar de unas pocas reutilizables. Entre las causas comunes se incluyen las siguientes:

• Diferencias de orden o alias de palabras clave en la cadena de conexión.
• Una cadena de conexión por cliente, usuario, solicitud o base de datos.
• Autenticación integrada bajo muchas identidades de Windows.
• Nuevo SqlCredential, acceso a la llamada de token o instancias de proveedor SSPI por solicitud.
• Tokens de acceso directo que cambian en cada actualización.
• Nombres de aplicaciones de alta cardinalidad o identificadores de estaciones de trabajo.

Normalizar cadenas de conexión con SqlConnectionStringBuilder y centralizar la creación de conexiones.

Si la aplicación se conecta intencionadamente a muchas bases de datos o identidades, incluye el número resultante de pools en la planificación de la capacidad. No ejecutes USE con un nombre de base de datos no confiable para colapsar pools. El aislamiento de la base de datos, los permisos, el estado de la sesión y el comportamiento de reinicio de pool deben permanecer explícitos.

Ten en cuenta los roles de la aplicación y el estado de la sesión

El pool reinicia el estado reutilizable de la sesión de SQL Server antes de asignar una conexión física a otra conexión lógica. El código de la aplicación debe seguir estableciendo cualquier estado de sesión requerido dentro de su unidad de trabajo.

Los roles de aplicación de SQL Server activados con sp_setapprole no pueden restablecerse de forma segura para la agrupación ordinaria de conexiones. Use preferentemente usuarios de base de datos, usuarios contenidos, roles, seguridad de nivel de fila u otro modelo de autorización. Si un rol de la aplicación es inevitable, utiliza un patrón documentado de reversión basado en cookies o desactiva la agrupación para esa ruta aislada después de realizar pruebas.

Cierra los lectores de datos, finaliza o revierte las transacciones y no dejes comandos en ejecución cuando se cierre la conexión. No dependas de tablas temporales u otros estados de sesión que sobrevivan a través de conexiones lógicas.

Utiliza patrones de pooling alojados en la nube

Para Azure App Service, Azure Functions, containers, Kubernetes y otros hosts horizontalmente escalados:

• Calcula las posibles conexiones a bases de datos en todas las instancias, procesos, claves de pool y réplicas.
• Utiliza identidad gestionada o un callback de token de acceso estable en lugar de rotar cadenas de token en los objetos de conexión.
• Mantén Min Pool Size=0 a menos que un requisito medido de inicio en frío justifique sesiones persistentes.
• Espera que una nueva instancia empiece con un pool vacío.
• Mantén las cadenas de conexión idénticas entre instancias que sirvan para la misma carga de trabajo.
• Limite los intentos de conexión y los reintentos para evitar ráfagas sincronizadas de inicios de sesión durante la conmutación por error o el escalado horizontal.
• Establezca MultiSubnetFailover=true para Azure SQL y otros puntos de conexión TCP de varias direcciones compatibles.

Los grupos de conexiones son locales al proceso de la aplicación. No se comparten entre instancias de aplicación, contenedores o hosts.

Diagnosticar el comportamiento del pool

Utiliza contadores de diagnóstico SqlClient para observar:

• Conexiones y desconexiones directas, que representan conexiones físicas del servidor.
• Conexiones suaves y desconexiones, que representan la salida y devolución del pool.
• Conexiones agrupadas activas y libres.
• Grupos activos en la piscina y piscinas.
• Conexiones de estasis.
• Recuperé conexiones donde el código de la aplicación no eliminó la conexión lógica.

Correlaciona los contadores de cliente con las sesiones de SQL Server, las esperas, los bloqueos y los límites de recursos. Un tiempo de espera en el pool puede significar una fuga de conexión, consultas lentas, transacciones bloqueadas, demasiada concurrencia, fragmentación del pool o un límite de capacidad de base de datos.

Utiliza el rastreo de fuentes de eventos para rastreos dirigidos al pooler. El trazado es detallado. Habilita la opción para una ventana de diagnóstico limitada y protege cualquier metadato de conexión capturado.

Lista de comprobación de envío

• Mantén el pooling activado.
• Usa una cadena de conexión canónica para cada carga de trabajo y base de datos.
• Elimina conexiones, comandos, lectores y transacciones en todas las rutas.
• Reutiliza credenciales, devolución de token y instancias de proveedor SSPI.
• Establece límites finitos de conexión y tiempos de espera.
• Ajusta el presupuesto total de conexión para cada instancia de aplicación.
• Controla las conexiones directas, el número de pools, las conexiones libres, la estasis y los tiempos de espera.
• Vacía los grupos solo cuando se trate de un cambio de credencial, token o configuración que el proveedor no pueda detectar por sí mismo, o cuando los diagnósticos confirmen que siguen existiendo conexiones obsoletas.
• Pruebe mediante pruebas de carga el escalado horizontal, la conmutación por error y el comportamiento de la actualización de credenciales antes de pasar a producción.

Contenido relacionado

• Conectarse a un origen de datos
• Cadenas de conexión
• Opciones de conexión.
• Contadores de diagnóstico SqlClient
• Lógica de reintento configurable
• Autenticación de Microsoft Entra ID