При настройке HA Proxy, как вы решаете, какие значения назначать тайм-аутам? Я прочитал полдюжины образцов в разных блогах, и каждый использует разные таймауты, и никто не обсуждает почему.

HAProxy, кажется, специально беспокоится о клиенте, соединении и сервере, о которых HAPRoxy выдает предупреждение, если вы оставляете полностью неустановленным:

While not properly invalid, you will certainly encounter various problems
with such a configuration. To fix this, please ensure that all following
timeouts are set to a non-zero value: 'client', 'connect', 'server'.

Документация не приносит никакой пользы в этом отношении: она предполагает «чуть выше кратные 3 секунды» , но не то, почему вы выбрали бы кратна 1 против 100 или 42.

RPM, который я использую (хранилище Amazon Linux), устанавливает следующие значения по умолчанию:

timeout connect         10s
timeout client          1m
timeout server          1m

Два из которых являются точными кратными 3 секундам, нарушая единственный официальный совет, который я видел.

Если у вас нет конкретных советов по настройке, возможно, более простой вопрос: что я могу ожидать, чтобы пойти не так с очень короткими или очень длинными тайм-аутами?

TCP RTO (тайм-аут приема) начинается через три секунды. ( RFC 1122 ) Если переданный пакет не получил подтверждение, возвращенное за это время, то он считается потерянным и повторно переданным. Это почти наверняка то, на что ссылается автор. (Обратите внимание, что RTO настраивается динамически с помощью различных алгоритмов , выходящих за рамки этого вопроса.)

Помните, что это действительно относится только к соединениям между вашим внешним сервером и клиентами (т. Е. Веб-пользователями). В нормальных сценариях соединения между HAProxy и вашими внутренними серверами должны быть в локальной сети, и вы должны использовать гораздо более короткие тайм-ауты, чтобы неисправные серверы быстрее выводились из строя.

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

Имея это в виду, вы, как правило, будете хотеть очень короткие тайм-ауты timeout connectи очень длинные timeout client.

Ведь timeout serverэто зависит от вашего веб-приложения. При установке времени ожидания учитывайте сложность обслуживаемого веб-приложения и продолжительность обработки сложного запроса в худшем случае. Если сомневаетесь, поднимите значение.

предисловие

Я некоторое время настраивал HAProxy и много тестировал производительность на нем. От 100 HTTP-запросов / с до 50 000 HTTP-запросов / с.

Первый совет - включить страницу статистики на HAProxy . Вам НУЖЕН мониторинг, не исключение. Вам также потребуется точная настройка, если вы намерены пройти 10 000 запросов / с.

Таймауты - это сбивающее с толку зверь, потому что они имеют огромный диапазон возможных значений, большинство из которых не имеют заметных различий. Я еще не видел что-то не так из-за числа на 5% ниже или на 5% выше. 10000 против 11000 миллисекунд, кого это волнует? Вероятно, не ваша система.

конфигурация

Я не могу с чистой совестью назвать пару цифр как «лучшие тайм-ауты для всех».

Вместо этого я могу сказать, что НАИБОЛЕЕ агрессивные таймауты, которые всегда приемлемы для балансировки нагрузки HTTP (S). Если вы встретите ниже, чем это, пришло время перенастроить балансировщик нагрузки.

timeout connect 5000
timeout check 5000
timeout client 30000
timeout server 30000

Тайм-аут клиента:

Тайм-аут неактивности применяется, когда ожидается, что клиент подтвердит или отправит данные. В режиме HTTP этот тайм-аут особенно важно учитывать на первом этапе, когда клиент отправляет запрос, и во время ответа, когда он читает данные, отправленные сервером.

Чтение : это максимальное время получения заголовков HTTP-запросов от клиента.

3G / 4G / 56k / спутник может быть медленным время от времени. Тем не менее, они должны иметь возможность отправлять заголовки HTTP в течение нескольких секунд, а НЕ 30.

