HA 프록시를 구성 할 때 시간 초과에 할당 할 값을 어떻게 결정합니까? 다양한 블로그에서 수십 개의 샘플을 읽었으며 모든 사람이 다른 시간 제한을 사용하며 아무도 이유를 논의하지 않습니다.

HAProxy는 클라이언트, 연결 및 서버에 대해 특별히 걱정하는 것 같습니다. HAPRoxy는 사용자가 완전히 설정하지 않은 경우 경고를 표시합니다.

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'.

문서는 이 점에서 도움이되지이다 : 그것은 "삼초의 약간 위의 배수"를 제안하지만 당신은 왜 100 42 대 1의 배수를 선택할 것 없습니다.

사용중인 RPM (Amazon Linux 리포지토리)은 다음 기본값을 설정합니다.

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

그 중 두 개는 3 초의 정확한 배수로, 내가 본 유일한 공식 조언을 위반합니다.

특정 튜닝 조언이없는 경우 더 쉬운 질문은 다음과 같습니다. 시간이 너무 짧거나 길면 어떻게 될까요?

TCP RTO (수신 제한 시간)는 3 초에 시작됩니다. ( RFC 1122 ) 전송 된 패킷이 그 시점에 확인 응답을받지 못하면, 손실 된 패킷과 재전송 된 것으로 간주됩니다. 이것은 저자가 언급 한 거의 확실합니다. RTO는 이 질문의 범위를 벗어난 다양한 알고리즘에 의해 동적으로 조정되거나 조정됩니다 .

이는 실제로 프론트 엔드 서버와 클라이언트 (예 : 웹 사용자) 간의 연결에만 적용됩니다. 일반적인 시나리오에서는 HAProxy와 백엔드 서버 간의 연결이 LAN에 있어야하며 훨씬 짧은 시간 초과를 사용하여 오작동 백엔드가 더 빨리 서비스를 중단하도록해야합니다.

웹 사용자의 경우 일부는 위성과 같이 대기 시간이 매우 긴 연결에있을 수 있으며 이로 인해 일반 재전송보다 더 많이 발생할 수 있습니다. 위성이 사용중인 연결의 RTT는 모두 정상이지만 2000ms를 초과 할 수 있습니다.

이 모든 것을 염두에두고 일반적으로에 대한 매우 짧은 시간 초과 timeout connect및에 대한 매우 긴 시간 초과를 원할 것입니다 timeout client.

의 경우 timeout server이는 웹 애플리케이션에 따라 다릅니다. 시간 초과를 설정할 때는 제공되는 웹 앱의 복잡성과 복잡한 요청을 처리하는 데 최악의 시간이 걸릴 수있는 시간을 고려하십시오. 의심스러운 경우 값을 올리십시오.

머리말

나는 HAProxy를 잠시 동안 튜닝 해 왔으며 그것에 대한 많은 성능 테스트를 수행했습니다. 100 개의 HTTP 요청에서 50000 개의 HTTP 요청까지

첫 번째 조언은 HAProxy에서 통계 페이지 를 활성화하는 것 입니다. 예외없이 모니터링이 필요합니다. 10,000 번의 요청을 초과하려는 경우 미세 조정이 필요합니다.

시간 초과는 가능한 범위의 값이 많고 대부분 눈에 띄는 차이가 없기 때문에 혼란스러운 짐승입니다. 5 % 더 낮거나 5 % 더 높기 때문에 실패한 것을 아직 보지 못했습니다. 10000 대 11000 밀리 초, 누가 신경 쓰나요? 아마 당신의 시스템이 아닙니다.

구성

나는 양심적으로 '모든 사람을위한 최고의 타임 아웃'으로 몇 개의 숫자를 줄 수 없습니다.

대신 내가 말할 수있는 것은 HTTP (S)로드 밸런싱에 항상 허용되는 가장 공격적인 시간 초과입니다. 이보다 낮은 경우로드 밸런서를 재구성 할 차례입니다.

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

타임 아웃 클라이언트 :

비 활동 시간 초과는 클라이언트가 데이터를 확인하거나 전송할 것으로 예상되는 경우에 적용됩니다. HTTP 모드에서이 시간 초과는 첫 번째 단계, 클라이언트가 요청을 보낼 때 및 서버가 보낸 데이터를 읽는 동안 응답하는 동안 고려해야합니다.

읽기 : 클라이언트로부터 HTTP 요청 헤더 를받는 최대 시간 입니다.

3G / 4G / 56k / 위성 속도는 때때로 느려질 수 있습니다. 여전히 30 초가 아닌 몇 초 안에 HTTP 헤더를 보낼 수 있어야합니다.

