Bên cạnh việc tiết kiệm chi phí kết nối &ngắt kết nối khi điều này được thực hiện theo cách khác trên mỗi yêu cầu, trình gộp kết nối có thể chuyển một số lượng lớn các kết nối máy khách xuống một số lượng nhỏ các kết nối cơ sở dữ liệu thực tế. Trong PostgreSQL, số lượng kết nối cơ sở dữ liệu đang hoạt động tối ưu thường nằm ở đâu đó khoảng ((2 * core_count) + effect_spindle_count) . Trên con số này, cả thông lượng và độ trễ đều trở nên tồi tệ hơn.
Đôi khi mọi người sẽ nói "Tôi muốn hỗ trợ 2000 người dùng, với thời gian phản hồi nhanh." Nó được đảm bảo khá nhiều rằng nếu bạn cố gắng làm điều đó với 2000 kết nối cơ sở dữ liệu thực tế, hiệu suất sẽ rất kinh khủng. Nếu bạn có một máy với bốn bộ xử lý lõi tứ và tập dữ liệu đang hoạt động được lưu vào bộ nhớ đệm đầy đủ, bạn sẽ thấy hiệu suất tốt hơn nhiều cho 2000 người dùng đó bằng cách sắp xếp các yêu cầu thông qua khoảng 35 kết nối cơ sở dữ liệu.
Để hiểu tại sao điều đó lại đúng, thử nghiệm suy nghĩ này sẽ hữu ích. Hãy xem xét một máy chủ cơ sở dữ liệu giả định chỉ có một tài nguyên để chia sẻ - một lõi duy nhất. Phần lõi này sẽ phân chia thời gian như nhau giữa tất cả các yêu cầu đồng thời mà không có chi phí. Giả sử 100 yêu cầu đến cùng một lúc, mỗi yêu cầu cần một giây thời gian CPU. Cốt lõi hoạt động trên tất cả chúng, cắt thời gian giữa chúng cho đến khi tất cả hoàn thành 100 giây sau đó. Bây giờ hãy xem xét điều gì sẽ xảy ra nếu bạn đặt trước một nhóm kết nối sẽ chấp nhận 100 kết nối máy khách nhưng chỉ thực hiện một yêu cầu tại một thời điểm đến máy chủ cơ sở dữ liệu, đưa bất kỳ yêu cầu nào đến trong khi kết nối đang bận vào hàng đợi. Giờ đây, khi 100 yêu cầu đến cùng một lúc, một khách hàng sẽ nhận được phản hồi sau 1 giây; một người khác nhận được phản hồi trong 2 giây và khách hàng cuối cùng nhận được phản hồi sau 100 giây. Không ai phải đợi lâu hơn để nhận được phản hồi, thông lượng là như nhau, nhưng độ trễ trung bình là 50,5 giây thay vì 100 giây.
Một máy chủ cơ sở dữ liệu thực có nhiều tài nguyên hơn có thể được sử dụng song song, nhưng cùng một nguyên tắc, một khi chúng bão hòa, bạn chỉ làm tổn hại mọi thứ bằng cách thêm nhiều yêu cầu cơ sở dữ liệu đồng thời hơn. Nó thực sự tồi tệ hơn ví dụ, bởi vì với nhiều tác vụ hơn, bạn có nhiều công tắc tác vụ hơn, tăng tranh chấp về khóa và bộ đệm, tranh chấp dòng bộ đệm L2 và L3 và nhiều vấn đề khác ảnh hưởng đến cả thông lượng và độ trễ. Trên hết, trong khi work_mem cao cài đặt có thể trợ giúp truy vấn theo một số cách, cài đặt đó là giới hạn mỗi nút kế hoạch cho mỗi kết nối , vì vậy với một số lượng lớn các kết nối, bạn cần để nó rất nhỏ để tránh bộ nhớ cache bị xóa hoặc thậm chí dẫn đến hoán đổi, dẫn đến kế hoạch chậm hơn hoặc những thứ như bảng băm tràn vào đĩa.
Một số sản phẩm cơ sở dữ liệu xây dựng một nhóm kết nối vào máy chủ một cách hiệu quả, nhưng cộng đồng PostgreSQL đã cho rằng vì việc gộp kết nối tốt nhất được thực hiện gần hơn với phần mềm máy khách, họ sẽ giao việc này cho người dùng quản lý. Hầu hết những kẻ đánh cắp sẽ có một số cách để giới hạn các kết nối cơ sở dữ liệu ở một số cứng, đồng thời cho phép nhiều yêu cầu khách đồng thời hơn thế, xếp chúng vào hàng đợi khi cần thiết. Đây là những gì bạn muốn và nó phải được thực hiện trên giao dịch cơ sở, không theo tuyên bố hoặc kết nối.
