Khi định cấu hình HA Proxy, làm thế nào để bạn quyết định giá trị nào được gán cho thời gian chờ? Tôi đã đọc một nửa tá mẫu trên các blog khác nhau và mọi người sử dụng thời gian chờ khác nhau và không ai thảo luận về lý do tại sao.

HAProxy dường như đặc biệt lo lắng về máy khách, kết nối và máy chủ, mà HAPRoxy đưa ra cảnh báo nếu bạn không hoàn toàn không đặt:

While not properly invalid, you will certainly encounter various problems
with such a configuration. To fix this, please ensure that all following
timeouts are set to a non-zero value: 'client', 'connect', 'server'.

Các tài liệu hướng dẫn là vô ích trong vấn đề này: nó cho thấy "bội hơi trên 3 giây" nhưng không phải lý do tại sao bạn muốn chọn một bội số của 1 vs 100 hoặc 42.

RPM tôi đang sử dụng (kho lưu trữ Amazon Linux) đặt các giá trị mặc định này:

timeout connect         10s
timeout client          1m
timeout server          1m

Hai trong số đó là bội số chính xác của 3 giây, vi phạm lời khuyên chính thức duy nhất tôi từng thấy.

Nếu bạn không có lời khuyên điều chỉnh cụ thể, có thể một câu hỏi dễ dàng hơn là: tôi nên làm gì sai với thời gian chờ thực sự ngắn hoặc thực sự dài?

TCP RTO (nhận thời gian chờ) bắt đầu sau ba giây. ( RFC 1122 ) Nếu một gói được truyền không có xác nhận được trả lại trong thời gian đó, thì nó được coi là bị mất và được truyền lại. Điều này gần như chắc chắn là những gì tác giả đang đề cập đến. (Lưu ý rằng RTO được điều chỉnh tăng hoặc giảm động bởi các thuật toán khác nhau , nằm ngoài phạm vi của câu hỏi này.)

Hãy nhớ rằng điều này thực sự chỉ áp dụng cho các kết nối giữa máy chủ lối vào của bạn và máy khách (tức là người dùng web). Trong các trường hợp thông thường, các kết nối giữa HAProxy và các máy chủ phụ trợ của bạn phải ở trên mạng LAN và bạn nên sử dụng thời gian chờ ngắn hơn nhiều, để các phụ trợ bị hỏng được đưa ra khỏi dịch vụ sớm hơn.

Đối với người dùng web của bạn, một số trong số họ có thể có kết nối độ trễ rất cao, chẳng hạn như vệ tinh và có thể có trải nghiệm cao hơn so với truyền lại thông thường do điều này. RTT trên kết nối sử dụng vệ tinh có thể vượt quá 2000 ms ngay cả khi tất cả đều ổn.

Với tất cả những điều này, bạn thường sẽ muốn thời gian chờ rất ngắn và thời gian timeout connectrất dài timeout client.

Đối với timeout server, điều này phụ thuộc vào ứng dụng web của bạn. Khi đặt thời gian chờ, hãy xem xét mức độ phức tạp của ứng dụng web đang được phục vụ và mất bao lâu trong trường hợp xấu nhất để xử lý một yêu cầu phức tạp. Nếu nghi ngờ, hãy nâng giá trị lên.

Lời tựa

Tôi đã điều chỉnh HAProxy một thời gian và thực hiện rất nhiều thử nghiệm hiệu năng trên nó. Từ 100 yêu cầu HTTP / s đến 50 000 yêu cầu HTTP / s.

Lời khuyên đầu tiên là kích hoạt trang thống kê trên HAProxy . Bạn CẦN giám sát, không có ngoại lệ. Bạn cũng sẽ cần tinh chỉnh nếu bạn dự định vượt quá 10.000 yêu cầu / s.

Thời gian chờ là một con thú khó hiểu bởi vì chúng có một phạm vi lớn các giá trị có thể, hầu hết chúng không có sự khác biệt có thể quan sát được. Tôi vẫn chưa thấy điều gì thất bại vì con số thấp hơn 5% hoặc cao hơn 5%. 10000 so với 11000 mili giây, ai quan tâm? Có lẽ không phải hệ thống của bạn.

Cấu hình

Trong lương tâm tôi không thể đưa ra một vài con số là 'thời gian chờ tốt nhất cho mọi người'.

Thay vào đó, điều tôi có thể nói là thời gian chờ tích cực nhất, luôn chấp nhận được đối với cân bằng tải HTTP (S). Nếu bạn gặp phải mức thấp hơn mức này, đã đến lúc cấu hình lại bộ cân bằng tải của bạn.

timeout connect 5000
timeout check 5000
timeout client 30000
timeout server 30000

khách hàng hết thời gian chờ:

Thời gian chờ không hoạt động được áp dụng khi khách hàng dự kiến ​​sẽ xác nhận hoặc gửi dữ liệu. Trong chế độ HTTP, thời gian chờ này đặc biệt quan trọng để xem xét trong giai đoạn đầu tiên, khi máy khách gửi yêu cầu và trong khi phản hồi trong khi nó đang đọc dữ liệu được gửi bởi máy chủ.

Đọc : Đây là thời gian tối đa để nhận các tiêu đề yêu cầu HTTP từ máy khách.

Đôi khi 3G / 4G / 56k / vệ tinh có thể bị chậm. Tuy nhiên, họ sẽ có thể gửi các tiêu đề HTTP trong vài giây, KHÔNG phải 30.

