Вилли получил ответ по электронной почте. Я думал, что поделюсь им. Его ответы выделены жирным шрифтом.
У меня вопрос по конфигурации моего haproxy:
#---------------------------------------------------------------------
# Global settings
#---------------------------------------------------------------------
global
log 127.0.0.1 syslog emerg
maxconn 4000
quiet
user haproxy
group haproxy
daemon
#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will
# use if not designated in their block
#---------------------------------------------------------------------
defaults
mode http
log global
option abortonclose
option dontlognull
option httpclose
option httplog
option forwardfor
option redispatch
timeout connect 10000 # default 10 second time out if a backend is not found
timeout client 300000 # 5 min timeout for client
timeout server 300000 # 5 min timeout for server
stats enable
listen http_proxy localhost:81
balance roundrobin
option httpchk GET /empty.html
server server1 myip:80 maxconn 15 check inter 10000
server server2 myip:80 maxconn 15 check inter 10000
Как видите, это просто, но я немного смущен тем, как работают свойства maxconn.
В блоке прослушивания на сервере есть глобальный и maxconn.
И есть еще один в блоке прослушивания, который по умолчанию равен 2000.
Я думаю так: глобальный управляет общим количеством подключений, которые haproxy, как сервис, будет обрабатывать в очереди или обрабатывать одновременно.
Верный. Это максимальное количество одновременных подключений для каждого процесса.
Если число становится выше этого, он либо убивает соединение, либо пулы в каком-то сокете linux?
Позднее он просто перестает принимать новые соединения, и они остаются в очереди сокетов в ядре. Количество сокетов в очереди определяется минимальным значением (net.core.somaxconn, net.ipv4.tcp_max_syn_backlog и maxconn блока прослушивания).
Я понятия не имею, что произойдет, если число станет больше 4000.
Лишние соединения ждут завершения другого, прежде чем будут приняты. Однако, пока очередь ядра не заполнена, клиент даже не замечает этого, поскольку соединение принимается на уровне TCP, но не обрабатывается. Таким образом, клиент замечает лишь некоторую задержку обработки запроса. Но на практике maxconn блока прослушивания намного важнее, так как по умолчанию он меньше глобального. Параметр maxconn прослушивания ограничивает количество подключений на одного слушателя. В общем, разумно настроить его на количество подключений, которое вы хотите для службы, и настроить глобальный maxconn на максимальное количество подключений, которое вы разрешаете процессу haproxy. Если у вас только одна служба, для обеих может быть установлено одинаковое значение. Но когда у вас много услуг,
Затем у вас есть свойство server maxconn, установленное на 15. Во-первых, я установил его на 15, потому что мой php-fpm, он пересылается на отдельный сервер, имеет только такое количество дочерних процессов, которые он может использовать, поэтому я уверен, что объединение запросов здесь, а не в php-fpm. Что, я думаю, быстрее.
Да, это не только должно быть быстрее, но и позволяет haproxy находить другой доступный сервер, когда это возможно, а также позволяет ему убивать запрос в очереди, если клиент нажимает «стоп» до того, как соединение будет перенаправлено на сервер.
Но, возвращаясь к теме, моя теория об этом количестве заключается в том, что каждому серверу в этом блоке будет отправляться только 15 соединений за раз. И тогда соединения будут ждать открытого сервера. Если бы у меня были куки-файлы, соединения будут ждать ПРАВИЛЬНОГО открытого сервера. Но я этого не делаю.
Это в точности принцип. Есть очередь на прокси и очередь на сервер. Соединения с сохраняемым cookie попадают в очередь сервера, а другие соединения - в очередь прокси. Однако, поскольку в вашем случае cookie не настроен, все подключения попадают в очередь прокси. Вы можете посмотреть диаграмму doc / queuing.fig в источниках haproxy, если хотите, она объясняет, как и где принимаются решения.
Итак, вопросы:
Что произойдет, если количество глобальных подключений превысит 4000? Они умирают? Или пул в линуксе как-нибудь?
В Linux они стоят в очереди. Как только вы перегружаете очередь ядра, они теряются в ядре.
Связано ли глобальное соединение с подключениями к серверу, кроме того факта, что у вас не может быть общего количества подключений к серверу больше глобального?
Нет, глобальные настройки и настройки подключения к серверу не зависят.
При выяснении глобальных подключений, не должно ли это быть количество подключений, добавленных в раздел сервера, плюс определенный процент для пула? И, очевидно, у вас есть другие ограничения на соединения, но действительно сколько вы хотите отправить на прокси?
Вы все правильно поняли. Если время отклика вашего сервера невелико, нет ничего плохого в том, чтобы поставить в очередь тысячи соединений для обслуживания только нескольких одновременно, поскольку это существенно сокращает время обработки запроса. На практике установление соединения в настоящее время занимает около 5 микросекунд в гигабитной локальной сети. Поэтому имеет смысл разрешить haproxy максимально быстро распределять соединения из своей очереди на сервер с очень маленьким maxconn. Я помню, как один игровой сайт создавал в очереди более 30000 одновременных подключений и работал с очередью по 30 на сервер! Это был сервер apache, и apache намного быстрее при небольшом количестве подключений, чем при большом. Но для этого вам действительно нужен быстрый сервер, потому что вы не Я хочу, чтобы все ваши клиенты стояли в очереди в ожидании слота подключения, потому что, например, сервер ожидает базу данных. Также очень хорошо работает выделение серверов. Если на вашем сайте много статики, вы можете направить статические запросы в пул серверов (или кешей), чтобы не ставить статические запросы на них в очередь и чтобы статические запросы не занимали дорогие слоты для подключения. Надеясь, что это поможет, Вилли