При настройке прокси-сервера высокой доступности как вы решаете, какие значения назначать тайм-аутам? Я прочитал полдюжины образцов в разных блогах, и все используют разные таймауты, и никто не обсуждает почему.
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 секунд, чтобы начать давать ответ, то я считаю приемлемым считать его мертвым.
Особый случай: Некоторым РЕДКИМ сервисам, выполняющим очень тяжелую обработку, может потребоваться целая минута или больше, чтобы дать ответ. Этот тайм-аут может потребоваться значительно увеличить для этого конкретного использования. (Примечание: скорее всего, это плохой дизайн, использование асинхронного стиля связи или полное отсутствие HTTP.)
Установите максимальное время ожидания успешной попытки подключения к серверу.
Читать: Максимальное время, в течение которого сервер должен принять TCP-соединение.
Серверы находятся в той же локальной сети, что и HAProxy, поэтому он должен быть быстрым. Дайте ему хотя бы 5 секунд, потому что именно столько времени может пройти, когда произойдет что-нибудь неожиданное (потерянный пакет TCP для повторной передачи, сервер, разветвляющий новый процесс для приема новых запросов, всплеск трафика).
Особый случай: Когда серверы находятся в другой локальной сети или по ненадежному каналу. Этот таймаут, возможно, потребуется значительно увеличить. (Примечание: скорее всего, это плохая архитектура.)
Установите дополнительный тайм-аут проверки, но только после того, как соединение уже установлено.
Установить дополнительный тайм-аут проверки, но только после того, как соединение уже было. Если установлено, haproxy использует min («timeout connect», «inter») как тайм-аут соединения для проверки и «timeout check» как дополнительный тайм-аут чтения. «Мин» используется для того, чтобы бегающие с очень длинный "тайм-аут подключения" (например, те, кому это нужно из-за очереди или тарпита) не замедляют их проверки. (Также обратите внимание, что нет веских причин для таких длинных тайм-аутов соединения, потому что "очередь тайм-аута" и "tarpit тайм-аута" всегда могут использоваться, чтобы избежать этого).
Читать: При выполнении проверки работоспособности сервер timeout connect чтобы принять соединение тогда timeout check дать ответ.
На всех серверах ДОЛЖНА быть настроена проверка работоспособности HTTP (S). Это единственный способ для балансировщика нагрузки узнать, доступен ли сервер. Проверка работоспособности - это простая /isalive страница всегда отвечает OK.
Дайте этому таймауту не менее 5 секунд, потому что именно столько времени может пройти, когда произойдет что-нибудь неожиданное (потерянный TCP-пакет для повторной передачи, сервер, разветвляющий новый процесс для приема новых запросов, всплеск трафика).
Военная история: Много людей неправильно считаю, что сервер всегда может ответить на эту простую страницу за 3 мс. Они устанавливают агрессивный тайм-аут (<2000 мс) с агрессивным аварийным переключением (2 неудачных проверки = сервер мертв). Я видел, как из-за этого падали целые веб-сайты. Обычно наблюдается небольшой всплеск трафика, внутренние серверы становятся медленнее, проверки работоспособности откладываются ... до тех пор, пока внезапно не истечет время ожидания всех вместе, HAProxy считает, что ВСЕ серверы умерли сразу, и весь сайт отключится.