Зачем вам когда-либо устанавливать MaxKeepAliveRequests на что угодно, кроме неограниченного?
Апача KeepAliveTimeout существует, чтобы закрыть соединение keep-alive, если новый запрос не выдан в течение заданного периода времени. При условии, что пользователь не закрывает свой браузер / вкладку, этот тайм-аут (обычно 5-15 секунд) является тем, что в конечном итоге закрывает большинство поддерживаемых соединений и предотвращает потерю ресурсов сервера из-за неограниченного удержания соединений.
Теперь MaxKeepAliveRequests Директива накладывает ограничение на количество HTTP-запросов, которые одно соединение TCP (оставить открытым из-за KeepAlive) будет служить. Установка этого в 0 означает, что разрешено неограниченное количество запросов.
Почему вы когда-либо устанавливаете это на что-либо, кроме "неограниченного"? При условии, что клиент все еще активно отправляет запросы, какой вред может допускать их при одном и том же соединении keep-alive? Как только предел достигнут, запросы все еще приходят, только на новом соединении.
Как я понимаю, нет смысла ограничивать это. Что мне не хватает?
4 ответа
По сути, потому что Apache не был создан для этого. Проблема в использовании памяти сервера. Во многих конфигурациях генерация контента осуществляется в том же процессе, что и доставка контента, поэтому каждый процесс вырастет до размера самой большой вещи, которую он обрабатывает. Представьте себе процесс, расширяющийся до 64 МБ из-за тяжелого php-скрипта, затем этот раздутый процесс, сидящий и обслуживающий статические файлы Теперь умножьте это на 100. Кроме того, если где-нибудь будут утечки памяти, процессы будут расти без ограничений.
Настройки активности активности должны быть сбалансированы в зависимости от типа вашего контента и трафика. Как правило, оптимальная конфигурация имеет высокое значение MaxKeepAliveRequests (100-500) и минимальное значение KeepAliveTimeout (2-5) для быстрого их освобождения.
Я знаю, что это старый вопрос, но я делал некоторые отладки, и кажется, что (и это не только верно для Apache) MaxKeepAliveRequests работает независимо от KeepAliveTimeout,
Это означает, что директива timeout учитывает только постоянные соединения на холостом ходу (без чтения или записи) - если вы продолжаете запрашивать ниже тайм-аута, вы можете фактически выполнять неограниченное количество запросов по одному и тому же соединению.
Это может быть нехорошо по ряду причин, в том числе из-за случайного уничтожения долго работающих tcp-соединений? В любом случае, http-клиенты не настолько глупы и могут справиться с "низким" MaxKeepAliveRequests настройка достаточно хорошая, например, на языке программирования относительно легко определить, было ли закрыто tcp-соединение сервером, и, таким образом, снова подключиться к нему. Кроме того, большинство http-клиентов будут иметь собственные ограничения (например, браузеры закроют поддерживающее соединение через 300 секунд или около того).
Частично, чтобы один пользователь не использовал все слоты для подключения. Без ограничения один злонамеренный или плохо написанный клиент может захватить каждое доступное соединение и удерживать его навсегда. Это, однако, не является хорошим решением по сравнению с чем-то вроде предела для каждого IP-соединения.
В основном балансировка нагрузки, но особенно в отношении обслуживания. Если вы хотите перевести сервер в автономный режим, вы отбросите его до 0 соединений, но позволите существующим соединениям завершиться в течение некоторого времени. Установка ограничения на количество запросов поддержки активности означает, что в конечном итоге пользователи будут элегантно создавать новое соединение и перемещаться на новый внутренний сервер. Возможно, какой-то способ сообщить серверу о том, что он вообще должен прекратить принимать сообщения поддержки активности во время процесса утечки, был бы еще лучше, но, насколько я знаю, такой функции не существует.
Одной из причин будет балансировка нагрузки. После того, как установлено постоянное соединение или постоянное соединение http 1.1, балансировщик нагрузки не будет перемещать его на новый хост, пока он не закроется. Если у вас есть один клиент, отправляющий огромное количество запросов через одно соединение, вы не сможете получить хороший баланс между серверами.