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