Если у кого-то настолько плохое соединение, что ему нужно более 30 секунд для запроса страницы (затем более 10 * 30 для запроса 10 встроенных изображений / CSS / JS), я считаю, что приемлемо отклонить его.

сервер тайм-аута:

Тайм-аут неактивности применяется, когда ожидается, что сервер подтвердит или отправит данные. В режиме HTTP этот тайм-аут особенно важно учитывать во время первой фазы ответа сервера, когда ему необходимо отправить заголовки, поскольку он непосредственно представляет время обработки сервером запроса. Чтобы выяснить, какое значение здесь поставить, часто полезно начать с того, что будет считаться недопустимым временем отклика, затем проверить журналы, чтобы наблюдать распределение времени отклика, и соответствующим образом скорректировать значение.

Чтение : это максимальное время для получения заголовков ответа HTTP от сервера (после того, как он получил полный клиентский запрос). По сути, это время обработки ваших серверов, прежде чем он начнет отправлять ответ.

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

Особый случай : некоторые службы RARE, выполняющие очень тяжелую обработку, могут получить ответ в течение минуты или более. Этот тайм-аут может потребоваться значительно увеличить для этого конкретного использования. (Примечание. Вероятно, это плохой дизайн, используется асинхронное взаимодействие или вообще не используется HTTP.)

время ожидания подключения:

Установите максимальное время ожидания попытки подключения к серверу для успешного выполнения.

Чтение : максимальное время, которое сервер должен принять TCP-соединение.

Серверы находятся в той же локальной сети, что и HAProxy, поэтому это должно быть быстро. Дайте ему не менее 5 секунд, потому что это может занять много времени, когда происходит что-то непредвиденное (потерянный пакет TCP для повторной передачи, сервер, разветвляющий новый процесс для приема новых запросов, скачок трафика).

Особый случай : когда серверы находятся в другой локальной сети или по ненадежной ссылке. Этот тайм-аут, возможно, нужно будет значительно увеличить. (Примечание: это может быть случай плохой архитектуры.)

проверка тайм-аута:

Установите дополнительное время проверки, но только после того, как соединение уже установлено.

Установите дополнительный тайм-аут проверки, но только после того, как соединение уже установлено. Haproxy использует min («timeout connect», «inter») в качестве тайм-аута соединения для проверки и «timeout check» в качестве дополнительного тайм-аута чтения. «Мин» используется для того, чтобы люди, работающие с очень длительным «тайм-аутом соединения» (например, те, кому это нужно из-за очереди или тарпита), не замедляют свои проверки. (Обратите также внимание, что нет веских причин для таких длительных тайм-аутов подключения, потому что всегда можно использовать «очередь ожидания» и «тайм-аут ожидания»).

Чтение : при выполнении проверки работоспособности сервер должен timeout connectзатем принять соединение, timeout checkчтобы дать ответ.

На всех серверах ДОЛЖНА быть настроена проверка работоспособности HTTP (S). Для балансировщика нагрузки это единственный способ узнать, доступен ли сервер. Проверка здоровья - это простая /isaliveстраница, которая всегда отвечает OK.

Дайте этому тайм-ауту не менее 5 секунд, потому что это может занять много времени, когда происходит что-то непредвиденное (потерянный TCP-пакет для повторной передачи, сервер, разветвляющий новый процесс для приема новых запросов, скачок трафика).

История войны : многие люди ошибочно полагают, что сервер всегда может ответить на эту простую страницу за 3 мс. Они установили агрессивный тайм-аут (<2000 мс) с агрессивным аварийным переключением (2 неудачных проверки = сервер не работает). Я видел, как целые сайты рушатся из-за этого. Обычно наблюдается небольшой всплеск трафика, бэкэнд-серверы работают медленнее, проверки работоспособности откладываются ... до тех пор, пока вдруг все они не прекратят работать вместе, HAProxy считает, что ВСЕ серверы умерли одновременно, и весь сайт вышел из строя.