Вилли получил мне ответ по электронной почте.Я думал, что поделюсь этим.Его ответы выделены жирным шрифтом.
У меня есть вопрос по поводу моей конфигурации 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 обрабатывать.Когда у вас есть только один сервис, оба могут быть установлены на одно и то же значение.Но когда у вас много служб, вы легко можете понять, что это имеет огромное значение, так как вы не хотите, чтобы одна служба принимала все соединения и не позволяла другим работать.
Тогда выустановите для свойства maxconn сервера значение 15. Во-первых, я установил это значение равным 15, потому что мой php-fpm пересылает его на отдельный сервер, имеет только столько дочерних процессов, которые он может использовать, поэтому я проверяю, объединяю ли я в пулзапросы здесь, а не в php-fpm.Который я думаю быстрее.
Да, он не только должен быть быстрее, но и позволяет haproxy находить другой доступный сервер при любой возможности, а также позволяет ему убить запрос в очереди, если клиент нажимает «stop» раньшесоединение переадресовано на сервер.
Но вернемся к этой теме, моя теория об этом числе состоит в том, что каждому серверу в этом блоке будет отправляться только 15 соединений одновременно.И тогда соединения будут ждать открытого сервера.Если бы у меня были cookie-файлы, соединения ожидали бы ПРАВИЛЬНОГО открытого сервера.Но я не знаю.
Это именно тот принцип.Существует очередь для прокси-сервера и очередь для сервера.Соединения с постоянным файлом cookie отправляются в очередь на сервер, а другие соединения - в очередь прокси.Однако, поскольку в вашем случае не настроен файл cookie, все соединения идут в очередь прокси.Вы можете посмотреть на диаграмму doc / queuing.fig в источниках haproxy, если хотите, она объясняет, как / где принимаются решения.
Итак, вопросы:
Что произойдет, если глобальные подключения превысят 4000?Они умирают?Или пул в Linux как-то?
Они стоят в очереди в Linux.Когда вы перегружаете очередь ядра, они сбрасываются в ядре.
Являются ли глобальные соединения связанными с соединениями с сервером, за исключением того факта, что вы не можете иметьобщее число подключений к серверу больше, чем глобальное?
Нет, глобальные и серверные настройки подключения не зависят.
При вычислении глобальных связей, не должно ли быть количество
соединения, добавленные в разделе сервера, плюс определенный процент для
Объединив? И, очевидно, у вас есть другие ограничения на связи, но
неужели это сколько вы хотите отправить на прокси?
Вы правильно поняли. Если время отклика вашего сервера короткое, ничего нет
неправильно ставить в очередь тысячи соединений, чтобы обслуживать только несколько одновременно,
потому что это существенно сокращает время обработки запроса. Практически,
установление соединения в настоящее время занимает около 5 микросекунд на гигабит
LAN. Так что имеет смысл позволить haproxy распределять соединения
как можно быстрее из своей очереди на сервер с очень маленьким maxconn.
Я помню один игровой сайт, в очереди более 30000 одновременных подключений
и работает с очередью 30 на сервер! Это был сервер Apache, и
apache намного быстрее с небольшим количеством соединений, чем с большими
номера. Но для этого вам действительно нужен быстрый сервер, потому что вы не
хотите, чтобы все ваши клиенты стояли в очереди в ожидании слота подключения, потому что
например, сервер ожидает базу данных.
Также то, что работает очень хорошо, это выделять серверы. Если ваш сайт
имеет много статики, вы можете направить статические запросы в пул серверов
(или кэши), чтобы вы не ставили статические запросы на них и чтобы
статические запросы не съедают дорогие слоты подключения.
Надеюсь, это поможет,
Willy