Dalam posting kami sebelumnya di seri ini, kami berbicara panjang lebar tentang menggunakan PgBouncer dan Pgpool-II, arsitektur kumpulan koneksi dan pro dan kontra dari memanfaatkan satu untuk penerapan PostgreSQL Anda. Dalam posting terakhir kami, kami akan menempatkan mereka secara langsung dalam perbandingan fitur terperinci dan membandingkan hasil kinerja PgBouncer vs. Pgpool-II untuk hosting PostgreSQL Anda!
Bagaimana fitur menumpuk?
Mari kita mulai dengan membandingkan fitur PgBouncer vs. Pgpool-II:
PgBouncer | Pgpool-II | |
|---|---|---|
| Konsumsi sumber daya | Hanya menggunakan satu proses yang membuatnya sangat ringan. PgBouncer menjamin jejak memori yang kecil, bahkan ketika berurusan dengan kumpulan data yang besar. Pemenang! | Jika kita memerlukan N koneksi paralel, ini memotong N proses anak. Secara default, ada 32 proses anak yang bercabang. |
| Kapan koneksi digunakan kembali? | PgBouncer mendefinisikan satu kumpulan per pengguna+kombinasi basis data. Ini dibagikan di antara semua klien, jadi koneksi gabungan tersedia untuk semua klien. Pemenang! | Pgpool-II mendefinisikan satu proses per proses anak. Kami tidak dapat mengontrol proses anak mana yang terhubung dengan klien. Klien mendapat manfaat dari koneksi gabungan hanya jika terhubung ke turunan yang sebelumnya melayani koneksi untuk kombinasi basis data+pengguna ini. |
| Mode pengumpulan | PgBouncer mendukung tiga mode berbeda:sesi (koneksi dikembalikan ke kumpulan saat klien terputus), transaksi (dikembalikan ke kumpulan saat klien melakukan atau rollback) atau pernyataan ( koneksi dikembalikan ke kumpulan setelah eksekusi setiap pernyataan). Pemenang! | Pgpool-II hanya mendukung mode session pooling – keefektifan pooling bergantung pada perilaku baik dari klien. |
| Ketersediaan tinggi | Tidak didukung. | Ketersediaan tinggi PostgreSQL didukung melalui proses pengamat bawaan Pgpool-II. Pemenang! |
| Load balancing | Tidak didukung – PgBouncer merekomendasikan penggunaan HAProxy untuk ketersediaan tinggi dan penyeimbangan muatan. | Mendukung penyeimbangan beban otomatis – bahkan cukup cerdas untuk mengalihkan permintaan baca ke standby, dan menulis ke master. Pemenang! |
| Dukungan multi-cluster | Satu instance PgBouncer dapat menampilkan beberapa cluster PostgreSQL (satu simpul atau kumpulan replika). Ini dapat mengurangi biaya middleware saat menggunakan beberapa cluster PostgreSQL. Pemenang! (Catatan – keuntungan ini hanya untuk skenario tertentu) | Pgpool-II tidak memiliki dukungan multi-cluster. |
| Kontrol koneksi | PgBouncer memungkinkan pembatasan koneksi per kumpulan, per basis data, per pengguna, atau per klien. Pemenang! | Pgpool-II memungkinkan pembatasan jumlah keseluruhan koneksi saja. |
| Antrean koneksi | PgBouncer mendukung antrian di tingkat aplikasi (yaitu PgBouncer mempertahankan antrian). Pemenang! | Pgpool-II mendukung antrian pada tingkat kernel – ini dapat menyebabkan pg_bench pada CentOS 6 berhenti bekerja. |
| Otentikasi | Otentikasi pass-through didukung melalui PgBouncer. Pemenang! | Pgpool-II tidak mendukung otentikasi pass-through – pengguna dan sandi terenkripsi md5 mereka harus dicantumkan dalam file dan diperbarui secara manual setiap kali pengguna memperbarui kata sandi mereka. Pgpool-II mendukung otentikasi tanpa kata sandi melalui PAM atau sertifikat SSL. Namun, ini harus diatur di luar sistem PostgreSQL, sementara PgBouncer dapat memindahkannya ke server PostgreSQL. |
| Administrasi | PgBouncer menyediakan database virtual yang melaporkan berbagai statistik berguna. | Pgpool-II menyediakan antarmuka administrasi yang mendetail, termasuk GUI. Pemenang! |
| Otentikasi berbasis host | Didukung. Terikat! | Didukung. Terikat! |
| dukungan SSL | Dukungan penuh. Terikat! | Dukungan penuh. Terikat! |
| Replikasi logis | Tidak didukung melalui PgBouncer. Terikat! | Didukung melalui Pgpool-II, tetapi ini dilakukan dengan mengirimkan kueri tulis ke semua node, dan umumnya tidak disarankan. Terikat! |
| Lisensi | ISC – sangat permisif, pada dasarnya memungkinkan semua penggunaan. Terikat! | Lisensi khusus – sama-sama permisif. Terikat! |
Intinya – Pgpool-II adalah alat yang hebat jika Anda membutuhkan penyeimbangan beban dan ketersediaan tinggi. Penyatuan koneksi hampir merupakan bonus yang Anda dapatkan. PgBouncer hanya melakukan satu hal, tetapi melakukannya dengan sangat baik. Jika tujuannya adalah untuk membatasi jumlah koneksi dan mengurangi konsumsi sumber daya, PgBouncer menang telak.
Hal ini juga baik-baik saja untuk menggunakan PgBouncer dan Pgpool-II dalam rantai – Anda dapat memiliki PgBouncer untuk menyediakan penyatuan koneksi, yang berbicara dengan Instans Pgpool-II yang menyediakan ketersediaan tinggi dan penyeimbangan beban. Ini memberi Anda yang terbaik dari kedua dunia!
Pengujian Kinerja
Sementara PgBouncer tampaknya menjadi pilihan yang lebih baik dalam teori, teori seringkali bisa menyesatkan. Jadi, kami mengadu dua penyatuan koneksi head-to-head, menggunakan alat pgbench standar, untuk melihat mana yang memberikan throughput transaksi per detik yang lebih baik melalui uji benchmark. Untuk ukuran yang baik, kami menjalankan pengujian yang sama tanpa pooler koneksi juga.
Kondisi Pengujian
Semua tes benchmark PostgreSQL dijalankan dalam kondisi berikut:
- Inisialisasi pgbench menggunakan faktor skala 100.
- Menonaktifkan auto-vacuuming pada instance PostgreSQL untuk mencegah interferensi.
- Tidak ada beban kerja lain yang bekerja pada saat itu.
- Menggunakan skrip pgbench default untuk menjalankan pengujian.
- Menggunakan pengaturan default untuk PgBouncer dan Pgpool-II, kecuali max_children *. Semua batas PostgreSQL juga disetel ke default.
- Semua pengujian dijalankan sebagai satu utas, pada satu-CPU, mesin 2-inti, selama 5 menit.
- Memaksa pgbench untuk membuat koneksi baru untuk setiap transaksi menggunakan opsi -C. Ini mengemulasi beban kerja aplikasi web modern dan merupakan alasan utama untuk menggunakan pooler!
Kami menjalankan setiap iterasi selama 5 menit untuk memastikan noise dirata-ratakan. Berikut adalah cara middleware dipasang:
- Untuk PgBouncer, kami menginstalnya di kotak yang sama dengan server PostgreSQL. Ini adalah konfigurasi yang kami gunakan di cluster PostgreSQL terkelola kami. Karena PgBouncer adalah proses yang sangat ringan, menginstalnya di kotak tidak berdampak pada kinerja secara keseluruhan.
- Untuk Pgpool-II, kami menguji keduanya saat instance Pgpool-II diinstal pada mesin yang sama dengan PostgreSQL (pada kolom kotak), dan saat diinstal pada mesin yang berbeda (di luar kolom kotak). Seperti yang diharapkan, performanya jauh lebih baik saat Pgpool-II tidak digunakan karena tidak harus bersaing dengan server PostgreSQL untuk mendapatkan sumber daya.
Tolok Ukur Hasil
Berikut adalah hasil transaksi per detik (TPS) untuk setiap skenario di rentang jumlah klien:
| Jumlah klien | Tanpa penggabungan | PgBouncer | Pgpool-II (di kotak) | Pgpool-II (di luar kotak) |
|---|---|---|---|---|
| 10 | 16,96 | 26,86 | 15,52 | 18,22 |
| 20 | 16,97 | 27,19 | 15,67 | 18,28 |
| 40 | 16,73 | 26,77 | 15,33 | 18,3 |
| 80 | 16,75 | 26,64 | 15,53 | 18.13 |
| 100 | 16,51 | 26,73 | 15,66 | 18,45 |
| 200 | Koneksi dibatalkan. | 26,93 | Koneksi dibatalkan saat max-children> 200, pgbench hang pada nilai max-children jika <=100. | Koneksi dibatalkan saat max-children> 200, pgbench hang pada nilai max-children jika <=100. |
Pgpool-II hang ketika pg_bench dijalankan dengan lebih banyak klien daripada max_children. Jadi, kami meningkatkan max_children agar sesuai dengan jumlah klien untuk setiap uji coba.
Jika kami menghitung persentase peningkatan TPS saat menggunakan connection pooler, inilah yang kami dapatkan:
| Jumlah klien | PgBouncer | Pgpool-II (pada kotak) | Pgpool-II (di luar kotak) |
|---|---|---|---|
| 10 | 58,37% | -8.49% | 7.43% |
| 20 | 60,22% | -7,66% | 7,72% |
| 40 | 60,01% | -8,37% | 9,38% |
| 80 | 59,04% | -7.28% | 8,24% |
| 100 | 61,90% | -5,15% | 11,75% |
* Algoritme peningkatan =(dengan pooler – tanpa)/tanpa
Kata Akhir
Seperti yang Anda lihat dari hasil pengujian kinerja, koneksi yang dikonfigurasi dengan baik dan kumpulan koneksi yang sesuai dapat secara drastis meningkatkan throughput transaksi, bahkan dengan jumlah klien yang cukup kecil. Pengumpul koneksi sangat berguna untuk dukungan antrian mereka – ketika jumlah klien melebihi klien maksimal yang didukung oleh server PostgreSQL, PgBouncer masih dapat mempertahankan tingkat transaksi, sedangkan koneksi langsung ke PostgreSQL dibatalkan.
Namun, penyatuan koneksi yang dikonfigurasi dengan buruk sebenarnya dapat mengurangi kinerja seperti yang kita lihat dengan penyiapan Pgpool-II di sini. Sebagian dari masalahnya adalah, menggunakan Pgpool-II ganda jumlah proses yang berjalan di server yang sama - kita harus jalankan Pgpool-II di server terpisah untuk mendapatkan kinerja yang baik. Namun meskipun demikian, PgBouncer berhasil memberikan kinerja yang lebih baik untuk jumlah klien yang relatif kecil ini.
Juga, perhatikan pengujian di sini sebenarnya dibuat dengan sempurna untuk Pgpool-II – karena ketika N> 32, jumlah klien dan jumlah proses turunan adalah sama, dan karenanya, setiap rekoneksi dijamin untuk menemukan proses yang di-cache. Meski begitu, PgBouncer adalah alternatif yang lebih cepat.
Jadi, pengujian kami menunjukkan PgBouncer adalah pilihan yang jauh lebih baik untuk penyatuan koneksi. Namun, penting untuk diingat bahwa meskipun kumpulan koneksi mutlak wajib untuk sebagian besar beban kerja yang realistis, apakah Anda memperoleh lebih banyak dengan menggunakan kumpulan sisi klien atau middleware seperti PgBouncer bergantung pada aplikasi Anda. Pola akses data akan berperan, seperti halnya latensi yang terlibat berdasarkan arsitektur Anda. Sebaiknya uji beban kerja Anda terhadap keduanya, lalu putuskan tindakan terbaik – tidak ada alternatif yang lebih baik selain eksperimen!
