Bagikan melalui

Mendiagnosis dan memecahkan masalah pengecualian batas waktu permintaan SDK Java v4 Azure Cosmos DB

  • Artikel

BERLAKU UNTUK: NoSQL

Kesalahan HTTP 408 terjadi jika SDK tidak dapat menyelesaikan permintaan sebelum batas waktu terjadi.

Langkah-langkah pemecahan masalah

Daftar berikut ini berisi penyebab dan solusi yang diketahui untuk pengecualian waktu tunggu permintaan.

Kebijakan batas waktu end-to-end

Ada skenario di mana 408 kesalahan batas waktu jaringan akan terjadi bahkan ketika semua solusi pre-emptive yang disebutkan di bawah ini telah diterapkan. Praktik terbaik umum untuk mengurangi latensi ekor, serta meningkatkan ketersediaan dalam skenario ini, adalah menerapkan kebijakan batas waktu end-to-end. Latensi ekor dikurangi dengan gagal lebih cepat, dan unit permintaan dan biaya komputasi sisi klien berkurang dengan menghentikan percobaan ulang setelah waktu habis. Durasi batas waktu dapat diatur pada CosmosItemRequestOptions. Opsi kemudian dapat diteruskan ke permintaan apa pun yang dikirim ke Azure Cosmos DB:

CosmosEndToEndOperationLatencyPolicyConfig endToEndOperationLatencyPolicyConfig = new CosmosEndToEndOperationLatencyPolicyConfigBuilder(Duration.ofSeconds(1)).build();
CosmosItemRequestOptions options = new CosmosItemRequestOptions();
options.setCosmosEndToEndOperationLatencyPolicyConfig(endToEndOperationLatencyPolicyConfig);
container.readItem("id", new PartitionKey("pk"), options, TestObject.class);

Masalah yang sudah ada

Jika Anda melihat permintaan macet untuk durasi yang lebih lama atau waktu habis lebih sering, tingkatkan SDK Java v4 ke versi terbaru. CATATAN: Kami sangat menyarankan untuk menggunakan versi 4.18.0 ke atas. Lihat catatan rilis SDK Java v4 untuk detail selengkapnya.

Pemanfaatan CPU tinggi

Penggunaan CPU tinggi adalah kasus yang paling umum. Agar latensi optimal, penggunaan CPU harus sekitar 40 persen. Gunakan 10 detik sebagai interval untuk memantau penggunaan maksimum (bukan rata-rata) CPU. Lonjakan CPU lebih umum terjadi pada kueri lintas-partisi yang mungkin melakukan banyak koneksi untuk satu kueri.

Solusi:

Aplikasi klien yang menggunakan SDK harus ditingkatkan atau diluaskan.

Pembatasan koneksi

Pembatasan koneksi dapat terjadi karena batas koneksi pada komputer host atau kehabisan port Azure SNAT (PAT).

Batas koneksi pada komputer host

