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.
# Empfehlungen für die Verwendung AWS Lambda mit Amazon Neptune Gremlin
Wir empfehlen jetzt, für die gesamte Lebensdauer eines Lambda-Ausführungskontextes eine einzige Verbindungs- und Graph-Traversal-Quelle zu verwenden, anstatt einer für jeden Funktionsaufruf (jeder Funktionsaufruf verarbeitet nur eine Client-Anfrage). Da gleichzeitige Client-Anfragen von verschiedenen Funktions-Instances verarbeitet werden, die in separaten Ausführungskontexten ausgeführt werden, ist es nicht erforderlich, einen Pool von Verbindungen aufrechtzuerhalten, um gleichzeitige Anfragen innerhalb einer Funktions-Instance zu verarbeiten. Wenn der Gremlin-Treiber, den Sie verwenden, über einen Verbindungspool verfügt, konfigurieren Sie ihn so, dass er nur eine Verbindung verwendet.
Verwenden Sie bei jeder Abfrage eine Wiederholungslogik, um mit Verbindungsfehlern umzugehen. Obwohl das Ziel darin besteht, eine einzige Verbindung für die gesamte Lebensdauer eines Ausführungskontextes aufrechtzuerhalten, können unerwartete Netzwerkereignisse dazu führen, dass diese Verbindung abrupt beendet wird. Solche Verbindungsfehler äußern sich je nach verwendetem Treiber als unterschiedliche Fehler. Sie sollten Ihre Lambda-Funktion so programmieren, dass sie diese Verbindungsprobleme behebt und bei Bedarf versucht, die Verbindung wiederherzustellen.
Einige Gremlin-Treiber kümmern sich automatisch um erneute Verbindungen. Der Java-Treiber versucht beispielsweise automatisch, die Konnektivität zu Neptune für Ihren Client-Code wiederherzustellen. Mit diesem Treiber muss Ihr Funktionscode nur zurückgezogen werden und die Abfrage erneut versuchen. Die Python-Treiber JavaScript und die Python-Treiber implementieren dagegen keine automatische Wiederverbindungslogik. Daher muss Ihr Funktionscode bei diesen Treibern versuchen, die Verbindung nach dem Zurückziehen erneut herzustellen, und die Abfrage erst wiederholen, wenn die Verbindung wieder hergestellt wurde.
Die Codebeispiele hier beinhalten Logik zur Wiederherstellung einer Verbindung, anstatt davon auszugehen, dass der Client dies übernimmt.
# Empfehlungen für die Verwendung von Gremlin-Schreibanforderungen in Lambda
Wenn Ihre Lambda-Funktion Grafikdaten ändert, sollten Sie eine back-off-and-retry Strategie zur Behandlung der folgenden Ausnahmen in Betracht ziehen:
+ **`ConcurrentModificationException`** – Die Neptune-Transaktionssemantik bedeutet, dass Schreibanforderungen manchmal mit einer `ConcurrentModificationException` fehlschlagen. Versuchen Sie es in diesen Situationen mit einem exponentiellen back-off-based Wiederholungsmechanismus.
+ **`ReadOnlyViolationException`** – Da sich die Cluster-Topologie aufgrund von geplanten oder ungeplanten Ereignissen jederzeit ändern kann, können Schreibzuständigkeiten von einer Instance im Cluster auf eine andere übertragen werden. Wenn Ihr Funktionscode versucht, eine Schreibanforderung an eine Instance zu senden, die nicht mehr die primäre (Writer-)Instance ist, schlägt die Anforderung mit einer `ReadOnlyViolationException` fehl. Schließen Sie in diesem Fall die bestehende Verbindung, stellen Sie erneut eine Verbindung zum Cluster-Endpunkt her und wiederholen Sie dann die Anforderung.
Wenn Sie eine back-off-and-retry Strategie zur Behandlung von Problemen mit Schreibanforderungen verwenden, sollten Sie außerdem erwägen, idempotente Abfragen für Erstellungs- und Aktualisierungsanforderungen zu implementieren (z. B. mit [fold () .coalesce () .unfold ()](http://kelvinlawrence.net/book/Gremlin-Graph-Guide.html#upsert).
# Empfehlungen für die Verwendung von Gremlin-Leseanforderungen in Lambda
Wenn Sie eine oder mehrere Lesereplikate in Ihrem Cluster haben, ist es sinnvoll, die Leseanforderungen auf diese zu verteilen. Eine Möglichkeit besteht darin, den [Reader-Endpunkt](feature-overview-endpoints.md) zu verwenden. Der Reader-Endpunkt gleicht Verbindungen zwischen den Replikaten aus, auch wenn sich die Cluster-Topologie ändert, wenn Sie Replikate hinzufügen oder entfernen oder ein Replikat zur neuen primären Instance heraufstufen.
Die Verwendung des Reader-Endpunkts kann jedoch unter bestimmten Umständen zu einer ungleichmäßigen Nutzung der Cluster-Ressourcen führen. Der Leser-Endpunkt funktioniert durch periodisches Ändern des Hosts, auf den der DNS-Eintrag verweist. Wenn ein Client viele Verbindungen öffnet, bevor sich der DNS-Eintrag ändert, werden alle Verbindungsanfragen an eine einzelne Neptune-Instance gesendet. Dies kann bei einem Lambda-Szenario mit hohem Durchsatz der Fall sein, in dem eine große Anzahl gleichzeitiger Anfragen an Ihre Lambda-Funktion dazu führt, dass mehrere Ausführungskontexte mit jeweils eigener Verbindung erstellt werden. Wenn diese Verbindungen fast gleichzeitig erstellt werden, verweisen sie wahrscheinlich alle auf dasselbe Replikat im Cluster und tun dies so lange, bis die Ausführungskontexte wiederverwendet werden.
Eine Möglichkeit, Anfragen auf Instances zu verteilen, besteht darin, Ihre Lambda-Funktion so zu konfigurieren, dass sie eine Verbindung mit einem Instance-Endpunkt herstellt, der nach dem Zufallsprinzip aus einer Liste von Replikat-Instance-Endpunkten ausgewählt wird, und nicht mit dem Reader-Endpunkt. Der Nachteil dieser Vorgehensweise besteht darin, dass der Lambda-Code Änderungen in der Cluster-Topologie verarbeiten muss, indem er den Cluster überwacht und die Endpunktliste aktualisiert, wenn sich die Mitgliedschaft des Clusters ändert.
Wenn Sie eine Java-Lambda-Funktion schreiben, die Leseanforderungen zwischen Instances in Ihrem Cluster ausgleichen muss, können Sie den [Gremlin-Client für Amazon Neptune](https://github.com/aws/neptune-gremlin-client) verwenden, einen Java-Gremlin-Client, der Ihre Cluster-Topologie kennt und Verbindungen und Anfragen in fairer Weise auf eine Reihe von Instances in einem Neptune-Cluster verteilt. [Dieser Blog-Beitrag](https://aws.amazon.com/blogs/database/load-balance-graph-queries-using-the-amazon-neptune-gremlin-client/) enthält ein Beispiel für eine Java-Lambda-Funktion, die den Gremlin-Client für Amazon Neptune verwendet.
# Faktoren, die den Kaltstart der Neptune-Gremlin-Lambda-Funktionen verlangsamen können
Das erste Mal, dass eine AWS Lambda Funktion aufgerufen wird, wird als Kaltstart bezeichnet. Es gibt mehrere Faktoren, die die Latenz eines Kaltstarts erhöhen können:
+ **Stellen Sie sicher, dass Sie Ihrer Lambda-Funktion ausreichend Speicherplatz zuweisen.** — Die Kompilierung während eines Kaltstarts kann für eine Lambda-Funktion erheblich langsamer sein als bei eingeschalteter Funktion, EC2 da AWS Lambda die CPU-Zyklen [linear proportional zum Speicher zugewiesen werden, den](https://docs.aws.amazon.com/lambda/latest/dg/configuration-console.html) Sie der Funktion zuweisen. Bei 1.769 MB Arbeitsspeicher erhält eine Funktion das Äquivalent einer vollen vCPU (eine vCPU-Sekunde an Credits pro Sekunde). Die Auswirkung einer unzureichenden Zuweisung von Arbeitsspeicher, um adäquate CPU-Zyklen zu empfangen, ist bei großen Lambda-Funktionen, die in Java geschrieben wurden, besonders ausgeprägt.
+ **Beachten Sie, dass die [Aktivierung der IAM-Datenbankauthentifizierung](iam-auth-enable.md) einen Kaltstart verlangsamen kann** – die AWS Identity and Access Management (IAM)-Datenbankauthentifizierung kann ebenfalls Kaltstarts verlangsamen, insbesondere wenn die Lambda-Funktion einen neuen Signaturschlüssel generieren muss. Diese Latenz wirkt sich nur auf den Kaltstart und nicht auf nachfolgende Anfragen aus, denn sobald die IAM-DB-Authentifizierung die Verbindungsdaten eingerichtet hat, überprüft Neptune nur noch periodisch, ob diese noch gültig sind.