Selain menghemat overhead connect &disconnect di mana hal ini dilakukan pada setiap permintaan, connection pooler dapat menyalurkan sejumlah besar koneksi klien ke sejumlah kecil koneksi database yang sebenarnya. Di PostgreSQL, jumlah optimal koneksi database aktif biasanya sekitar ((2 * core_count) + effective_spindle_count) . Di atas angka ini, throughput dan latensi menjadi lebih buruk.
Terkadang orang akan mengatakan "Saya ingin mendukung 2000 pengguna, dengan waktu respons yang cepat." Cukup banyak dijamin bahwa jika Anda mencoba melakukannya dengan 2000 koneksi database yang sebenarnya, kinerjanya akan mengerikan. Jika Anda memiliki mesin dengan empat prosesor quad-core dan kumpulan data aktif sepenuhnya di-cache, Anda akan melihat kinerja yang jauh lebih baik untuk 2000 pengguna tersebut dengan menyalurkan permintaan melalui sekitar 35 koneksi database.
Untuk memahami mengapa hal itu benar, eksperimen pemikiran ini akan membantu. Pertimbangkan mesin server database hipotetis dengan hanya satu sumber daya untuk dibagikan -- satu inti. Inti ini akan membagi waktu secara merata di antara semua permintaan bersamaan tanpa overhead. Katakanlah 100 permintaan semua masuk pada saat yang sama, yang masing-masing membutuhkan satu detik waktu CPU. Inti bekerja pada semuanya, membagi waktu di antara mereka sampai semuanya selesai 100 detik kemudian. Sekarang pertimbangkan apa yang terjadi jika Anda meletakkan kumpulan koneksi di depan yang akan menerima 100 koneksi klien tetapi hanya membuat satu permintaan pada satu waktu ke server database, menempatkan permintaan apa pun yang datang saat koneksi sibuk ke dalam antrian. Sekarang ketika 100 permintaan tiba pada saat yang sama, satu klien mendapat respons dalam 1 detik; yang lain mendapat respons dalam 2 detik, dan klien terakhir mendapat respons dalam 100 detik. Tidak ada yang harus menunggu lebih lama untuk mendapatkan respons, throughputnya sama, tetapi latensi rata-ratanya adalah 50,5 detik, bukan 100 detik.
Server basis data nyata memiliki lebih banyak sumber daya yang dapat digunakan secara paralel, tetapi prinsip yang sama berlaku, begitu mereka jenuh, Anda hanya akan merugikan banyak hal dengan menambahkan lebih banyak permintaan basis data secara bersamaan. Ini sebenarnya lebih buruk daripada contoh, karena dengan lebih banyak tugas Anda memiliki lebih banyak sakelar tugas, peningkatan pertentangan untuk kunci dan cache, pertikaian baris cache L2 dan L3, dan banyak masalah lain yang memotong throughput dan latensi. Selain itu, dengan work_mem yang tinggi pengaturan dapat membantu kueri dalam beberapa cara, pengaturan itu adalah batas per node rencana untuk setiap koneksi , jadi dengan sejumlah besar koneksi, Anda harus membiarkan ini sangat kecil untuk menghindari pembersihan cache atau bahkan mengarah ke swapping, yang menyebabkan rencana lebih lambat atau hal-hal seperti tabel hash tumpah ke disk.
Beberapa produk database secara efektif membangun kumpulan koneksi ke server, tetapi komunitas PostgreSQL telah mengambil posisi bahwa karena kumpulan koneksi terbaik dilakukan lebih dekat ke perangkat lunak klien, mereka akan menyerahkannya kepada pengguna untuk mengelolanya. Sebagian besar pooler akan memiliki beberapa cara untuk membatasi koneksi database ke nomor yang sulit, sementara mengizinkan lebih banyak permintaan klien secara bersamaan dari itu, mengantrekannya seperlunya. Ini yang Anda inginkan, dan itu harus dilakukan dengan transaksional dasar, bukan per pernyataan atau koneksi.
