предисловие
Я некоторое время настраивал 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 считает, что ВСЕ серверы умерли одновременно, и весь сайт вышел из строя.