Передмова
Я деякий час налаштовував 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") як час очікування підключення для перевірки, а "checkout check" - як додатковий час очікування. "Хв" використовується для того, щоб люди, які працюють з дуже довгим "timeout connect" (наприклад, ті, хто потребував цього через чергу чи tarpit), не сповільнювали свої перевірки. (Будь ласка, зауважте, що немає поважних причин для таких довгих тайм-аутів підключення, тому що "черга очікування очікування" та "таймапт тайм-ауту" завжди можна використовувати, щоб уникнути цього).
Прочитайте : виконуючи перевірку стану здоров'я, сервер timeout connectповинен прийняти з'єднання, timeout checkщоб дати відповідь.
На всіх серверах ОБОВ'ЯЗКОВО встановлено перевірку стану здоров'я HTTP (S). Це єдиний спосіб, щоб балансир завантаження дізнався, чи є сервер. Перевірка здоров'я - це проста /isaliveсторінка, яка завжди відповідає OK.
Дайте цьому тайм-ауту принаймні 5 секунд, тому що стільки часу може зайняти, коли трапиться щось несподіване (втрачений TCP-пакет для повторної передачі; сервер змушує новий процес приймати нові запити, прискорити трафік).
Історія війни : Багато людей помилково вважають, що сервер завжди може відповісти на цю просту сторінку за 3 мс. Вони встановлюють агресивний тайм-аут (<2000 мс) з агресивним відмовою (2 невдалі перевірки = сервер загинув). Я бачив, що цілі веб-сайти знижуються через це. Зазвичай спостерігається невеликий сплеск трафіку, сервери бекенда уповільнюються, перевірки здоров’я затягуються ... поки раптом вони весь час закінчуються разом, HAProxy вважає, що ВСІ сервери загинули одразу і весь сайт знижується.