Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Gérez les pools de connexions et le cycle de vie dans les environnements conteneurisés
La gestion efficace des connexions à Neptune est essentielle dans les environnements conteneurisés où les conteneurs (pods dans Kubernetes) démarrent, s'arrêtent et évoluent fréquemment. Neptune impose plusieurs WebSocket limites de connexion :
Chaque type d'instance dispose d'un nombre maximum de WebSocket connexions simultanées
Les connexions inactives sont fermées après 20 à 25 minutes d'inactivité
Certains pilotes prennent en charge les pulsations cardiaques continues afin d'éviter les déconnexions inactives. Par exemple, le pilote Java Gkremlin keepAliveInterval envoie un ping périodique au serveur. Consultez les options de configuration spécifiques à votre pilote pour déterminer quels paramètres de maintien en vie sont disponibles et comment ils interagissent avec le délai d'inactivité de Neptune.
La compréhension de ces limites vous permet de concevoir une gestion des connexions qui fonctionne bien avec les modèles d'orchestration des conteneurs tels que les déploiements progressifs, le dimensionnement automatique et le recyclage des conteneurs. Pour obtenir des instructions générales sur la gestion des connexions avec le pilote Java Gkremlin, reportez-vous aux sections Fermeture du client pour éviter de limiter les connexions etCréation d'une connexion après un basculement.
Fermer les connexions lors de l'arrêt du conteneur
Implémentez un arrêt progressif en ajoutant un SIGTERM gestionnaire qui ferme votre client graphique avant la sortie du conteneur. Par exemple, appelez Gemp's Javacluster.close(), Garmlin's driverRemoteConnection.close() in Go ou Python, ou Bolt driver.close() pour le pilote Neo4j. Dans Kubernetes, utilisez un preStop crochet pour vider les connexions avant SIGTERM leur envoi, en particulier lors des mises à jour continues.
Note
Docker et Amazon ECS livrent uniquement SIGTERM au PID 1 dans le conteneur. Utilisez le formulaire d'exécution dans votre Dockerfile (par exemple, ENTRYPOINT ["java", "-jar", "app.jar"] nonENTRYPOINT java -jar app.jar) ou un processus d'initialisation pour vous tini assurer que votre application reçoit le signal.
Utiliser une seule instance client par conteneur
La création de plusieurs neo4j.Driver instances de DriverRemoteConnection Gkremlin ou de Bolt dans le même conteneur multiplie l'utilisation des connexions. Partagez une instance client unique sur tous les threads du conteneur. Les objets clients sont sûrs dans un contexte multithread.
Dimensionnez les pools de connexions par rapport à votre flotte
Configurez de maxConnectionPoolSize telle sorte que le nombre total de connexions entre tous les conteneurs ne dépasse pas la limite de connexion à l'instance Neptune. Par exemple, si vous exécutez 20 conteneurs avec 8 threads chacun, calculez la taille du pool par conteneur de manière à ce que 20 × la taille du pool reste dans la limite d'instance pour votre type d'instance. Pour plus d'informations sur la configuration de la taille des pools de connexions, consultezDéfinition de maxInProcessPerConnection et maxSimultaneousUsagePerConnection sur la même valeur.
Définir un délai d'attente pour la connexion
Dans le pilote Java Gkremlin, configurez maxWaitForConnection à une valeur raisonnable, telle que 5 à 10 secondes. La valeur par défaut est souvent infinie ou très longue, ce qui entraîne le blocage des threads lorsque le pool est épuisé au lieu d'échouer rapidement avec une erreur claire. Tous les pilotes de langue ne prennent pas en charge ce paramètre. Consultez la documentation de votre pilote pour connaître l'option de configuration équivalente.
