Ответ 1
KeepAlive обычно должен использоваться для обработки запросов, которые следует за HTML-запросом. Скажем, при первом посещении вашего сайта я получаю HTML-страницу с 5 css, 5js и 25 изображениями, я буду использовать мое HTTP-соединение, которое все еще живое, чтобы запросить эти вещи (ну, в зависимости от браузера, я, возможно, буду использовать 3 для ускорения этих вещей).
Чтобы справиться с этим фактом, мы обычно используем Keepalive 2s или 3s. Наличие более длительного keepalive означает, что соединение ожидает следующую страницу, которую пользователь может запросить. Это может быть действительным способом мышления, в следующий раз, когда пользователю захочется перейти на страницу, мы избежим времени, устанавливающего HTTP-соединение (и это может быть самой длинной частью времени запроса/ответа). Но для вашего сервера, который означает большинство HTTP-соединений, которые обрабатываются сервером, делать... ничего. И вы достигнете своего MaxConnection (W3SVC/MaxConnections со смешным по умолчанию до 10), при этом соединения ничего не делают. Действительно плохо. Таким образом, для поддержания продолжительности жизни нужны большие веб-серверы, и их следует использовать, только если ваше приложение действительно нуждается в этом.
Если вы используете Keepalive на "классическом веб-сайте" , вы должны изменить время ожидания соединения (по умолчанию 2min). В Apache у вас будет 2 настройки: keepalive tiemout (по умолчанию 5 с) и таймаут соединения (2 мин). В IIS кажется, что параметры таймаута используются для обоих. Так что не устанавливайте его на 2 с (клиент очень медленно посылает запрос на тайм-аут), но может быть достаточно 10-ти. Теперь один ответ - запретить Keep-Alive и сделать браузер более открытым. Другой ответ - использовать современный веб-сервер (например, nginx или cherokee), который обрабатывает соединение keep-alive более элегантным и ресурсоемким способом, чем Apache или IIS.
Даже если вы не используете Keepalive, какая причина ожидания 2 минуты для тайм-аута клиента? он, конечно, слишком высок, уменьшает это значение примерно до 60 с.
Затем вы должны проверить несколько параметров, связанных с таймаутом (ConnectionTimeout, HeaderWaitTimeout, MinFileBytesPerSec) и этот приятный ответ на настроек производительности в реестре.