Зачем вам когда-либо устанавливать MaxKeepAliveRequests на что угодно, кроме неограниченного?

Question

KeepAliveTimeout Apache существует, чтобы закрыть соединение keep-alive, если новый запрос не был выполнен в течение определенного периода времени. При условии, что пользователь не закрывает свой браузер / вкладку, этот тайм-аут (обычно 5-15 секунд) является тем, что в конечном итоге закрывает большинство поддерживающих соединение соединений и предотвращает трату ресурсов сервера из-за бесконечного удержания соединений.

Теперь директива MaxKeepAliveRequests устанавливает ограничение на количество HTTP-запросов, которые будут обслуживать одно TCP-соединение (оставленное открытым из-за KeepAlive). Установка этого значения в 0 означает, что разрешено неограниченное количество запросов.

Почему вы когда-либо устанавливаете это на что-либо, кроме "неограниченного"? При условии, что клиент все еще активно отправляет запросы, какой вред может допускать их при одном и том же соединении keep-alive? Как только предел достигнут, запросы все еще приходят, только на новом соединении.

Как я понимаю, нет смысла ограничивать это. Что мне не хватает?

Answer 1

По сути, потому что Apache не был создан для этого. Проблема в использовании памяти сервера. Во многих конфигурациях генерация контента выполняется в том же процессе, что и доставка контента, поэтому каждый процесс вырастет до размера самой большой вещи, которую он обрабатывает. Представьте себе процесс, расширяющийся до 64 МБ из-за тяжелого php-скрипта, затем этот раздутый процесс, сидящий и обслуживающий статические файлы. Теперь умножьте это на 100. Кроме того, если где-нибудь будут утечки памяти, процессы будут расти без ограничений.

Настройки активности активности должны быть сбалансированы в зависимости от типа вашего контента и трафика. Как правило, оптимальная конфигурация имеет высокое значение MaxKeepAliveRequests (100-500) и минимальное значение KeepAliveTimeout (2-5) для быстрого их освобождения.

Answer 2

Я знаю, что это старый вопрос, но я проводил некоторую отладку, и кажется, что (и это не только верно для Apache) MaxKeepAliveRequests работает независимо от KeepAliveTimeout .

Это означает, что директива timeout учитывает только постоянные соединения на холостом ходу (без чтения или записи) - если вы продолжаете запрашивать ниже тайм-аута, вы можете фактически выполнять неограниченное количество запросов по одному и тому же соединению.

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

Answer 3

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

Answer 4

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

В основном балансировка нагрузки, но особенно в отношении обслуживания. Если вы хотите перевести сервер в автономный режим, вы отбрасываете его до 0 соединений, но позволяете существующим соединениям завершаться в течение некоторого времени. Установка ограничения на количество запросов keepalive означает, что в конечном итоге пользователи будут элегантно создавать новое соединение и перемещаться на новый внутренний сервер. Возможно, какой-то способ сообщить серверу о том, что он вообще должен прекратить принимать сообщения поддержки активности во время процесса утечки, был бы еще лучше, но, насколько я знаю, такой функции не существует.