

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

# Gestione los grupos de conexiones y el ciclo de vida en entornos contenerizados
<a name="best-practices-ecs-eks-connections"></a>

Administrar las conexiones a Neptune de forma eficaz es esencial en los entornos contenerizados en los que los contenedores (pods en Kubernetes) se inician, se detienen y se escalan con frecuencia. Neptune impone varios WebSocket límites de conexión:
+ [Cada tipo de instancia tiene un número máximo de conexiones simultáneas WebSocket ](https://docs.aws.amazon.com/neptune/latest/userguide/limits.html#limits-websockets)
+ Las conexiones inactivas se cierran después de 20 a 25 minutos de inactividad
+ [Con la autenticación de IAM, las conexiones se cierran forzosamente después de 10 días, independientemente de la actividad (consulte los límites de conexión) WebSocket ](https://docs.aws.amazon.com/neptune/latest/userguide/limits.html#limits-websockets)

Algunos conductores admiten latidos cardíacos que se mantienen vivos periódicamente para evitar desconexiones al estar inactivos. Por ejemplo, el controlador Java de Gremlin `keepAliveInterval` envía un ping periódico al servidor. Consulte las opciones de configuración específicas de su controlador para determinar qué ajustes de mantenimiento están disponibles y cómo interactúan con el tiempo de espera de Neptuno por inactividad.

Comprender estos límites le ayudará a diseñar una gestión de conexiones que funcione bien con los patrones de organización de contenedores, como los despliegues sucesivos, el escalado automático y el reciclaje de contenedores. Para obtener información general sobre la administración de conexiones con el controlador Java Gremlin, consulte y. [Cierre el cliente para evitar el límite de conexiones](best-practices-gremlin-java-close-connections.md) [Cree una nueva conexión después de una conmutación por error](best-practices-gremlin-java-new-connection.md)

**Cierre las conexiones al cerrar el contenedor**

Implemente un cierre correcto añadiendo un `SIGTERM` controlador que cierre su cliente de gráficos antes de que salga el contenedor. Por ejemplo, llama a Gremlin Java's`cluster.close()`, Gremlin's en `driverRemoteConnection.close()` Go o Python o Bolt's `driver.close()` para el controlador Neo4j. En Kubernetes, usa un `preStop` gancho para drenar las conexiones antes de enviarlas, especialmente durante las actualizaciones sucesivas. `SIGTERM`

**nota**  
Docker y Amazon ECS solo realizan envíos `SIGTERM` al PID 1 del contenedor. Usa el formulario exec de tu Dockerfile (por ejemplo, `ENTRYPOINT ["java", "-jar", "app.jar"]` no`ENTRYPOINT java -jar app.jar`) o un proceso de inicio similar `tini` para asegurarte de que tu aplicación reciba la señal.

**Utilice una única instancia de cliente por contenedor**

La creación de varias `neo4j.Driver` instancias de Gremlin `DriverRemoteConnection` o Bolt en el mismo contenedor multiplica el uso de la conexión. Comparta una única instancia de cliente en todos los subprocesos del contenedor. Los objetos cliente son seguros para subprocesos.

**Dimensione los grupos de conexiones en función de su flota**

`maxConnectionPoolSize`Configúrelo de forma que el total de conexiones en todos los contenedores no supere el límite de conexiones de la instancia de Neptune. Por ejemplo, si ejecutas 20 contenedores con 8 subprocesos cada uno, calcula el tamaño del grupo por contenedor para que 20 veces el tamaño del grupo se mantenga dentro del [límite de instancias de tu tipo de instancia](https://docs.aws.amazon.com/neptune/latest/userguide/limits.html#limits-websockets). Para obtener más información sobre cómo configurar los tamaños de los grupos de conexiones, consulte[Establezca `maxInProcessPerConnection` y `maxSimultaneousUsagePerConnection` con el mismo valor.](best-practices-gremlin-java-maxes.md).

**Establezca un tiempo de espera de conexión**

En el controlador Java Gremlin, configúrelo con un valor razonable, por ejemplo, de 5 `maxWaitForConnection` a 10 segundos. El valor predeterminado suele ser infinito o muy largo, lo que provoca que los subprocesos se bloqueen cuando se agota el pool en lugar de fallar rápidamente y provocar un error evidente. No todos los controladores de idioma admiten esta configuración; consulte la documentación del controlador para ver la opción de configuración equivalente.