Kumpulan koneksi

Topik ini menjelaskan cara kerja kumpulan koneksi di Bigtable, dampak yang dapat ditimbulkan ukuran kumpulan koneksi pada aplikasi yang menggunakan Bigtable, dan kapan Anda mungkin ingin mengubah setelan kumpulan koneksi default.

Setelah membaca halaman ini, jika Anda memutuskan bahwa Anda harus mengubah ukuran kumpulan koneksi, lihat Mengonfigurasi kumpulan koneksi untuk mempelajari cara menentukan ukuran yang optimal dan cara mengubahnya. Jumlah koneksi di setiap kumpulan dapat dikonfigurasi dalam kode Anda hanya jika Anda menggunakan library klien Go, C++, atau Java untuk Cloud Bigtable.

Cara kerja kumpulan koneksi

Kumpulan koneksi, juga dikenal sebagai kumpulan saluran, adalah cache koneksi database yang digunakan bersama dan digunakan kembali untuk meningkatkan latensi dan performa koneksi. Koneksi digunakan dalam sistem round robin.

Saat menggunakan Bigtable, Anda membuat satu klien data per proses aplikasi. Setiap klien memiliki satu kumpulan koneksi. Setiap kumpulan koneksi berisi sejumlah koneksi gRPC, yang masing-masing dapat menangani hingga 100 streaming serentak. Permintaan yang dikirim melalui koneksi ini akan melewati middleware Google, yang kemudian merutekannya ke tabel Anda. Lapisan middleware terdiri dari banyak instance load-balanced, dan setiap permintaan dirutekan melalui instance middleware yang memiliki ketersediaan terbanyak.

Anda dapat menganggap koneksi (atau saluran) seperti jalan raya yang memiliki hingga 100 jalur, dan setiap jalur (aliran) hanya dapat berisi satu mobil (permintaan) pada waktu tertentu. Batas 100 streaming serentak per koneksi gRPC diterapkan di lapisan middleware Google, dan Anda tidak dapat mengonfigurasi ulang jumlah ini.

Koneksi akan otomatis diperbarui setiap satu jam sekali. Selain itu, jika koneksi belum melihat permintaan dalam lima menit, middleware akan otomatis menghapus koneksi dan tidak membuatnya lagi hingga koneksi tambahan diperlukan.

Di balik layar, setiap channel memiliki satu subchannel. Setiap subsaluran memiliki koneksi HTTP2 yang menggunakan TCP untuk mengonversi permintaan menjadi byte dan mengirimkannya melalui middleware, lalu ke tabel Anda. Proses ini ditangani secara lancar oleh layanan Bigtable, dan Anda tidak perlu mengonfigurasi apa pun untuk melakukannya.

Kumpulan koneksi dan traffic

Pengaruh kumpulan koneksi terhadap performa

Idealnya, Anda harus memiliki cukup koneksi gRPC untuk menangani permintaan tanpa buffering. Namun, Anda tidak boleh memiliki terlalu banyak koneksi sehingga sering terputus karena kurangnya penggunaan.

Koneksi tidak cukup

Jika kumpulan koneksi tidak memiliki cukup koneksi untuk menangani traffic Anda, middleware akan mulai melakukan buffering dan membuat antrean permintaan. Buffering ini memperlambat traffic, mengurangi jumlah permintaan per detik, dan meningkatkan latensi saat permintaan di-back up.

Terlalu banyak koneksi

Jika kumpulan memiliki terlalu banyak koneksi, yang berarti beberapa koneksi tidak ada aktivitas, middleware akan memutuskan koneksi yang tidak ada aktivitas. Kemudian, saat permintaan baru yang memerlukannya datang, koneksi ini akan dibuat ulang. Artinya, saat traffic meningkat, permintaan dapat mengalami cache miss sisi server, yang menyebabkan pekerjaan dan latensi tambahan. Jika hal ini sering terjadi karena tingkat traffic yang bervariasi, aktivitas ini dapat muncul sebagai lonjakan latensi ekor yang dirasakan di sisi klien.

Waktu untuk mengubah setelan default

Ukuran kumpulan koneksi default tepat untuk sebagian besar aplikasi, dan dalam sebagian besar kasus, Anda tidak perlu mengubahnya. Bergantung pada library klien yang Anda gunakan dalam aplikasi, Anda mungkin tidak dapat mengubah ukuran kumpulan koneksi. Jumlah koneksi di setiap kumpulan dapat dikonfigurasi dalam kode Anda hanya jika Anda menggunakan library klien Go, C++, atau Java untuk Cloud Bigtable.

Sebagai aturan umum, kumpulan koneksi yang ideal memiliki setidaknya dua kali jumlah koneksi yang diperlukan untuk saturasi maksimum. Hal ini akan memberi ruang untuk fluktuasi traffic. Misalnya, jika Anda memiliki 4 koneksi dan masing-masing menangani jumlah permintaan maksimum yang mungkin (100), Anda ingin mengurangi jumlah permintaan per koneksi menjadi antara 10 dan 50, sehingga ukuran kumpulan koneksi yang ideal setidaknya dua kali lipat, atau minimal 8 koneksi.

Sinyal yang harus Anda pertimbangkan untuk mengubah jumlah koneksi dalam kumpulan meliputi hal berikut:

Throughput rendah yang dikombinasikan dengan lonjakan latensi ekor sisi klien

Jika throughput standar Anda cukup rendah, seperti kurang dari satu permintaan per detik per koneksi, dan Anda mengamati latensi ekor tinggi secara berkala untuk aplikasi, Anda mungkin tidak mengirim cukup traffic untuk mempertahankan koneksi tetap aktif. Dalam hal ini, Anda mungkin perlu menurunkan jumlah koneksi dalam kumpulan. Lihat Mengonfigurasi kumpulan koneksi untuk mempelajari cara menentukan jumlah yang tepat.

Permintaan yang di-buffer

Jika Anda mengamati bahwa permintaan menumpuk di sisi klien, hal ini mungkin menunjukkan bahwa Anda mengirim lebih banyak permintaan serentak daripada yang dapat ditangani oleh kumpulan koneksi. Hitung jumlah optimal, lalu ubah kode jika perlu.

Untuk menentukan apakah permintaan menumpuk, Anda dapat menggunakan OpenCensus untuk melihat perbedaan antara metrik grpc.io/client/started_rpcs dan grpc.io/client/completed_rpcs.

Lingkungan virtual

Dalam beberapa kasus yang jarang terjadi, klien Bigtable tidak dapat mengetahui jumlah CPU tempat aplikasi berjalan dan mengalokasikan koneksi seolah-olah hanya satu CPU yang digunakan. Misalnya, hal ini dapat terjadi saat Anda menggunakan instance CPU virtual di Kubernetes atau Docker. Jika hal ini terbukti, Anda harus mengonfigurasi jumlah kumpulan sesuai dengan pedoman berdasarkan QPS dan latensi aplikasi Anda.

Langkah Berikutnya