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
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
Las conexiones inactivas se cierran después de 20 a 25 minutos de inactividad
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 Cree una nueva conexión después de una conmutación por error
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'scluster.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"] noENTRYPOINT 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
maxConnectionPoolSizeConfigú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. Para obtener más información sobre cómo configurar los tamaños de los grupos de conexiones, consulteEstablezca maxInProcessPerConnection y maxSimultaneousUsagePerConnection con el mismo valor..
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.
