답변:
최소 conn을 실험하지는 않았지만 가장 오래 사용하는 연결은 오래 지속될 수있는 무언가를로드 밸런싱 할 때 가장 많이 사용되는 것입니다. 그 이유는 로드 로빈이보다 균형 잡힌 도착 속도를 제공 할 예정인 균형 잡힌 동시성 을 보장하는 데 최소한의 초점을 맞추기 때문 입니다. 이 차이점이 명확하지 않은 경우 차이점에 대한 내 대답을 참조하십시오 .
로드가 고르게 분산되지 않았다고하면 "로드"를 조금 더 잘 정의하는 데 도움이 될 수 있습니다. 서버 리소스를 의미한다면,로드를 증가시키는 원인 (예 : 특정 유형의 연결)을 정확히 파악하고 그 뒤로 거꾸로 작업하는 것이 좋습니다.
프로토콜은 무엇이며 균형을 맞추기위한 사용 사례에 따라 다릅니다. 연결의 양이로드 / 사용과 상관이있는 경우에는 사용하는 것이 좋습니다 leastconn. 네트워크와 응용 프로그램이 작동하는 방식 때문에 거의 항상 사실이며 leastconn기본적으로 사용 하는 것이 좋습니다 .
예를 들어 회사에는 직원들이 연결하는 원격 데스크톱 풀이 있습니다. 직원들이 데스크탑에 어느 정도 고르게 분포되기를 바랍니다.
이 유스 케이스의 활성 연결 수는 대략 "현재 얼마나 많은 직원이 해당 데스크탑을 사용하고 있는지"입니다. 연결이 가장 적은 호스트는이를 사용하는 직원이 가장 적으며로드가 가장 적은 호스트 일 수 있습니다. 이러한 상황에서 "leastconn"을 사용하면 사용자 수에 따라 부하가 고르게 분산됩니다.
이상적인로드 밸런서는 원격 데스크톱로드를 알고 있어야합니다. 얼마나 많은 사용자? 몇 개의 어플리케이션입니까? 얼마나 많은 메모리와 CPU가 소비됩니까? 원격 데스크톱 (Microsoft / Citrix / etc ...) 전용 상용 솔루션이 있으며 일반적으로 이러한 메트릭을 측정하여 사용량을 매우 잘 분산시킵니다. HAProxy는 간단한 네트워크로드 밸런서이며로 연결을 계산하는 것보다 더 나은 방법은 없습니다 leastconn.
HTTP를 사용하면 활성 연결은 서버가 요청을 처리 중임을 의미합니다. 연결은 부하에 정비례합니다. 활성 연결이 가장 적은 서버를 선택하려고합니다 (요청 진행 중). leastconnHTTP (S) 트래픽에 사용하십시오 .
하나의 서버가 요청 처리 속도가 느릴 수있는 두 개의 HTTP 서버가있는 시나리오를 상상해보십시오 (오버로드되었거나 오래된 하드웨어 일 수 있음).
roundrobin두 서버간에 절반의 요청을 분배합니다. 매우 비효율적이며 서버가 빠를수록 더 많은 시간이 소요됩니다. 더 나쁜 점은 더 느린 서버에 과부하가 걸리고 더 많은 요청이 들어 오면 더 느려져 언제든지 요청을 삭제하기 시작할 수 있다는 것입니다. 당신은 그것을 원하지 않습니다.
leastconn서버가 고르지 않음을 감지합니다. 느린 서버는 연결을 더 오래 보유하며 연결 수가 더 높습니다. leastconn이를 설명하고 다른 서버를 선호합니다.
중소 웹 사이트에 대한 성능 테스트를 독점적으로 수행 한 역할을 포함하여 내 경험상 HTTP (S) leastconn보다 300 % 효율적일 수 있습니다 roundrobin. roundrobin연결을 공평하게 분배하지 않으며 높은 부하에서 불안정성을 유발합니다.
(HAProxy는 UDP를 지원하지 않으며 UDP는 연결이 적다는 것을 무시하십시오).
마지막 예입니다. DNS는 간단한 프로토콜입니다. 클라이언트는 단일 UDP 메시지를 보내 도메인을 요청하고 DNS 서버는 단일 메시지로 응답합니다.
이 경우 실제로 연결이 없습니다. 존재하더라도 즉시 이론적으로 닫힙니다.
이러한 상황에서는 연결 수를 계산하는 것이 이치에 맞지 않습니다 leastconn. 간단한 roundrobin메시지를 배포 할 수 있습니다.
사람들은 때로는 leastconn짧은 수명의 연결 (마지막 예와 유사)에 사용해서는 안된다고 생각합니다 . HAProxy 문서조차도 오해의 소지가 있습니다.
leastconn
Use of this algorithm is recommended where very long sessions are
expected, such as LDAP, SQL, TSE, etc... but is not very well
suited for protocols using short sessions such as HTTP.
[misleading advice, should ignore it]
현실에서는 일 short connections이 아닙니다.
응용 프로그램은 TCP 위에 구축됩니다. 메시지는 순서대로 전달되고 처리됩니다. 서버가 느리거나 오버로드되면 "짧은"연결이 더 길어집니다. 연결이 더 많으면 아마도 더 많은 작업이 수행되고있을 것입니다. 연결 수와 연결 시간은 다양하며 의미가 있습니다.
기본 HTTP 서버를 생각하십시오. 일부 자산은 몇 밀리 초가 걸리고, 일부 API 호출은 몇 초가 걸리며, 페이지는 그 안에 많은 양의 요청을로드하는 데 시간이 걸릴 수 있습니다. leastconn진행중인 활동을 이해하고 분산을 조정합니다. 이는 정확히로드 밸런서에서 원하는 것입니다.