Nếu ai đó có kết nối tệ đến mức cần hơn 30 giây để yêu cầu một trang (sau đó hơn 10 * 30 để yêu cầu 10 hình ảnh nhúng / CSS / JS), tôi tin rằng có thể từ chối anh ta.

máy chủ thời gian chờ:

Thời gian chờ không hoạt động được áp dụng khi máy chủ dự kiến ​​sẽ xác nhận hoặc gửi dữ liệu. Trong chế độ HTTP, thời gian chờ này đặc biệt quan trọng để xem xét trong giai đoạn đầu phản hồi của máy chủ, khi nó phải gửi các tiêu đề, vì nó trực tiếp thể hiện thời gian xử lý yêu cầu của máy chủ. Để tìm ra giá trị nào được đặt ở đó, thường bắt đầu với giá trị được coi là thời gian phản hồi không được chấp nhận, sau đó kiểm tra nhật ký để quan sát phân phối thời gian đáp ứng và điều chỉnh giá trị phù hợp.

Đọc : Đây là thời gian tối đa để nhận các tiêu đề phản hồi HTTP từ máy chủ (sau khi nhận được yêu cầu máy khách đầy đủ). Về cơ bản, đây là thời gian xử lý từ các máy chủ của bạn, trước khi nó bắt đầu gửi phản hồi.

Nếu máy chủ của bạn chậm đến mức cần hơn 30 giây để bắt đầu đưa ra câu trả lời, thì tôi tin rằng có thể chấp nhận được khi xem xét nó đã chết.

Trường hợp đặc biệt : Một số dịch vụ RARE thực hiện xử lý rất nặng có thể mất toàn bộ thời gian hoặc nhiều hơn để đưa ra câu trả lời. Thời gian chờ này có thể cần phải tăng lên rất nhiều cho việc sử dụng cụ thể này. (Lưu ý: Đây có thể là trường hợp thiết kế xấu, sử dụng giao tiếp kiểu không đồng bộ hoặc hoàn toàn không sử dụng HTTP.)

thời gian chờ kết nối:

Đặt thời gian tối đa để chờ kết nối đến máy chủ thành công.

Đọc : Thời gian tối đa mà máy chủ phải chấp nhận kết nối TCP.

Các máy chủ nằm trong cùng mạng LAN với HAProxy nên sẽ nhanh. Hãy dành ít nhất 5 giây bởi vì đó sẽ mất bao lâu khi có bất cứ điều gì bất ngờ xảy ra (một gói TCP bị mất để truyền lại, một máy chủ yêu cầu một quy trình mới để thực hiện các yêu cầu mới, tăng lưu lượng truy cập).

Trường hợp đặc biệt : Khi các máy chủ ở trong một mạng LAN khác hoặc qua một liên kết không đáng tin cậy. Thời gian chờ này có thể cần phải tăng lên rất nhiều. (Lưu ý: Đây có thể là một trường hợp kiến ​​trúc xấu.)

kiểm tra thời gian chờ:

Đặt thời gian kiểm tra bổ sung, nhưng chỉ sau khi kết nối đã được thiết lập.

Đặt thời gian chờ kiểm tra bổ sung, nhưng chỉ sau khi đã có kết nối Nếu được đặt, haproxy sử dụng min ("thời gian chờ kết nối", "inter") làm thời gian chờ kết nối để kiểm tra và "kiểm tra thời gian chờ" làm thời gian chờ đọc thêm. "Min" được sử dụng để những người đang chạy với "thời gian chờ kết nối" rất dài (ví dụ: những người cần điều này do hàng đợi hoặc tarpit) không làm chậm kiểm tra của họ. (Xin lưu ý rằng không có lý do hợp lệ để có thời gian chờ kết nối dài như vậy, bởi vì "hàng đợi hết thời gian" và "tarpit hết thời gian" luôn có thể được sử dụng để tránh điều đó).

Đọc : Khi thực hiện kiểm tra sức khỏe, máy chủ timeout connectphải chấp nhận kết nối sau đó timeout checkđể đưa ra phản hồi.

Tất cả các máy chủ PHẢI có kiểm tra sức khỏe HTTP (S) được cấu hình. Đó là cách duy nhất để bộ cân bằng tải biết máy chủ có khả dụng hay không. Healthcheck là một /isalivetrang đơn giản luôn trả lời OK.

Hết thời gian chờ này ít nhất 5 giây vì đó là khoảng thời gian có thể xảy ra khi có bất cứ điều gì bất ngờ xảy ra (gói TCP bị mất để truyền lại, máy chủ yêu cầu một quy trình mới để thực hiện các yêu cầu mới, tăng lưu lượng truy cập).

Câu chuyện chiến tranh : Rất nhiều người tin sai rằng máy chủ luôn có thể trả lời trang đơn giản này trong 3 ms. Họ đặt thời gian chờ tích cực (<2000ms) với chuyển đổi dự phòng tích cực (2 kiểm tra không thành công = máy chủ đã chết). Tôi đã thấy toàn bộ trang web đi xuống vì điều đó. Thông thường, lưu lượng truy cập tăng đột biến, máy chủ phụ trợ chậm hơn, kiểm tra sức khỏe bị trì hoãn ... cho đến khi đột nhiên tất cả cùng hết thời gian, HAProxy nghĩ rằng TẤT CẢ các máy chủ đã chết cùng một lúc và toàn bộ trang web ngừng hoạt động.