Docs Menu
Docs Home
/ /

Descripción general del pool de conexiones

Este documento describe cómo usar un pool de conexiones para administrar las conexiones entre aplicaciones e instancias de MongoDB.

Un pool de conexiones es una caché de conexiones abiertas a bases de datos listas para usar mantenidas por la driver. Tu aplicación puede obtener conexiones del pool, realizar operaciones y devolver conexiones al pool. Los pool de conexiones son seguros para subprocesos.

Un pool de conexiones reduce la latencia de la aplicación y el número de nuevas conexiones creadas. El pool crea conexiones al iniciar, y las conexiones retornan automáticamente al pool; las aplicaciones no necesitan devolverlas manualmente. Algunas conexiones están activas y otras están disponibles. Si su aplicación solicita una conexión y hay una disponible en el pool, no es necesario crear una nueva conexión.

La mayoría de los controladores proporcionan un objeto de tipo MongoClient.

Utilice una instancia MongoClient por aplicación, a menos que la aplicación se conecte a muchos clústeres separados. Cada MongoClient instancia gestiona su propio pool de conexiones al clúster o nodo de MongoDB especificado cuando se crea el MongoClient. Los objetos MongoClient son seguros para subprocesos en la mayoría de los controladores.

Nota

Guarde su instancia de MongoClient en un lugar que esté disponible globalmente para su aplicación.

Para utilizar un pool de conexiones con LDAP, consulta Comportamiento del pool de conexiones LDAP.

mongos Los routers tienen pools de conexiones para cada nodo en el clúster. La disponibilidad de conexiones a nodos individuales dentro de un clúster fragmentado afecta la latencia. Las operaciones deben esperar a que se establezca una conexión.

Se puede especificar la configuración del pool de conexiones en estas ubicaciones:

  • El URI de MongoDB

  • La instancia MongoClient de su aplicación

  • Archivos de configuración del framework de aplicaciones

Configuración
Descripción

La mayoría de los drivers, por defecto, nunca se agotan. Algunas versiones de los drivers de Java (por ejemplo, la versión 3.7) tienen por defecto el valor 10.

Por defecto: 0 para la mayoría de los drivers. Se debe consultar la documentación sobre drivers.

Número máximo de conexiones que un pool puede establecer concurrentemente.

maxConnecting es compatible con todos los drivers excepto el driver de Rust.

Incrementar el valor de maxConnecting permite al cliente establecer la conexión con el servidor más rápidamente, pero aumenta la posibilidad de que se produzcan tormentas de conexión. Si el valor de maxConnecting es demasiado bajo, su pool de conexiones puede experimentar una fuerte limitación y un aumento de la latencia de cola para los clientes que verifican las conexiones.

Por defecto: 2

El número máximo de milisegundos que una conexión puede permanecer inactiva en el pool antes de ser eliminada y cerrada.

Por defecto: se debe consultar la documentación su driver.

Número máximo de conexiones abiertas en el grupo. Cuando el pool de conexionesalcanza el número máximo de conexiones, las nuevas conexiones esperan hasta el valor dewaitQueueTimeoutMS.

Por defecto: 100

Número mínimo de conexiones abiertas en el pool. El valor de minPoolSize debe ser menor que el valor de maxPoolSize.

Por defecto: 0

Número de milisegundos que se deben esperar antes de que se agote el tiempo de espera en una conexión TCP.

No utilices socketTimeoutMS como mecanismo para prevenir operaciones de servidor de larga duración.

Configurar tiempos de espera de socket bajos puede resultar en que las operaciones fallen antes de que el servidor responda.

Por defecto: 0, lo que significa que no hay tiempo de espera.

Tiempo máximo de espera en milisegundos que un hilo puede esperar para que una conexión esté disponible. Un valor de 0 significa que no hay ningún límite.

Por defecto: 0

Volver

Rendimiento

En esta página