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

11

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

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

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

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

apache-http-server http keepalive Джонатон Рейнхарт
источник

Ответы:

4

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

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

Дирижабль
источник
2

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

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

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

lifeofguenter
источник
1

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

dtauzell
источник
Но почему это имеет значение? Мне кажется нежелательным когда-либо распространять соединение одного пользователя на несколько серверов. Балансировка нагрузки предназначена для обработки большого количества пользователей, а не для соединений одного пользователя. На самом деле - если один пользователь работает с сервисом, вы бы предпочли, чтобы он был ограничен одним сервером (где они эффективно ограничивали бы скорость).
Джонатон Рейнхарт
1
Хорошие моменты. Несколько мыслей: 1. кто-нибудь еще на этом сервере тоже будет забит. 2. Для балансировщиков нагрузки, которые работают ниже уровня HTTP: когда вы вынимаете сервер из пула балансировщика нагрузки, он не закрывает существующее HTTP-соединение. Это усложняет перемещение людей на другой сервер с помощью только балансировщика нагрузки. Причина 2 заключается в том, как я попал на эту страницу во время поиска, чтобы узнать, что люди говорят об этом параметре.
dtauzell
1
Третья причина: если ваш сервер / приложение переходит в плохое состояние и выдает ошибку, это закрепление может привести к ошибке всех запросов, пока ситуация не будет исправлена, тогда как, если вы ограничите, сколько у них есть шансов получить баланс для нового сервера ,
dtauzell
Я не сталкивался с балансировщиком нагрузки, который работает так. Балансировщик нагрузки обычно имеет параметр «липкость», который определяет, следует ли направлять все запросы клиента (например, по IP) в текущем сеансе к одному и тому же восходящему каналу или распределять по восходящим потокам. Какой вариант полезен, зависит от того бежит вверх по течению
Мануэль
1

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

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

Elliott
источник