누군가 연결이 너무 나빠서 페이지를 요청하는 데 30 초 이상이 필요하면 (10 개의 내장 이미지 / CSS / JS를 요청하려면 10 * 30 초 이상), 나는 그를 거부하는 것이 용납 될 수 있다고 생각합니다.

타임 아웃 서버 :

비 활동 시간 초과는 서버가 데이터를 승인하거나 전송할 것으로 예상되는 경우에 적용됩니다. HTTP 모드에서이 시간 초과는 서버가 요청에 대한 서버의 처리 시간을 직접 나타내므로 헤더를 보내야 할 때 서버 응답의 첫 번째 단계에서 고려하는 것이 특히 중요합니다. 어떤 값을 넣어야하는지에 대해서는, 허용 할 수없는 응답 시간으로 시작한 다음 로그를 확인하여 응답 시간 분포를 관찰하고 그에 따라 값을 조정하는 것이 좋습니다.

읽기 : 서버에서 전체 클라이언트 요청을받은 후 HTTP 응답 헤더 를 수신 할 수있는 최대 시간 입니다. 기본적으로 응답을 보내기 전에 서버에서 처리하는 시간입니다.

서버가 너무 느려서 답변을 시작하기 위해 30 대 이상이 필요한 경우 서버를 죽인 것으로 간주하는 것이 좋습니다.

특수 사례 : 매우 많은 처리를 수행하는 일부 RARE 서비스는 답변을 제공하는 데 1 분 이상 걸릴 수 있습니다. 이 특정 사용을 위해이 시간 제한을 많이 늘려야 할 수도 있습니다. (참고 : 이것은 디자인이 잘못되었거나 비동기 스타일 통신을 사용하거나 HTTP를 전혀 사용하지 않는 경우 일 수 있습니다.)

타임 아웃 연결 :

서버와의 연결 시도가 성공하기를 기다리는 최대 시간을 설정하십시오.

읽기 : 서버가 TCP 연결을 수락해야하는 최대 시간입니다.

서버는 HAProxy와 동일한 LAN에 있으므로 속도가 빠릅니다. 예상치 못한 상황 (재전송 할 TCP 패킷 손실, 새 프로세스를 요청하는 새 프로세스를 요청하는 서버, 트래픽 급증)이 발생할 때 시간이 오래 걸리기 때문에 최소 5 초를 제공하십시오.

특수 사례 : 서버가 다른 LAN에 있거나 신뢰할 수없는 링크를 통해있는 경우. 이 시간 초과를 많이 늘려야 할 수도 있습니다. (참고 : 아키텍처가 잘못되었을 수 있습니다.)

타임 아웃 확인 :

연결이 이미 설정된 후에 만 ​​추가 확인 시간 초과를 설정하십시오.

추가 점검 시간 초과 설정 (연결이 이미 설정된 후에 만) haproxy는 min ( "timeout connect", "inter")을 점검을위한 연결 시간 초과로 사용하고 "timeout check"를 추가 읽기 시간 초과로 사용합니다. "최소"는 매우 긴 "시간 초과 연결"로 실행하는 사람들 (예 : 대기열 또는 타르 핏으로 인해 필요한 사람들)이 점검 속도를 늦추지 않도록 사용됩니다. 또한 "timeout queue"및 "timeout tarpit"을 사용하여 항상이를 방지 할 수 있으므로 연결 시간이 오래 걸리는 유효한 이유는 없습니다.

읽기 : 상태 확인을 수행 할 때 서버는 timeout connect연결을 수락 한 다음 timeout check응답을 제공해야합니다.

모든 서버에는 HTTP (S) 상태 확인이 구성되어 있어야합니다. 이것이로드 밸런서가 서버를 사용할 수 있는지 여부를 알 수있는 유일한 방법입니다. 상태 확인은 /isalive항상 간단한 페이지 OK입니다.

예상치 못한 상황 (재전송 할 TCP 패킷 손실, 새 프로세스를 요청하는 새 프로세스를 요청하는 서버, 트래픽 급증)이 발생할 때 시간이 오래 걸리기 때문에이 제한 시간을 5 초 이상으로 지정하십시오.

전쟁 이야기 : 많은 사람들 이 서버가 항상이 간단한 페이지에 3ms 안에 응답 할 수 있다고 잘못 믿고 있습니다. 공격적인 페일 오버 (2 개의 실패한 검사 = 서버 작동 불능)로 공격적인 시간 초과 (<2000ms)를 설정했습니다. 그로 인해 전체 웹 사이트가 다운되는 것을 보았습니다. 일반적으로 트래픽이 약간 급증하고 백엔드 서버가 느려지고 상태 확인이 지연됩니다. 갑자기 모든 시간이 함께 시간 초과 될 때까지 HAProxy는 모든 서버가 한 번에 죽었고 전체 사이트가 다운되었다고 생각합니다.