Зачем вам когда-либо устанавливать MaxKeepAliveRequests на что угодно, кроме неограниченного?
19021
Jonathon Reinhart
Apache KeepAliveTimeoutсуществует, чтобы закрыть соединение keep-alive, если новый запрос не выдан в течение заданного периода времени. При условии, что пользователь не закрывает свой браузер / вкладку, этот тайм-аут (обычно 5-15 секунд) является тем, что в конечном итоге закрывает большинство поддерживающих соединение соединений и предотвращает трату ресурсов сервера из-за бесконечного удержания соединений.
Теперь MaxKeepAliveRequestsдиректива устанавливает ограничение на количество HTTP-запросов, которые KeepAliveбудут обслуживать одно TCP-соединение (оставленное открытым из-за ). Установка этого значения 0означает, что разрешено неограниченное количество запросов.
Почему вы когда-либо устанавливаете это на что-либо, кроме «неограниченного»? При условии, что клиент все еще активно отправляет запросы, какой вред может допускать их при одном и том же соединении keep-alive? Как только предел достигнут, запросы все еще приходят, только на новом соединении.
Как я понимаю, нет смысла ограничивать это. Что мне не хватает?
Basically, because Apache wasn't built for it. The problem is server memory usage. In many configurations, content generation is done in the same process as content delivery, so each process will grow to the size of the largest thing it handles. Picture a process expanding to 64mb because of a heavy php script, then that bloated process sitting and serving static files. Now multiply that by 100. Also, if there are memory leaks anywhere, processes will grow without limit.
The keepalive settings should be balanced based on the type of your content and your traffic. Generally, the optimal configuration has MaxKeepAliveRequests high (100-500), and KeepAliveTimeout low (2-5) to free them up quickly.
1
lifeofguenter
I know this is a old question, but I have been doing some debugging, and it seems as (and this is not only true for Apache) MaxKeepAliveRequests works independently of KeepAliveTimeout.
Meaning, the timeout directive only counts against idling persistent connections (no reads or writes) - if you keep requesting below the timeout you can virtually do an unlimited amount of requests over the same connection.
This might not be good for some reasons including long running tcp connections being randomly killed? In any case, http clients are not that stupid and can handle a "low" MaxKeepAliveRequests setting pretty well, e.g. it is relatively easy in programming language to detect if a tcp connection has been closed by the server and thus re-connecting to it again. Additionally, most of the http-clients are going to have limits in place on their own (e.g. browsers would close a keep-alive connection after 300 seconds or so).
1
dtauzell
Одной из причин будет балансировка нагрузки. После того, как установлено постоянное соединение или постоянное соединение http 1.1, балансировщик нагрузки не будет перемещать его на новый хост, пока он не закроется. Если у вас есть один клиент, отправляющий огромное количество запросов через одно соединение, вы не сможете получить хороший баланс между серверами.
Но почему это имеет значение? Мне кажется нежелательным когда-либо распространять подключение одного пользователя на несколько серверов. Балансировка нагрузки предназначена для обработки большого количества пользователей, а не для соединений одного пользователя. На самом деле - если один пользователь работает с сервисом, вы бы предпочли, чтобы он был ограничен одним сервером (где они эффективно ограничивали бы скорость).
Jonathon Reinhart 7 лет назад
0
Хорошие моменты. Несколько мыслей: 1. кто-нибудь еще на этом сервере тоже будет забит. 2. Для балансировщиков нагрузки, которые работают ниже уровня HTTP: когда вы вынимаете сервер из пула балансировщика нагрузки, он не закрывает существующее HTTP-соединение. Это усложняет перемещение людей на другой сервер с помощью только балансировщика нагрузки. Причина 2 в том, как я попал на эту страницу во время поиска, чтобы узнать, что люди говорят об этом параметре.
dtauzell 7 лет назад
0
Третья причина: если ваш сервер / приложение находится в плохом состоянии и выдает ошибку, это закрепление может привести к ошибке всех запросов, пока ситуация не будет исправлена, тогда как, если вы ограничите, сколько у них есть шансов получить баланс для нового сервера ,
dtauzell 7 лет назад
0
0
Elliott
Частично, чтобы один пользователь не использовал все слоты для подключения. Без ограничения один злонамеренный или плохо написанный клиент может захватить каждое доступное соединение и удерживать его навсегда. Это, однако, не является хорошим решением по сравнению с чем-то вроде лимита на соединение для IP.
В основном балансировка нагрузки, но особенно в отношении обслуживания. Если вы хотите перевести сервер в автономный режим, вы отбрасываете его до 0 соединений, но позволяете существующим соединениям завершаться в течение некоторого времени. Установка ограничения на количество запросов поддержки активности означает, что в конечном итоге пользователи будут элегантно создавать новое соединение и перемещаться на новый внутренний сервер. Возможно, какой-то способ сообщить серверу о том, что он вообще должен прекратить принимать сообщения поддержки активности во время процесса утечки, был бы еще лучше, но, насколько я знаю, такой функции не существует.