Это зависит от протокола и варианта использования для балансировки. Для всего, где количество подключений коррелирует с нагрузкой / использованием, лучше использовать lessconn . Из-за того, как работают сети и приложения, это почти всегда верно, и вам лучше использовать по умолчанию lessconn .

Удаленные рабочие столы RDP / X11 / Jump Hosts

Например, компания имеет пул удаленных рабочих столов, к которым подключаются сотрудники. Вы бы хотели, чтобы сотрудники распределялись по рабочим столам примерно равномерно.

Количество активных подключений в этом варианте использования примерно равно «сколько сотрудников используют этот рабочий стол прямо сейчас». На хосте с наименьшим количеством подключений меньше всего его используют сотрудники и, вероятно, он наименее загружен. В таких случаях используйте команду "leastconn", она равномерно распределяет нагрузку по количеству пользователей.

Идеальный балансировщик нагрузки должен учитывать нагрузку на удаленный рабочий стол. Сколько пользователей? Сколько приложений? Сколько потребляется памяти и процессора? Существуют коммерческие решения, предназначенные для удаленных рабочих столов (Microsoft / Citrix / и т. Д.), Они обычно измеряют эти показатели, чтобы очень хорошо распространять использование. HAProxy - это простой балансировщик сетевой нагрузки, и он не может лучше, чем подсчет подключений с помощью lessconn .

HTTP / HTTPS

В случае HTTP активное соединение означает, что сервер занят обработкой запроса . Подключения прямо пропорциональны нагрузке. Вы хотите выбрать сервер с наименьшим количеством активных подключений (выполняемых запросов). Используйте lessconn для HTTP (S) трафика.

Представьте себе сценарий с двумя серверами HTTP, где один сервер медленнее обрабатывает запросы (возможно, он перегружен, может быть, у него более старое оборудование).

roundrobin распределяет половину запросов между двумя серверами. Это очень неэффективно, более быстрый сервер должен занять больше. Что еще хуже, более медленный сервер может быть перегружен, он станет еще медленнее по мере поступления новых запросов и может начать отбрасывать запросы в любое время. Вы этого не хотите.

leastconn обнаружит, что серверы работают неравномерно. Более медленный сервер дольше держит соединения, у него больше соединений. lessconn учитывает это и предпочитает другой сервер.

По моему опыту, включая роли, в которых я проводил тестирование производительности исключительно для средних и крупных веб-сайтов. minimumconn может быть на 300% эффективнее, чем roundrobin для HTTP (S). roundrobin не распределяет соединение справедливо, и это вызовет нестабильность при высокой нагрузке.

DNS Request

(Давайте проигнорируем, что HAProxy не поддерживает UDP, а UDP не поддерживает соединение).

И последний пример. DNS - это простой протокол. Клиенты отправляют одно сообщение UDP для запроса домена, а DNS-сервер отвечает одним сообщением.

В данном случае связи на самом деле нет. Даже если бы были, он бы моментально закрылся (теоретически).

В таких условиях нет смысла подсчитывать соединения, это не оптимально для lessconn . Простой roundrobin может распространять сообщения.

Распространенное недоразумение

Иногда люди считают, что не следует использовать lessconn для краткосрочных соединений (аналогично последнему примеру). Даже документация 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]

В реальном мире короткие соединения не имеют значения.

Приложения создаются поверх TCP. Сообщения доставляются и часто обрабатываются по порядку. Когда сервер работает медленно или перегружен, «короткие» соединения становятся длиннее. Если есть (больше) соединений, вероятно, есть (больше) работа. Количество подключений и продолжительность подключения различаются и имеют значение.

Представьте себе простой HTTP-сервер. Некоторые ресурсы занимают несколько миллисекунд, некоторые вызовы API - несколько секунд, страница может занять любое время для загрузки с любым количеством запросов внутри нее и т.д. lessconn понимает текущую активность и регулирует распределение, что именно то, что вы хотите от балансировщика нагрузки.