Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Verwalten Sie Verbindungspools und den Lebenszyklus in containerisierten Umgebungen
<a name="best-practices-ecs-eks-connections"></a>

Die effektive Verwaltung von Verbindungen zu Neptune ist in containerisierten Umgebungen, in denen Container (Pods in Kubernetes) häufig gestartet, gestoppt und skaliert werden, unerlässlich. Neptune erzwingt mehrere WebSocket Verbindungslimits:
+ [Jeder Instanztyp hat eine maximale Anzahl gleichzeitiger Verbindungen WebSocket ](https://docs.aws.amazon.com/neptune/latest/userguide/limits.html#limits-websockets)
+ Verbindungen im Leerlauf werden nach 20—25 Minuten Inaktivität geschlossen
+ [Bei der IAM-Authentifizierung werden Verbindungen unabhängig von der Aktivität nach 10 Tagen zwangsweise geschlossen (siehe Verbindungslimits) WebSocket ](https://docs.aws.amazon.com/neptune/latest/userguide/limits.html#limits-websockets)

Einige Treiber unterstützen regelmäßige Keep-Alive-Heartbeats, um Verbindungsabbrüche im Leerlauf zu verhindern. Beispielsweise `keepAliveInterval` sendet der Gremlin-Java-Treiber regelmäßig einen Ping an den Server. Ermitteln Sie anhand der Konfigurationsoptionen Ihres jeweiligen Treibers, welche Keep-Alive-Einstellungen verfügbar sind und wie sie mit dem Leerlauf-Timeout von Neptune interagieren.

Wenn Sie diese Grenzen kennen, können Sie die Verbindungsverwaltung so gestalten, dass sie gut mit Container-Orchestrierungsmustern wie rollierenden Bereitstellungen, Autoscaling und Container-Recycling funktioniert. Allgemeine Hinweise zur Verbindungsverwaltung mit dem Java-Gremlin-Treiber finden Sie unter und. [Schließen des Clients zur Vermeidung des Verbindungs-Limits](best-practices-gremlin-java-close-connections.md) [Erstellen einer neuen Verbindung nach einem Failover](best-practices-gremlin-java-new-connection.md)

**Schließen Sie die Verbindungen beim Herunterfahren des Containers**

Implementieren Sie ein ordnungsgemäßes Herunterfahren, indem Sie einen `SIGTERM` Handler hinzufügen, der Ihren Graph-Client schließt, bevor der Container beendet wird. Rufen Sie zum Beispiel Gremlin Javas`cluster.close()`, Gremlins `driverRemoteConnection.close()` in Go oder Python oder Bolts `driver.close()` für den Neo4j-Treiber auf. Verwenden Sie in Kubernetes einen `preStop` Hook, um Verbindungen abzuleiten, bevor `SIGTERM` sie gesendet werden, insbesondere bei fortlaufenden Updates.

**Anmerkung**  
Docker und Amazon ECS liefern nur `SIGTERM` an PID 1 im Container. Verwenden Sie das Exec-Formular in Ihrem Dockerfile (z. B. `ENTRYPOINT ["java", "-jar", "app.jar"]` nicht`ENTRYPOINT java -jar app.jar`) oder einen Init-Prozess, `tini` um sicherzustellen, dass Ihre Anwendung das Signal empfängt.

**Verwenden Sie eine einzelne Client-Instanz pro Container**

Das Erstellen mehrerer Gremlin `DriverRemoteConnection` - oder `neo4j.Driver` Bolt-Instanzen im selben Container vervielfacht die Verbindungsnutzung. Teilen Sie eine einzelne Client-Instanz für alle Threads im Container. Die Client-Objekte sind threadsicher.

**Größe der Verbindungspools im Verhältnis zu Ihrer Flotte**

Stellen Sie `maxConnectionPoolSize` es so ein, dass die Gesamtzahl der Verbindungen in allen Containern das Verbindungslimit für Neptune-Instanzen nicht überschreitet. Wenn Sie beispielsweise 20 Container mit jeweils 8 Threads ausführen, berechnen Sie die Poolgröße pro Container so, dass das 20-fache der Poolgröße innerhalb des [Instance-Limits für Ihren Instance-Typ](https://docs.aws.amazon.com/neptune/latest/userguide/limits.html#limits-websockets) bleibt. Weitere Informationen zur Konfiguration der Verbindungspoolgrößen finden Sie unter[Setzen Sie `maxInProcessPerConnection` und `maxSimultaneousUsagePerConnection` auf den selben Wert.](best-practices-gremlin-java-maxes.md).

**Legen Sie ein Timeout für die Verbindungswartezeit fest**

Stellen Sie im Java-Gremlin-Treiber einen angemessenen Wert ein`maxWaitForConnection`, z. B. 5—10 Sekunden. Die Standardeinstellung ist oft unendlich oder sehr lang, was dazu führt, dass Threads hängen bleiben, wenn der Pool erschöpft ist, und nicht schnell mit einem eindeutigen Fehler ausfallen. Nicht alle Sprachtreiber unterstützen diese Einstellung. Die entsprechende Konfigurationsoption finden Sie in der Dokumentation Ihres Treibers.