Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Rekomendasi untuk digunakan AWS Lambda dengan Amazon Neptunus Gremlin
Kami sekarang merekomendasikan menggunakan koneksi tunggal dan sumber grafik traversal untuk seumur hidup dari konteks eksekusi Lambda, bukan satu untuk setiap invokasi fungsi (setiap fungsi invkasi hanya menangani hanya satu permintaan klien). Karena permintaan klien yang bersamaan ditangani oleh instans fungsi yang berbeda yang berjalan di dalam konteks eksekusi terpisah, maka tidak perlu mempertahankan kolam koneksi untuk menangani permintaan yang bersamaan dalam instans fungsi. Jika driver Gremlin yang Anda gunakan memiliki kolam koneksi, konfigurasikan driver tersebut untuk menggunakan hanya satu koneksi.
Untuk menangani kegagalan koneksi, gunakan logika coba lagi di sekitar masing-masing kueri. Meskipun tujuannya adalah untuk mempertahankan koneksi tunggal untuk seumur hidup konteks eksekusi, peristiwa jaringan tak terduga dapat menyebabkan koneksi tersebut dihentikan tiba-tiba. Kegagalan koneksi seperti itu terwujud sebagai kesalahan yang berbeda tergantung pada driver yang Anda gunakan. Anda harus melakukan kode fungsi Lambda Anda untuk menangani masalah koneksi ini dan mencoba koneksi ulang jika diperlukan.
Beberapa driver Gremlin secara otomatis menangani koneksi ulang. Driver Java, misalnya, secara otomatis mencoba untuk membangun kembali konektivitas ke Neptune atas nama kode klien Anda. Dengan driver ini, kode fungsi Anda hanya perlu mundur dan coba lagi kueri. Driver JavaScript dan Python, sebaliknya, tidak menerapkan logika koneksi ulang otomatis apa pun, jadi dengan driver ini kode fungsi Anda harus mencoba menyambung kembali setelah mundur, dan hanya mencoba lagi kueri setelah koneksi dibuat kembali.
Contoh kode di sini termasuk logika rekoneksi daripada menganggap bahwa klien mengurus itu.
# Rekomendasi untuk menggunakan permintaan tulis Gremlin di Lambda
Jika fungsi Lambda Anda memodifikasi data grafik, pertimbangkan untuk mengadopsi back-off-and-retry strategi untuk menangani pengecualian berikut:
+ **`ConcurrentModificationException`** – Semantik transaksi Neptune berarti bahwa permintaan tulis terkadang gagal dengan `ConcurrentModificationException`. Dalam situasi ini, cobalah mekanisme coba lagi back-off-based eksponensial.
+ **`ReadOnlyViolationException`** – Karena topologi klaster dapat berubah setiap saat sebagai akibat dari peristiwa yang direncanakan atau tidak direncanakan, menulis tanggung jawab dapat bermigrasi dari satu instans ke lainnya dalam klaster. Jika kode fungsi Anda mencoba untuk mengirim permintaan tulis ke instans yang bukan lagi instans utama (penulis), permintaan gagal dengan `ReadOnlyViolationException`. Ketika ini terjadi, tutup koneksi yang ada, sambung kembali ke titik akhir klaster, dan kemudian coba lagi permintaannya.
Selain itu, jika Anda menggunakan back-off-and-retry strategi untuk menangani masalah permintaan tulis, pertimbangkan untuk menerapkan kueri idempoten untuk membuat dan memperbarui permintaan (misalnya, menggunakan [fold () .coalesce () .unfold ()](http://kelvinlawrence.net/book/Gremlin-Graph-Guide.html#upsert).
# Rekomendasi untuk menggunakan permintaan tulis Gremlin di Lambda
Jika Anda memiliki satu replika baca atau lebih klaster Anda, itu ide yang baik untuk menyeimbangkan permintaan baca di seluruh replika ini. Salah satu pilihan adalah dengan menggunakan [reader endpoint](feature-overview-endpoints.md). Reader Endpoint menyeimbangkan koneksi di seluruh replika bahkan jika topologi klaster berubah ketika Anda menambahkan atau menghapus replika, atau mempromosikan replika untuk menjadi instans primer baru.
Namun, menggunakan Reader Endpoint dapat mengakibatkan penggunaan sumber daya klaster yang tidak merata dalam beberapa keadaan. Reader Endpoint bekerja dengan mengubah host yang ditunjuk entri DNS secara berkala. Jika klien membuka banyak koneksi sebelum perubahan entri DNS, semua permintaan koneksi dikirim ke instans Neptune tunggal. Hal ini dapat menjadi kasus dengan skenario Lambda throughput tinggi di mana sejumlah besar permintaan bersamaan untuk fungsi Lambda Anda menyebabkan beberapa konteks eksekusi akan dibuat, masing-masing dengan koneksinya sendiri. Jika koneksi tersebut semuanya dibuat hampir bersamaan, koneksi cenderung ke semua titik pada replika yang sama dalam klaster, dan untuk tetap menunjuk ke replika itu sampai konteks eksekusi didaur ulang.
Salah satu cara Anda dapat mendistribusikan permintaan di seluruh instans adalah untuk mengkonfigurasi fungsi Lambda Anda agar terhubung ke titik akhir instans, dipilih secara acak dari daftar titik akhir instans replika, bukan Reader Endpoint. Kelemahan dari pendekatan ini adalah bahwa pendekatan ini memerlukan kode Lambda untuk menangani perubahan dalam topologi klaster dengan memantau klaster dan memperbarui daftar titik akhir setiap kali keanggotaan klaster berubah.
Jika Anda menulis fungsi Lambda Java yang perlu menyeimbangkan permintaan baca di seluruh instans di klaster Anda, Anda dapat menggunakan [Klien Gremlin untuk Amazon Neptune](https://github.com/aws/neptune-gremlin-client), klien Gremlin Java yang mengetahui topologi klaster Anda dan yang dengan adil mendistribusikan koneksi dan permintaan di seluruh satu set instans di klaster Neptune. [Posting blog ini](https://aws.amazon.com/blogs/database/load-balance-graph-queries-using-the-amazon-neptune-gremlin-client/) termasuk contoh fungsi Lambda Java yang menggunakan klien Gremlin untuk Amazon Neptune.
# Faktor-faktor yang dapat memperlambat awal dingin dari fungsi Lambda Gremlin Neptune
Pertama kali AWS Lambda fungsi dipanggil disebut sebagai awal yang dingin. Ada beberapa faktor yang dapat meningkatkan latensi awal dingin:
+ **Pastikan untuk menetapkan memori yang cukup untuk fungsi Lambda Anda.** — Kompilasi selama start dingin dapat secara signifikan lebih lambat untuk fungsi Lambda daripada yang akan diaktifkan EC2 karena AWS Lambda mengalokasikan siklus CPU secara [linier sebanding dengan memori yang Anda tetapkan ke fungsi tersebut](https://docs.aws.amazon.com/lambda/latest/dg/configuration-console.html). Dengan memori 1.769 MB, sebuah fungsi menerima setara dengan satu vCPU penuh (satu VCPU-detik kredit per detik). Dampak tidak menetapkan cukup memori untuk menerima siklus CPU yang memadai yakni terutama ditentukan untuk fungsi Lambda besar yang tertulis di Java.
+ **Sadarilah bahwa [mengaktifkan autentikasi basis data IAM](iam-auth-enable.md) dapat memperlambat awal dingin** – AWS Identity and Access Management (IAM) autentikasi database juga dapat memperlambat awal dingin, terutama jika fungsi Lambda untuk menghasilkan kunci penandatanganan baru. Latency ini hanya mempengaruhi awal dingin dan bukan permintaan berikutnya, karena setelah IAM DB auth telah menetapkan kredensial koneksi, Neptune hanya secara berkala memvalidasi bahwa mereka masih berlaku.