Tại sao bạn lại đặt MaxKeepAliveRequests thành bất cứ thứ gì nhưng không giới hạn?

Apache KeepAliveTimeouttồn tại để đóng kết nối duy trì nếu yêu cầu mới không được đưa ra trong một khoảng thời gian nhất định. Với điều kiện người dùng không đóng trình duyệt / tab của mình, thời gian chờ này (thường là 5-15 giây) là thứ cuối cùng sẽ đóng hầu hết các kết nối duy trì và ngăn chặn tài nguyên máy chủ bị lãng phí bằng cách giữ các kết nối vô thời hạn.

Bây giờ, lệnh MaxKeepAliveRequestsnày đặt giới hạn số lượng yêu cầu HTTP mà một kết nối TCP duy nhất (còn mở do KeepAlive) sẽ phục vụ. Đặt điều này 0có nghĩa là số lượng yêu cầu không giới hạn được cho phép.

Tại sao bạn lại đặt cái này thành bất cứ thứ gì ngoài "không giới hạn"? Với điều kiện một khách hàng vẫn đang tích cực thực hiện các yêu cầu, có hại gì khi để chúng xảy ra trên cùng một kết nối không? Khi đạt đến giới hạn, các yêu cầu vẫn đến, chỉ trên một kết nối mới.

Cách tôi nhìn thấy nó, không có điểm nào trong việc giới hạn điều này. Tôi đang thiếu gì?

Về cơ bản, vì Apache không được xây dựng cho nó. Vấn đề là sử dụng bộ nhớ máy chủ. Trong nhiều cấu hình, việc tạo nội dung được thực hiện trong cùng một quy trình như phân phối nội dung, vì vậy mỗi quy trình sẽ phát triển theo kích thước của thứ lớn nhất mà nó xử lý. Hình dung một quá trình mở rộng lên 64mb vì một tập lệnh php nặng, sau đó quá trình cồng kềnh đó đang ngồi và phục vụ các tệp tĩnh. Bây giờ nhân số đó với 100. Ngoài ra, nếu có rò rỉ bộ nhớ ở bất cứ đâu, các quy trình sẽ phát triển không giới hạn.

Các cài đặt cố định phải được cân bằng dựa trên loại nội dung và lưu lượng truy cập của bạn. Nói chung, cấu hình tối ưu có MaxKeepAliveRequests cao (100-500) và KeepAliveTimeout thấp (2-5) để giải phóng chúng nhanh chóng.

Tôi biết đây là một câu hỏi cũ, nhưng tôi đã thực hiện một số gỡ lỗi và có vẻ như (và điều này không chỉ đúng với Apache) MaxKeepAliveRequestshoạt động độc lập KeepAliveTimeout.

Có nghĩa là, chỉ thị hết thời gian chờ chỉ tính vào các kết nối liên tục không hoạt động (không đọc hoặc ghi) - nếu bạn tiếp tục yêu cầu dưới thời gian chờ, bạn hầu như có thể thực hiện một lượng yêu cầu không giới hạn trên cùng một kết nối.

Điều này có thể không tốt cho một số lý do bao gồm các kết nối tcp chạy dài bị giết ngẫu nhiên? Trong mọi trường hợp, các máy khách http không phải là ngu ngốc và có thể xử lý MaxKeepAliveRequestscài đặt "thấp" khá tốt, ví dụ như ngôn ngữ lập trình tương đối dễ dàng để phát hiện nếu kết nối tcp đã bị máy chủ đóng và do đó kết nối lại với nó. Ngoài ra, hầu hết các máy khách http sẽ tự đặt giới hạn (ví dụ: các trình duyệt sẽ đóng kết nối duy trì sau 300 giây hoặc lâu hơn).

Một lý do sẽ là để cân bằng tải. Khi kết nối liên tục hoặc http 1.1 được thực hiện, bộ cân bằng tải sẽ không di chuyển nó đến một máy chủ mới cho đến khi nó đóng lại. Nếu bạn có một khách hàng thực hiện một số lượng lớn yêu cầu qua một kết nối của họ, bạn có thể không có được sự cân bằng tốt giữa các máy chủ.

Một phần, để giữ cho một người dùng duy nhất không ăn cắp tất cả các khe kết nối. Không có giới hạn, một khách hàng độc hại hoặc viết kém có thể chiếm lấy mọi kết nối có sẵn và giữ chúng mãi mãi. Tuy nhiên, đây không phải là một sự giảm thiểu lớn cho điều đó, so với một cái gì đó như giới hạn kết nối trên mỗi IP.

Chủ yếu là cân bằng tải, nhưng đặc biệt liên quan đến bảo trì. Nếu bạn muốn đưa máy chủ ngoại tuyến, bạn thả nó xuống 0 kết nối nhưng cho phép các kết nối hiện có kết thúc trong một khoảng thời gian. Đặt giới hạn về số lượng yêu cầu giữ có nghĩa là cuối cùng người dùng sẽ duyên dáng tạo một kết nối mới và được chuyển đến một máy chủ back-end mới. Có lẽ một số cách để báo hiệu cho máy chủ rằng nó nên ngừng chấp nhận các khoản giữ lại hoàn toàn trong quá trình thoát nước sẽ còn tốt hơn, nhưng cho đến nay tôi biết một tính năng như vậy không tồn tại.