ApsaraDB RDS:Konfigurasikan connection pooling

Pilih tipe connection pool

ApsaraDB RDS for MySQL menyediakan dua tipe connection pool. Gunakan pertanyaan berikut untuk menentukan tipe yang sesuai dengan workload Anda.

Apakah koneksi Anda bersifat persisten sepanjang sesi atau bersifat singkat?

• Koneksi persisten (framework web dengan pool bawaan seperti Druid, DBCP, c3p0, atau HikariCP): nonaktifkan connection pooling. Proksi tidak memberikan nilai tambah dalam skenario ini karena pool tingkat aplikasi sudah mencukupi.

• Koneksi singkat (skrip PHP, fungsi serverless, pola satu koneksi per permintaan): aktifkan connection pooling dan lanjutkan ke bagian berikutnya.

Apakah Anda mencapai batas koneksi instans, atau apakah workload Anda menggunakan salah satu batas tingkat transaksi?

Secara default, connection pooling dinonaktifkan. Setelah Anda mengubah tipe connection pool, perubahan tersebut hanya berlaku untuk koneksi baru.

Batasan

Tabel berikut membandingkan operasi dan fungsi yang didukung di masing-masing mode pool. Tinjau hal ini sebelum memilih tipe.

Untuk versi database proxy V1.13.11 atau lebih baru:

SELECT FOUND_ROWS() setelah SELECT SQL_CALC_FOUND_ROWS * FROM t1 LIMIT * mengembalikan hasil yang akurat. Namun, pola ini tidak lagi direkomendasikan oleh MySQL. Gantilah dengan SELECT COUNT(*) FROM tb1. Lihat FOUND_ROWS().

SELECT LAST_INSERT_ID() setelah pernyataan INSERT mengembalikan hasil yang akurat.

Saat koneksi dikunci (dipicu oleh operasi di atas), koneksi tersebut tidak dapat dikembalikan ke pool hingga koneksi secara eksplisit ditutup. Secara efektif, sesi tersebut berperilaku seperti session-level pooling selama masa berlaku koneksi tersebut.

Catatan penggunaan untuk variabel tingkat sesi: Transaction-level connection pooling mencocokkan variabel berikut dalam permintaan: sql_mode, character_set_server, collation_server, dan time_zone. Jika permintaan mencakup variabel sistem tingkat sesi lainnya, Anda harus secara eksplisit menjalankan pernyataan SET di client Anda untuk mengonfigurasi variabel tersebut setelah koneksi dibuat untuk permintaan tersebut. Jika tidak, koneksi yang variabel sistemnya telah dikonfigurasi ulang dapat dipilih dari connection pool dan digunakan kembali.

Cara kerja

Database proxy membagi setiap koneksi menjadi dua bagian: frontend connection antara aplikasi Anda dan proksi, serta backend connection antara proksi dan database.

Transaction-level connection pooling

Beberapa sesi berbagi satu backend connection. Proksi tidak langsung membuka backend connection saat client terhubung. Sebaliknya, proksi menunggu hingga transaksi siap dieksekusi, lalu memilih backend connection yang tersedia dari pool.

Backend connection tersedia jika nilai `user` dan `dbname`-nya sesuai dengan nilai variabel sistem yang ditentukan.

• Jika koneksi yang sesuai tersedia, proksi menggunakannya. Saat transaksi selesai, proksi mengembalikan koneksi ke pool—sesi dapat dilanjutkan tanpa berakhir.

• Jika tidak ada koneksi yang sesuai, proksi membuka koneksi baru.

Karena sesi idle tidak memegang backend connection, beberapa sesi aktif dapat dimultiplex melalui jumlah backend connection yang lebih sedikit (N sesi : 1 backend connection). Hal ini mengurangi frekuensi pembuatan koneksi dan jumlah total koneksi.

Database proxy tidak memberlakukan batas ketat pada jumlah koneksi. Batas maksimum ditentukan oleh spesifikasi instans RDS Anda.

Session-level connection pooling

Satu sesi menempati satu backend connection (N sesi : N backend connection). Proksi mencari pool untuk backend connection yang tersedia saat sesi dimulai.

Backend connection tersedia jika nilai `user`, `clientip`, dan `dbname`-nya semuanya sesuai.