Beberapa sistem Linux, seperti `Red Hat, memiliki batas atas jumlah total file terbuka. Soket di Linux diimplementasikan sebagai file, sehingga angka ini membatasi jumlah total koneksi juga. Jalankan perintah berikut.

ulimit -a

Solusi:

Jumlah file terbuka maksimum yang diizinkan, yang diidentifikasi sebagai "nofile", harus setidaknya 10.000 atau lebih. Untuk informasi selengkapnya, lihat tips performa Azure Cosmos DB Java SDK v4.

Ketersediaan soket atau port mungkin rendah

Saat berjalan di Azure, klien yang menggunakan SDK Java dapat kehabisan port Azure SNAT (PAT).

Solusi 1:

Jika Anda menjalankan Azure VM, ikuti panduan kehabisan port SNAT.

Solusi 2:

Jika Anda menjalankan Azure App Service, ikuti panduan pemecahan masalah kesalahan koneksi dan menggunakan diagnostik Azure App Service.

Solusi 3:

Jika Anda menjalankan Azure Functions, pastikan Anda mengikuti rekomendasi Azure Functions untuk mempertahankan klien database tunggal atau statis untuk semua layanan yang terlibat (termasuk Azure Cosmos DB). Periksa batas layanan berdasarkan jenis dan ukuran hosting Aplikasi Fungsi Anda.

Solusi 4:

Jika Anda menggunakan proksi HTTP, pastikan proksi tersebut dapat mendukung jumlah koneksi yang dikonfigurasi di SDK GatewayConnectionConfig. Jika tidak, Anda akan menghadapi masalah koneksi.

Membuat beberapa instans klien

Membuat beberapa instans klien dapat menyebabkan masalah ketidaksesuaian dan batas waktu koneksi.

Solusi 1:

Ikuti tips performa, dan gunakan satu instans CosmosClient di seluruh aplikasi.

Solusi 2:

Jika Singleton CosmosClient tidak mungkin dimiliki dalam aplikasi, sebaiknya gunakan berbagi koneksi di beberapa Klien Azure Cosmos DB melalui API connectionSharingAcrossClientsEnabled(true) ini di CosmosClient. Ketika Anda memiliki beberapa instans Klien Azure Cosmos DB dalam JVM yang sama yang berinteraksi ke beberapa akun Azure Cosmos DB, memungkinkan berbagi koneksi dalam mode Langsung jika memungkinkan antara instans Klien Azure Cosmos DB. Harap dicatat, saat mengatur opsi ini, konfigurasi koneksi (misalnya, konfigurasi batas waktu soket, konfigurasi batas waktu diam) dari klien yang pertama kali dibuat akan digunakan untuk semua instans klien lainnya.

Kunci partisi panas

Azure Cosmos DB mendistribusikan throughput yang disediakan secara merata di seluruh partisi fisik. Ketika ada partisi panas, satu atau lebih kunci partisi logis fisik mengonsumsi semua Unit Permintaan partisi fisik per detik (RU/s). Pada saat yang sama, RU/s pada partisi fisik lainnya tidak akan digunakan. Sebagai gejala, total RU/s yang dikonsumsi akan kurang dari keseluruhan RU/s yang disediakan di database atau kontainer, tetapi pembatasan masih akan terlihat (429s) pada permintaan terhadap kunci partisi logis panas. Gunakan Metrik konsumsi RU Yang Dinormalisasi untuk melihat apakah beban kerja mengalami partisi panas.

Solusi:

Pilih kunci partisi yang baik untuk mendistribusikan volume permintaan dan penyimpanan secara merata. Pelajari cara mengubah kunci partisi Anda.

Tingkat konkurensi tinggi

Aplikasi ini melakukan konkurensi tingkat tinggi, yang dapat menyebabkan ketidaksesuaian di saluran.

Solusi:

Aplikasi klien yang menggunakan SDK harus ditingkatkan atau diluaskan.

Permintaan atau respons besar

Permintaan atau respons besar dapat menyebabkan pemblokiran head-of-line di saluran dan memperparah ketidaksesuaian, bahkan dengan tingkat konkurensi yang relatif rendah.

Solusi:

Aplikasi klien yang menggunakan SDK harus ditingkatkan atau diluaskan.

Tingkat kegagalan berada dalam SLA Azure Cosmos DB

Aplikasi harus dapat menangani kegagalan sementara dan mencoba kembali bila perlu. Pengecualian 408 apa pun tidak dicoba lagi karena di jalur pembuatan tidak mungkin untuk mengetahui apakah layanan membuat item atau tidak. Mengirim item yang sama lagi untuk pembuatan akan menyebabkan pengecualian konflik. Logika bisnis aplikasi pengguna mungkin memiliki logika kustom untuk menangani konflik, yang akan keluar dari ambiguitas item yang ada versus konflik dari coba lagi buat.

Tingkat kegagalan melanggar SLA Azure Cosmos DB

Hubungi Dukungan Azure.

Langkah berikutnya