So sánh Pgpool-II và Pgbouncer – Phần 2 - Đặng Xuân Duy

Tiếp theo bài viết “So sánh pgpool-II và pgbouncer – Phần 1”, nếu bạn chưa đọc có thể xem tại đây

Đọc thêm So sánh Pgpool-II và Pgbouncer – Phần 1

Bài viết gốc tại đây

Bài trước là so sánh về mặt tính năng, còn bài này liên quan đến việc so sánh hiệu năng.

1. Bắt đầu nhé

Trong khi PgBouncer có vẻ là lựa chọn tốt hơn về mặt lý thuyết, lý thuyết thường có thể gây hiểu lầm. Vì vậy, tôi đã đánh giá hiệu năng của 2 phần mềm (Pgpool II và PgBouncer ) bằng cách sử dụng công cụ pg_bench tiêu chuẩn, để xem cái nào cung cấp thông lượng giao dịch trên mỗi giây tốt hơn, qua một bài kiểm tra tiêu chuẩn.

Để dễ so sánh hơn nữa, tôi cũng đã chạy các thử nghiệm tương tự trong trường hợp không sử dụng cả Pgpool II và PgBouncer.

2. Điều kiện thử nghiệm

Tất cả các bài kiểm tra điểm chuẩn của PostgreSQL đều được chạy trong các điều kiện sau:

Pgbench được khởi tạo với scale factor là 100.
Tắt tính năng auto-vacuuming trên PostgreSQL để ngăn chặn ảnh hưởng của nó đến kết quả thử nghiệm.
Không có tải hoạt động nào khác vào thời điểm đó.
Sử dụng pgbench với tùy chọn mặc định để chạy các bài kiểm tra.
Sử dụng cài đặt mặc định cho cả PgBouncer và Pgpool-II, ngoại trừ max_children *. Tất cả các giới hạn trong PostgreSQL cũng được đặt thành mặc định.
Tất cả các bài kiểm tra đều sử dụng một luồng xử lý đơn (single thread), trên máy chủ có một CPU, 2 lõi, trong thời gian 5 phút.
Buộc pgbench tạo kết nối mới cho mỗi giao dịch (transaction) bằng cách sử dụng tùy chọn -C.

Kịch bản kiểm thử này mô phỏng tải hoạt động của một ứng dụng web và sẽ cho bạn thấy lý do tại sao lại phải sử dụng connection pooling. Tôi sẽ thử nghiệm mỗi lần trong 5 phút để đảm bảo loại bỏ nhiễu cho kết quả trung bình.

Và đây là cách phần mềm Pgpool-II và PgBouncer được cài đặt:

Đối với PgBouncer, tôi đã cài đặt nó trên cùng máy chủ với PostgreSQL. Đây là cấu hình tôi sử dụng trong các cụm PostgreSQL được quản lý của chúng tôi. Vì PgBouncer là một tiến trình rất nhẹ nên việc cài đặt nó trên cùng máy chủ với PostgreSQL không ảnh hưởng đến hiệu suất tổng thể.
Đối với Pgpool-II, tôi đã kiểm tra cả 2 trường hợp: Pgpool-II được cài đặt trên cùng một máy chủ với PostgreSQL (on box) và cả khi nó được cài đặt trên một máy chủ khác (off box). Kết quả như mong đợi, hiệu suất trở nên tốt hơn nhiều khi Pgpool-II được cài đặt trên máy chủ riêng, vì nó không phải cạnh tranh với PostgreSQL về tài nguyên.

3. Kết quả

Dưới đây là kết quả giao dịch mỗi giây (TPS) cho từng tình huống trên một loạt các máy khách.

Số máy khách	Không connection pooling	pgBouncer	Pgpool II (on box)	Pgpool II (off box)
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	Kết nối bị ngắt	26.93	Kết nối bị ngắt khi max-children > 200, pgbench bị treo khi max-children <= 100	Kết nối bị ngắt khi max-children > 200, pgbench bị treo khi max-children <= 100