• Jika koneksi yang sesuai tersedia, proksi menggunakannya kembali—menghindari overhead handshake.

• Jika tidak ada koneksi yang sesuai, proksi membuka koneksi baru.

Saat sesi berakhir, proksi mengembalikan backend connection ke pool untuk digunakan kembali oleh sesi berikutnya. Hal ini mengurangi overhead pembuatan koneksi tanpa mengurangi jumlah total koneksi terbuka.

Selama sesi aktif, backend connection-nya tidak dapat digunakan oleh sesi lain—meskipun sesi tersebut idle di antara pernyataan.

Catatan penggunaan

• Izin akun berbasis IP: Connection pooling tidak mendukung izin per-IP untuk suatu akun. Jika suatu akun memiliki izin berbeda tergantung pada IP sumber (misalnya, akses ke database_a dari 192.xx.xx.1 tetapi tidak dari 192.xx.xx.2), kesalahan izin dapat terjadi saat koneksi yang sudah ada digunakan kembali.

• Pool tingkat aplikasi: Connection pooling proksi tidak mengganggu pool tingkat aplikasi (Druid, DBCP, c3p0, HikariCP). Jika aplikasi Anda sudah mengelola pool sendiri, tidak perlu mengaktifkan connection pooling tingkat proksi.

• Kueri lambat: Connection pooling tidak menyelesaikan akumulasi koneksi yang disebabkan oleh kueri SQL lambat. Optimalkan kueri tersebut atau atasi masalahnya di tingkat instans.

• Versi proksi dan tipe endpoint: Versi proksi sebelum 2.9.1 tidak mendukung connection pooling pada endpoint hanya-baca. Versi 2.9.1 dan lebih baru mendukung connection pooling pada endpoint baca/tulis maupun hanya-baca.

• Perilaku `wait_timeout`: Saat transaction-level connection pooling diaktifkan, parameter wait_timeout mungkin tidak berlaku di client Anda. Proksi memilih koneksi dari pool pada setiap permintaan. Saat wait_timeout habis, hanya backend connection yang ditutup; koneksi yang menghadap client tetap terbuka.

• Deteksi penggunaan kembali koneksi: Jalankan SELECT CONNECTION_ID() untuk mendapatkan ID thread saat ini. Jika ID thread berubah antar permintaan dalam sesi client yang sama, koneksi tersebut sedang digunakan kembali dari pool.

• Perilaku SHOW PROCESSLIST: Saat transaction-level connection pooling diaktifkan, ID thread frontend berbeda dari ID thread backend. Akibatnya, perintah KILL mungkin mengembalikan error meskipun proses telah berhasil dihentikan. Jalankan SHOW PROCESSLIST lagi untuk memastikan status proses. Proksi juga menggabungkan hasil dari semua instansi primary, secondary, dan hanya-baca sebelum mengembalikannya ke aplikasi Anda. Alamat IP dan port yang ditampilkan di SHOW PROCESSLIST atau fitur Penjelajah SQL dan Audit mungkin berbeda dari alamat client sebenarnya. Untuk informasi lebih lanjut, lihat Gunakan fitur Penjelajah SQL dan Audit.

Aktifkan connection pooling

FAQ

Berapa banyak koneksi yang dapat ditampung oleh pool?

Tidak ada batas maksimum tetap untuk pool itu sendiri. Jika aplikasi Anda mendekati batas koneksi instans, aktifkan transaction-level connection pooling untuk memultiplex sesi melalui jumlah backend connection yang lebih sedikit.

Berapa lama koneksi idle tetap berada di pool?

Koneksi di dalam pool tetap aktif selama 10 detik sebelum ditutup.

Apakah connection pooling memengaruhi performa?

Pada workload dengan koneksi singkat, mengaktifkan connection pooling meningkatkan performa instans sekitar 10%.

Apa perbedaan antara pooling tingkat transaksi dan tingkat sesi?

Aplikasi saya terputus dari proksi. Apakah penyebabnya connection pooling?

Tidak selalu. Penyebabnya bergantung pada kondisi spesifik saat pemutusan terjadi dan mungkin tidak terkait dengan connection pooling.

Referensi API