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

Ответ 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, если хотите, это объясняет как/где принимаются решения.

Итак, вопросы:

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

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

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

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

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

   Вы правильно поняли. Если время отклика вашего сервера короткое, ничего нет неправильно ставить в очередь тысячи соединений, чтобы обслуживать только несколько одновременно, потому что это существенно сокращает время обработки запроса. Практически, установление соединения в настоящее время занимает около 5 микросекунд на гигабит LAN. Так что имеет смысл позволить haproxy распределять соединения как можно быстрее из своей очереди на сервер с очень маленьким maxconn. Я помню один игровой сайт, в очереди более 30000 одновременных подключений и работает с очередью 30 на сервер! Это был сервер Apache, и apache намного быстрее с небольшим количеством соединений, чем с большими номера. Но для этого вам действительно нужен быстрый сервер, потому что вы не хотите, чтобы все ваши клиенты стояли в очереди в ожидании слота подключения, потому что например, сервер ожидает базу данных. Кроме того, очень хорошо работает выделение серверов. Если ваш сайт имеет много статики, вы можете направить статические запросы в пул серверов (или кэши), чтобы вы не ставили статические запросы на них и чтобы статические запросы не съедают дорогие слоты подключения. Надеюсь, это поможет, Уилли