Pgpool-II bị treo khi pg_bench được chạy với nhiều máy khách hơn max_children. Vì vậy, tôi đã tăng max_children để phù hợp với số lượng máy khách cho mỗi lần chạy thử nghiệm.

Nếu tôi so sánh tỷ lệ cải thiện khi có sử dụng connection pooling so với khi không sử dụng, thì đây là những gì chúng ta nhận được:

Số máy khách	pgBouncer (cải thiện)	Pgpool II (on box) (cải thiện)	Pgpool II (off box) (cải thiện)
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%

4.Kết luận

Như bạn có thể thấy từ kết quả kiểm tra hiệu năng, một connection pool được cấu hình phù hợp có thể tăng đáng kể thông lượng giao dịch, ngay cả với một số lượng khá nhỏ máy khách. Connection pool đặc biệt hữu ích khi số lượng máy khách vượt quá số lượng máy khách tối đa được hỗ trợ bởi PostgreSQL. Trong trường hợp này, PgBouncer vẫn có thể duy trì tốc độ giao dịch, trong khi cơ chế kết nối trực tiếp đến PostgreSQL sẽ thất bại.

Tuy nhiên, nếu một Connection pool được cấu hình không tốt, thực sự có thể làm giảm hiệu suất, như chúng ta đã thấy với thiết lập Pgpool-II ở trên. Một phần của vấn đề là, việc sử dụng Pgpool-II làm tăng gấp đôi số tiến trình chạy trên cùng một máy chủ – do đó, chúng ta phải chạy Pgpool-II trên một máy chủ riêng để có được hiệu suất tốt. Nhưng ngay cả khi đó, PgBouncer vẫn cung cấp hiệu suất tốt hơn cho số lượng máy khách tương đối nhỏ.

Ngoài ra, hãy lưu ý rằng thử nghiệm ở đây thực sự đã được tạo hoàn hảo cho Pgpool-II, vì khi N > 32, số lượng máy khách và số lượng tiến trình con là như nhau, do đó, mỗi lần kết nối lại đảm bảo luôn tìm thấy một tiến trình được lưu trong bộ nhớ cache. Ngay cả khi đó, PgBouncer vẫn là giải pháp tốt hơn.

Vì vậy, thử nghiệm của tôi cho thấy PgBouncer là lựa chọn tốt hơn nhiều cho bài toán Connection Pool. Tuy nhiên, điều quan trọng cần nhớ là: mặc dù một Connection Pool là gần như bắt buộc đối với các database trên thực tế, việc bạn có được lợi ích nhiều hơn hay không phụ thuộc vào ứng dụng của bạn. Các mô hình truy cập dữ liệu hay kiến trúc database của bạn sẽ ảnh hưởng nhiều đến độ trễ thực tế. Lời khuyên của tôi cho bạn là: Nên kiểm thử cả 2 giải pháp trên hệ thống test của bạn trước khi áp dụng lên hệ thống thực tế.

Nguồn: https://dangxuanduy.com/

Hiện tại, tôi có tổ chức đều đặn các khóa học về quản trị Oracle Database, tôi sẽ để thông tin ở đây, để bạn nào quan tâm về lịch học cũng như chương trình học có thể theo dõi nhé.

KHOÁ DÀNH CHO NGƯỜI MỚI

KHÓA HỌC: QUẢN TRỊ ORACLE DATABASE THẬT LÀ ĐƠN GIẢN (ADMIN 1)

CÁC KHOÁ NÂNG CAO:

KHÓA HỌC ORACLE NÂNG CAO: QUẢN TRỊ KIẾN TRÚC MULTITENANT 12c

KHÓA HỌC ORACLE NÂNG CAO: QUẢN TRỊ HỆ THỐNG DATA GUARD

CÁC KHOÁ COMBO:

COMBO 1: ADMIN 1 + MULTITENANT 12c

COMBO 2: ADMIN 1 + DATA GUARD

COMBO 3: ADMIN 1 + MULTITENANT 12c + DATA GUARD

LỊCH HỌC:

Mời bạn xem tại đây: LỊCH HỌC CÁC LỚP ORACLE

ĐĂNG KÝ: