Разница между глобальным maxconn и сервером maxconn haproxy

Вилли получил мне ответ по электронной почте. Я думал, что поделюсь им. Его ответы выделены жирным шрифтом.

У меня есть вопрос о моей конфигурации 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 на сервере,в блоке listen.

и есть еще один в блоке прослушивания, который по умолчанию что-то как 2000.

мое мышление таково: глобальный управляет общим количеством соединений это haproxy, как услуга, будет que или обрабатывать в одно время.

правильно. Это максимальное количество одновременных подключений для каждого процесса.

Если количество получает выше этого, он либо убивает соединение, либо пулы в некоторых linux сокет?

позже, он просто перестает принимать новые подключения и они остаются в очередь сокетов в ядре. Определяется количество сокетов, стоящих в очереди по мин (нет.ядро.somaxconn, net.протокол IPv4.tcp_max_syn_backlog, и слушайте блок maxconn).

Я понятия не имею, что произойдет, если число становится выше 4000.

избыточные соединения ждут завершения другого, прежде чем быть общепринятый. Однако, пока очередь ядра не насыщена, клиент даже не замечает этого, так как соединение принимается на уровне Уровень TCP но не обрабатывается. Так что клиент замечает только некоторую задержку для обработки запроса. Но на практике maxconn блока прослушивания гораздо важнее, так как по умолчанию он меньше глобального. Слушать это maxconn ограничивает количество подключений на одного слушателя. В общем, это мудро настройте его для количества подключений, которые вы хотите для службы, и настроить глобальный maxconn на максимальное количество подключений вы позволяете процессу HAProxy обрабатывать. Когда у вас есть только один услуга, оба могут быть установлены на одно и то же значение. Но когда у вас есть много услуг, вы можете легко понять, что это имеет огромное значение, так как вы этого не делаете хочу одного, чтобы все соединения и предотвратить остальных от работы.

тогда у вас есть свойство сервера maxconn 15 лет. Во-первых, я установил это на 15 потому что мой php-fpm, это пересылка на отдельный сервер, только имеет так много дочерних процессов, он может использовать, поэтому я уверен, что объединение запросов здесь, а не в php-fpm. Что, по-моему, быстрее.

Да, не только это должно быть быстрее, но это позволяет haproxy найти другой доступный сервер, когда это возможно, а также это позволяет ему убить запрос в очереди, если клиент нажимает "стоп" перед подключением пересылается на сервер.

Но вернемся к теме, Моя теория об этом номере-это каждый сервер в этом блок будет отправлен только 15 соединений одновременно. А потом соединения будет ждите открытия сервера. Если бы у меня были куки, соединения ждали бы для правильного открытого сервера. Но я этого не делаю.

это точно принцип. Существует очередь на прокси и на сервер очередь. Соединения с сохраняемым файлом cookie переходят в очередь сервера и другие соединения идут в очередь прокси. Однако так как в вашем случае нет куки настроен, все соединения идут в очередь прокси. Вы можете посмотреть на диаграмме doc / queuing.рис в источниках haproxy, если вы хотите, это объясняет как и где принимаются решения.

поэтому вопросы:

1. что произойдет, если глобальные соединения превысят 4000? Они умирают? Или пул в Linux как-то?

   они стоят в очереди в linux. Как только вы перегружаете очередь ядра, тогда они упал в ядро.

2. связаны ли глобальные соединения с серверными соединениями, кроме тот факт, что вы не можете иметь общее количество подключений к серверу больше, чем глобально?

   нет, глобальные и серверные настройки подключения независимы.

3. при выяснении глобальных соединений, не должно ли это быть количество соединения, добавленные в разделе сервер, плюс определенный процент для объединение? И, очевидно, у вас есть другие ограничения на связи, но неужели это сколько вы хотите отправить своим прокси?

   вы все правильно поняли. Если ваш время отклика сервера короткое, ничего нет неправильно ставить в очередь тысячи соединений, чтобы обслуживать только несколько одновременно, ведь это существенно сокращает время обработки запроса. Почти, установление соединения в настоящее время занимает около 5 микросекунд на гигабит ЛОКАЛЬНАЯ ВЫЧИСЛИТЕЛЬНАЯ СЕТЬ. Поэтому он делает много смысла, чтобы позволить распространять графических интерфейсов подключения как можно быстрее из своей очереди на сервер с очень маленьким maxconn. Я помню один игровой сайт, стоящий в очереди более 30000 одновременно подключение и работает с очередью 30 на сервер ! Это был сервер Apache, и apache намного быстрее с небольшим количеством соединений, чем с большим числа. Но для этого вам нужен быстрый сервер, потому что вы не хотите, чтобы все ваши клиенты стояли в очереди в ожидании слота подключения, потому что например, сервер ожидает базу данных. Также очень хорошо работает в составе сервера. Если ваш сайт имеет много статики, вы можете направить статические запросы в пул сервера (или кэш), чтобы вы не ставили в очередь статические запросы на них и что статические запросы не едят дорогие слоты подключения. Надеюсь, это поможет, Вилли