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 ](https://docs.aws.amazon.com/neptune/latest/userguide/limits.html#limits-websockets) + Le connessioni inattive vengono chiuse dopo 20-25 minuti di inattività + [Con l'autenticazione IAM, le connessioni vengono chiuse forzatamente dopo 10 giorni indipendentemente dall'attività (vedi limiti di connessione) WebSocket ](https://docs.aws.amazon.com/neptune/latest/userguide/limits.html#limits-websockets) 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](best-practices-gremlin-java-close-connections.md) [Creazione di una nuova connessione dopo il failover](best-practices-gremlin-java-new-connection.md) **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 Java`cluster.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"]` no`ENTRYPOINT 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](https://docs.aws.amazon.com/neptune/latest/userguide/limits.html#limits-websockets). Per ulteriori informazioni sulla configurazione delle dimensioni del pool di connessioni, consulta. [Impostazione di `maxInProcessPerConnection` e `maxSimultaneousUsagePerConnection` sullo stesso valore](best-practices-gremlin-java-maxes.md) **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.