Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Gestisci i pool di connessioni e il ciclo di vita in ambienti containerizzati
La gestione efficace delle connessioni a Neptune è essenziale negli ambienti containerizzati in cui i container (pod in Kubernetes) si avviano, si fermano e si scalano frequentemente. Neptune impone diversi limiti di connessione: WebSocket
Ogni tipo di istanza ha un numero massimo di connessioni simultanee WebSocket
Le connessioni inattive vengono chiuse dopo 20-25 minuti di inattività
Alcuni driver supportano battiti cardiaci periodici di tipo keep-alive per evitare disconnessioni inattive. Ad esempio, il driver Java Gremlin invia un ping periodico al server. keepAliveInterval Consultate le opzioni di configurazione del vostro driver specifico per determinare quali impostazioni keep-alive sono disponibili e come interagiscono con il timeout di inattività di Neptune.
La comprensione di questi limiti aiuta a progettare una gestione delle connessioni che funzioni bene con modelli di orchestrazione dei container come le distribuzioni in sequenza, la scalabilità automatica e il riciclaggio dei contenitori. Per indicazioni generali sulla gestione delle connessioni con il driver Java Gremlin, vedere e. Chiusura del client per evitare il limite di connessioni Creazione di una nuova connessione dopo il failover
Chiudere le connessioni allo spegnimento del contenitore
Implementa uno spegnimento graduale aggiungendo un SIGTERM gestore che chiuda il client grafico prima dell'uscita del contenitore. Ad esempio, chiamate Gremlin Javacluster.close(), Gremlin's in driverRemoteConnection.close() Go o Python o Bolt's per il driver Neo4j. driver.close() In Kubernetes, usa un preStop hook per drenare le connessioni prima che vengano inviate, specialmente durante gli aggiornamenti continui. SIGTERM
Nota
Docker e Amazon ECS effettuano consegne solo SIGTERM al PID 1 nel contenitore. Usa il modulo exec nel tuo Dockerfile (ad esempio, ENTRYPOINT ["java", "-jar", "app.jar"] noENTRYPOINT java -jar app.jar) o un processo di inizializzazione per assicurarti che l'applicazione riceva tini il segnale.
Utilizza una singola istanza client per contenitore
La creazione di più neo4j.Driver istanze Gremlin DriverRemoteConnection o Bolt nello stesso contenitore moltiplica l'utilizzo della connessione. Condividi una singola istanza client tra tutti i thread del contenitore. Gli oggetti client sono thread-safe.
Dimensiona i pool di connessioni rispetto alla tua flotta
Impostato maxConnectionPoolSize in modo che le connessioni totali tra tutti i contenitori non superino il limite di connessione dell'istanza Neptune. Ad esempio, se esegui 20 contenitori con 8 thread ciascuno, calcola la dimensione del pool per contenitore in modo che 20 × la dimensione del pool rimanga entro il limite di istanza per il tipo di istanza. Per ulteriori informazioni sulla configurazione delle dimensioni del pool di connessioni, consulta. Impostazione di maxInProcessPerConnection e maxSimultaneousUsagePerConnection sullo stesso valore
Impostare un timeout di attesa per la connessione
Nel driver Java Gremlin, configuralo su un valore ragionevole, maxWaitForConnection ad esempio 5-10 secondi. L'impostazione predefinita è spesso infinita o molto lunga, il che fa sì che i thread si blocchino quando il pool è esaurito anziché fallire rapidamente con un chiaro errore. Non tutti i driver linguistici supportano questa impostazione: consulta la documentazione del driver per l'opzione di configurazione equivalente.
