Titik latensi dalam permintaan Spanner

Halaman ini memberikan ringkasan komponen tingkat tinggi yang terlibat dalam permintaan Spanner dan bagaimana setiap komponen dapat memengaruhi latensi.

Permintaan Spanner API

Komponen tingkat tinggi yang digunakan untuk membuat permintaan Spanner API mencakup:

Saat Anda melakukan remote procedure call ke Spanner, library klien Spanner akan menyiapkan permintaan API. Kemudian, permintaan API akan diteruskan melalui GFE dan AFE Spanner sebelum mencapai database Spanner.

Dengan mengukur dan membandingkan latensi permintaan antara berbagai komponen dan database, Anda dapat menentukan komponen mana yang menyebabkan masalah. Latensi ini mencakup latensi dua arah klien, GFE, permintaan Spanner API, dan kueri.

Diagram arsitektur Spanner.

Bagian berikut menjelaskan setiap jenis latensi yang Anda lihat dalam diagram sebelumnya.

Konektivitas langsung

Traffic aplikasi yang memenuhi kriteria tertentu dapat dirutekan langsung ke Spanner, melewati Google Front End (GFE) dan mengoptimalkan performa. Konektivitas langsung dapat diaktifkan untuk aplikasi yang memenuhi kriteria berikut:

  • Berjalan di Compute Engine atau Google Kubernetes Engine.
  • Menggunakan endpoint global.
  • Dalam jaringan yang dikonfigurasi dengan rute dan aturan firewall yang mengizinkan traffic keluar untuk mencapai 34.126.0.0/18 dan 2001:4860:8040::/42.
  • Menggunakan versi library klien:
    • Java: 6.111.0 atau yang lebih baru.
    • Go: 1.88.0 atau yang lebih baru.
  • Kredensial yang Anda gunakan untuk aplikasi memiliki spanner.databases.get izin.

Fitur ini dapat diaktifkan dengan menetapkan variabel lingkungan GOOGLE_SPANNER_ENABLE_DIRECT_ACCESS ke true atau melalui konfigurasi library klien Anda ( setEnableDirectAccess(true) di Java, ClientConfig.EnableDirectAccess di Go, atau properti koneksi enableDirectAccess=true di driver JDBC).

Untuk memverifikasi apakah konektivitas langsung Spanner digunakan, pantau label penggunaan dalam metrik sisi klien Anda.

Latensi dua arah

Latensi dua arah adalah jangka waktu (dalam milidetik) antara byte pertama permintaan Spanner API yang dikirim klien ke database (melalui GFE dan frontend Spanner API), dan byte terakhir respons yang diterima klien dari database.

Diagram arsitektur Spanner untuk latensi end-to-end.

Metrik spanner.googleapis.com/client/operation_latencies memberikan waktu antara byte pertama permintaan API yang dikirim ke byte terakhir respons yang diterima. Hal ini mencakup percobaan ulang yang dilakukan oleh library klien.

Untuk mengetahui informasi selengkapnya, lihat Melihat dan mengelola metrik sisi klien.

Latensi GFE

Latensi Google Front End (GFE) adalah jangka waktu (dalam milidetik) antara saat jaringan Google menerima remote procedure call dari klien dan saat GFE menerima byte pertama respons. Latensi ini tidak mencakup handshake TCP/SSL.

Diagram arsitektur Spanner untuk latensi GFE.

Setiap respons dari Spanner (REST atau gRPC) menyertakan header yang berisi total waktu antara GFE dan backend (layanan Spanner) untuk permintaan dan respons. Hal ini membantu membedakan sumber latensi antara klien dan GFE dengan lebih baik.

Metrik spanner.googleapis.com/client/gfe_latencies mengambil dan mengekspos latensi GFE untuk permintaan Spanner.

Untuk mengetahui informasi selengkapnya, lihat Melihat dan mengelola metrik sisi klien.

Latensi permintaan Spanner API

Latensi permintaan API Spanner adalah jangka waktu (dalam detik) dari saat AFE Spanner menerima byte pertama permintaan hingga saat frontend Spanner API mengirimkan byte terakhir respons. Latensi ini mencakup waktu yang diperlukan untuk memproses permintaan API di backend Spanner dan lapisan API. Namun, latensi ini tidak mencakup overhead jaringan atau proxy terbalik antara klien dan server Spanner.

Diagram arsitektur Spanner untuk latensi permintaan Spanner API.

Metrik spanner.googleapis.com/api/request_latencies mengambil dan mengekspos latensi AFE Spanner untuk permintaan Spanner. Untuk mengetahui informasi selengkapnya, lihat Metrik Spanner.

Latensi kueri

Latensi kueri adalah jangka waktu (dalam milidetik) yang diperlukan untuk menjalankan kueri SQL di database Spanner.

Diagram arsitektur Spanner untuk latensi kueri.

Latensi kueri tersedia untuk the executeSql API.

Jika parameter QueryMode ditetapkan ke WITH_STATS atau WITH_PLAN_AND_STATS, maka ResultSetStats Spanner akan tersedia dalam respons. ResultSetStats mencakup waktu yang berlalu untuk menjalankan kueri di database Spanner.

Untuk mengambil dan memvisualisasikan latensi kueri, lihat Mengambil latensi kueri dengan OpenTelemetry.

Langkah berikutnya