Câu trả lời:
Tôi sẽ tập trung vào hành vi của khách hàng chậm và cách cấu hình của bạn xử lý nó, nhưng đừng cố tin rằng đó là lợi ích duy nhất. Phương pháp tương tự có lợi cho khách hàng chậm cũng có lợi ích cho khách hàng nhanh, xử lý SSL, xử lý sự gia tăng lưu lượng truy cập và các khía cạnh khác của việc phục vụ HTTP trên Internet.
Gunicorn là phần mềm pre-forking. Đối với truyền thông có độ trễ thấp, chẳng hạn như cân bằng tải đến máy chủ ứng dụng hoặc liên lạc giữa các dịch vụ, hệ thống tiền ngã ba có thể rất thành công. Không có chi phí trong việc tạo ra một quy trình để xử lý yêu cầu và một quy trình duy nhất có thể được dành riêng để xử lý một yêu cầu; việc loại bỏ những điều này có thể dẫn đến một hệ thống tổng thể nhanh hơn, hiệu quả hơn cho đến khi số lượng kết nối đồng thời vượt quá số lượng quy trình có sẵn để xử lý chúng.
Trong tình huống của bạn, bạn đang đối phó với các khách hàng có độ trễ cao qua internet. Những khách hàng chậm chạp có thể buộc các quá trình tương tự. Khi QPS có vấn đề, mã ứng dụng cần nhận, xử lý và giải quyết yêu cầu càng nhanh càng tốt để có thể chuyển sang yêu cầu khác. Khi khách hàng chậm giao tiếp trực tiếp với hệ thống của bạn, họ sẽ kết nối quy trình đó và làm chậm nó. Thay vì xử lý và xử lý yêu cầu càng nhanh càng tốt, quy trình đó bây giờ cũng phải chờ khách hàng chậm. QPS hiệu quả đi xuống.
Xử lý số lượng lớn kết nối với rất ít cpu và chi phí bộ nhớ là điều mà các máy chủ không đồng bộ như Nginx rất giỏi. Họ không bị ảnh hưởng theo cách tiêu cực tương tự bởi các khách hàng chậm vì họ có khả năng xử lý đồng thời số lượng lớn khách hàng. Trong trường hợp của Nginx, chạy trên phần cứng hiện đại, nó có thể xử lý hàng chục ngàn kết nối cùng một lúc.
Nginx trước một máy chủ pre-forking là một sự kết hợp tuyệt vời. Nginx xử lý giao tiếp với khách hàng và không bị phạt vì xử lý các khách hàng chậm. Nó gửi các yêu cầu đến phụ trợ nhanh nhất vì phụ trợ có thể xử lý các yêu cầu đó, cho phép phụ trợ có hiệu quả với tài nguyên máy chủ nhất có thể. Phần cuối trả về kết quả ngay khi tính toán và bộ đệm Nginx phản hồi để cung cấp cho khách hàng chậm theo tốc độ của riêng họ. Trong khi đó, phần phụ trợ có thể chuyển sang xử lý một yêu cầu khác ngay cả khi máy khách chậm vẫn nhận được kết quả.
@blueben nói đúng. Một ví dụ cụ thể và phổ biến về những gì có thể xảy ra khi proxy ngược không được sử dụng là cơ sở dữ liệu phụ trợ có thể chạy hết các kết nối cơ sở dữ liệu xử lý khi không có proxy và có lưu lượng truy cập tăng đột biến. Điều này là do các kết nối bị chậm phát hành như @blueben mô tả.
Một bản năng đầu tiên để thấy các cơ sở dữ liệu xử lý hết có thể là để hỗ trợ nhiều kết nối cơ sở dữ liệu hơn. Nhưng bằng cách thêm proxy ngược trước ứng dụng, bạn sẽ thấy số lượng kết nối cơ sở dữ liệu cần thiết cho tải cao giảm đáng kể và ổn định - mức kết nối cơ sở dữ liệu sẽ không tăng đột biến khi có lưu lượng truy cập tăng đột biến.
Nginx cũng tuyệt vời trong việc phục vụ nội dung tĩnh, bộ nhớ đệm và nhiều tác vụ HTTP khác, cho phép máy chủ ứng dụng của bạn tập trung vào việc trở thành một máy chủ ứng dụng.