HTTP Keep Alive в больших веб-приложениях - PullRequest
13 голосов
/ 24 мая 2011

У меня есть веб-приложение, развернутое через IIS 7.0.приложение доступно большому количеству пользователей и манипулирует большими данными. Мой вопрос касается опции HTTP Keep-Alive, которая по умолчанию имеет значение true.

- это лучший подход для установки HTTP Keep-Живые или ложные или истинные.

в случае истины - это хороший подход для использования тайм-аута?

Ответы [ 3 ]

7 голосов
/ 24 мая 2011

KeepAlive обычно следует использовать для обработки запросов, которые следуют сразу за запросом HTML. Допустим, при первом посещении вашего сайта я получаю HTML-страницу с 5 css, 5js и 25 изображениями, я буду использовать свое HTTP-соединение, которое еще живо, чтобы запрашивать эти вещи (ну, в зависимости от браузера, возможно, я буду использовать 3 подключения, чтобы ускорить эти вещи).

Чтобы справиться с этим фактом, мы обычно используем Keepalive 2s или 3s . Наличие более продолжительного сообщения активности означает, что соединение ожидает следующую страницу, которую может запросить пользователь. Это может быть правильным способом мышления: в следующий раз, когда пользователю понадобится страница, мы избежим потери времени на установление HTTP-соединения (а это может быть самой длинной частью времени запроса / ответа). Но для вашего сервера это означает, что большинство HTTP-соединений, которые обрабатываются сервером, ничего не делает ... 1008 *. И вы достигнете MaxConnection (W3SVC / MaxConnections со смешным значением по умолчанию 10), при этом соединения ничего не делают. Действительно плохо. Таким образом, для поддержки активности необходимы большие веб-серверы, и их следует использовать только в том случае, если это действительно нужно вашему приложению.

Если вы используете Keepalive на «классическом веб-сайте» , вы должны изменить время ожидания соединения (по умолчанию 2 минуты). В Apache у вас будет 2 параметра: тайм-аут активности активности (по умолчанию 5 с) и время ожидания соединения (2 мин). В IIS похоже настройки тайм-аута используются для обоих. Поэтому не устанавливайте его в 2 с (клиент очень медленно отправляет свой запрос по истечении времени ожидания), но, возможно, достаточно примерно 10 с. Теперь один из ответов - запретить Keep-Alive и заставить браузер открывать больше подключений. Другой ответ - использовать современный веб-сервер (например, nginx или cherokee), который обрабатывает поддерживающее соединение более элегантным и не требующим ресурсов способом, чем Apache или IIS.

Даже если вы не используете Keepalive, что является причиной ожидания 2 минут для ожидания клиента? это, конечно, слишком высоко, уменьшите это значение до 60 с.

Затем вы должны проверить несколько настроек, связанных с таймаутом ( ConnectionTimeout, HeaderWaitTimeout, MinFileBytesPerSec ) и этот приятный ответ на настроек производительности в реестре.

3 голосов
/ 24 мая 2011

Эта статья принесет больше понимания и не забудьте проверить, «Как мы это исправим?» раздел http://mocko.org.uk/b/2011/01/23/http-keepalive-considered-harmful/

0 голосов
/ 24 мая 2011

Я думаю, что это не очень хорошая идея, чтобы подключить всех пользователей.

Из-за:

  1. Пользователь просто может открыть ваш сайт, но не использовать его - почему мы должныподдерживать соединение в течение длительного времени?
  2. Трудно поддерживать большое количество соединений (больше памяти)

Использовать тайм-аут соединения (максимум 5 минут, мы будем в порядке)

НО: если ваше приложение является живым чатом - вы должны поддерживать все соединения.Таким образом, лучше использовать Ajax Long Polling Request + Node JS + некоторую быструю nosql db для хранения сообщений чата.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...