У меня есть веб-приложение, развернутое поверх IIS 7.0. приложение доступно большому числу пользователей и манипулирует большими данными. Мой вопрос касается опции HTTP Keep-Alive, которая по умолчанию установлена в true.
это лучший подход для установки HTTP Keep-Alive в false или true.
в случае истинного является хорошим подходом к использованию тайм-аута?
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) и этот приятный ответ на настроек производительности в реестре.
Эта статья принесет больше информации и не забудьте проверить "Как мы ее исправим?" раздел http://mocko.org.uk/b/2011/01/23/http-keepalive-considered-harmful/
Я думаю, что это не очень хорошая идея, чтобы подключить всех пользователей.
Из-за:
Использовать тайм-аут подключения (не более 5 мин.).
НО: если ваше приложение является чатом в прямом эфире, вы должны kepp оживить все соединение. Таким образом, лучше использовать Ajax Long Polling Request + Node JS + некоторый быстрый nosql db для хранения сообщений чата.