Чому ви коли-небудь встановлювали MaxKeepAliveRequests нічим іншим, але не обмеженим?

Apache KeepAliveTimeoutіснує для того, щоб закрити постійне з'єднання, якщо новий запит не буде виданий протягом певного періоду часу. За умови, що користувач не закриває свій браузер / вкладку, цей час очікування (як правило, 5-15 секунд) - це те, що врешті-решт закриває більшість збережених зв’язків і запобігає марному витраченню ресурсів сервера, утримуючи безперервно з'єднання.

Тепер MaxKeepAliveRequestsдиректива встановлює обмеження на кількість запитів HTTP, які обслуговуватиме одне з'єднання TCP (залишене відкритим через KeepAlive). Встановлення цього значення 0означає необмежену кількість запитів.

Чому ти коли-небудь ставив би це щось, крім "необмеженого"? За умови, що клієнт все ще активно надсилає запити, яка шкода в тому, щоб дозволити їм траплятися на одному і тому ж постійному зв’язку? Як тільки ліміт буде досягнуто, запити все ще надходять, лише після нового з'єднання.

Як я це бачу, немає сенсу ніколи це обмежувати. Що я пропускаю?

В основному, тому, що Apache не був побудований для цього. Проблема - використання пам'яті сервера. У багатьох конфігураціях генерування контенту відбувається в тому ж процесі, що і доставка вмісту, тому кожен процес зростатиме до розміру найбільшої речі, яку він обробляє. Зобразіть процес, який розширюється до 64 Мб через важкий скрипт для PHP, потім роздутий процес сидіння та обслуговування статичних файлів. Тепер помножте це на 100. Крім того, якщо десь є витоки пам'яті, процеси будуть рости без обмежень.

Параметри збереження повинні бути збалансованими залежно від типу вашого вмісту та вашого трафіку. Як правило, оптимальна конфігурація має MaxKeepAliveRequests високий (100-500) та KeepAliveTimeout низький (2-5), щоб швидко їх звільнити.

Я знаю, що це давнє питання, але я вже робив налагодження, і, схоже, (і це не тільки для Apache) MaxKeepAliveRequestsпрацює незалежно від KeepAliveTimeout.

Це означає, що директива тайм-ауту зараховується лише до стійких з'єднань в режимі очікування (не читає чи записує) - якщо ви продовжуєте запитувати нижче таймауту, ви можете практично робити необмежену кількість запитів за тим самим з'єднанням.

Це може бути непогано з якихось причин, включаючи довгі запущені tcp-з'єднання, які випадково вбиваються? У будь-якому випадку, клієнти http не такі вже й нерозумні і можуть MaxKeepAliveRequestsдосить добре впоратися з налаштуваннями "низького рівня" , наприклад, в мові програмування досить легко виявити, чи не було з'єднання tcp сервером закрито і, таким чином, знову підключитися до нього знову. Крім того, у більшості http-клієнтів буде встановлено обмеження самостійно (наприклад, браузери закриють постійне з'єднання через 300 секунд або близько того).

Однією з причин буде балансування навантаження. Після того, як буде збережено живим або http 1.1 стійким з'єднанням, балансир навантаження не перемістить його на новий хост, поки він не закриється. Якщо у вас є один клієнт, який робить величезну кількість запитів через одне з'єднання, можливо, ви не зможете добре балансувати між серверами.

Частково, щоб уникнути того, щоб один користувач не переплутав усі слоти підключення. Без обмежень один зловмисний або погано написаний клієнт може перейняти кожне доступне з'єднання і утримувати їх назавжди. Однак це не є великим пом’якшенням, ніж порівняно з обмеженням підключення до IP.

Переважно збалансування навантаження, але конкретно щодо технічного обслуговування. Якщо ви хочете взяти сервер в автономному режимі, ви скинете його на 0 підключень, але дозволите існуючим з'єднанням закінчитися протягом певного часу. Поставлення ліміту на кількість запитів на зберігання означає, що в кінцевому підсумку користувачі витончено створять нове з'єднання та будуть переміщені на новий бек-сервер. Можливо, якийсь спосіб сигналізувати серверу про те, що він повинен припинити взагалі приймати кепалів під час процесу зливу, був би ще кращим, але, наскільки я знаю, такої функції не існує.