Віллі отримав мені відповідь електронною поштою. Думав, поділюсь. Його відповіді напівжирним шрифтом.
У мене є запитання про мою конфігурацію 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 якось?
Вони стоять у черзі в Linux. Як тільки ви перевантажуєте чергу ядра, вони потрапляють у ядро.
Чи пов’язане глобальне з’єднання із підключеннями до сервера, крім того факту, що загальна кількість з’єднань із сервером не може бути більшим за загальне?
Ні, загальні налаштування та налаштування підключення до сервера не залежать.
Визначаючи глобальні підключення, чи не повинен це бути кількість підключень, доданих у розділі сервера, плюс певний відсоток для об’єднання? І, очевидно, у вас є інші обмеження на зв'язку, але насправді це скільки ви хочете відправити довіреним особам?
Ви правильно зрозуміли. Якщо час відповіді вашого сервера короткий, немає нічого поганого в тому, щоб поставити в чергу тисячі підключень, які обслуговуватимуть лише кілька за один раз, оскільки це істотно скорочує час обробки запиту. Практично встановлення з'єднання в наш час займає близько 5 мікросекунд у гігабітній локальній мережі. Тому має сенс дозволити haproxy розподіляти зв’язки якомога швидше з черги на сервер із дуже невеликим maxconn. Я пам’ятаю, як один ігровий сайт ставив у чергу більше 30000 одночасних з’єднань і працював із чергою 30 на сервер! Це був сервер Apache, і Apache набагато швидший при малій кількості з'єднань, ніж при великій кількості. Але для цього вам дійсно потрібен швидкий сервер, тому що ви цього не робите Не хочу, щоб усі ваші клієнти стояли в черзі, чекаючи слота підключення, оскільки сервер, наприклад, чекає базу даних. Крім того, що дуже добре працює, це виділення серверів. Якщо на вашому сайті багато статики, ви можете направити статичні запити до пулу серверів (або кеш-пам’яті), щоб не ставити на них статичні запити, а статичні запити не їли дорогих слотів підключення. Сподіваючись, це допоможе, Віллі