В чем разница между потоком за соединение и потоком за запрос?

Ответ 1

Какая из этих двух стратегий лучше масштабируется и почему?

Поток за запрос масштабируется лучше, чем поток за соединение.

Java-потоки довольно дороги, обычно используют сегмент памяти 1 МБ каждый, независимо от того, активны они или нет. Если вы укажете каждому соединению свой собственный поток, поток, как правило, будет сидеть без дела между последовательными запросами на соединение. В конечном итоге инфраструктура должна либо прекратить прием новых соединений (поскольку она не может создавать больше потоков), либо начать отключение старых подключений (что приводит к сбою соединения, если/когда пользователь просыпается).

Для HTTP-соединения требуется значительно меньше ресурсов, чем стек потоков, хотя существует ограничение на 64 Кбит открытых соединений на каждый IP-адрес из-за того, как работает TCP/IP.

В отличие от этого, в модели нить за запрос поток связан только во время обработки запроса. Это обычно означает, что службе требуется меньше потоков для обработки одинакового количества пользователей. И поскольку потоки используют значительные ресурсы, это означает, что служба будет более масштабируемой.

(И обратите внимание, что поток за запрос не означает, что инфраструктура должна закрыть HTTP-соединение после каждого запроса...)

Сказав это, модель потока за запрос не является идеальной, когда во время обработки каждого запроса есть длительные паузы. (И это особенно не идеально, когда служба использует метод comet, который предполагает сохранение открытого потока ответа в течение длительного времени.) Чтобы поддержать это, Servlet 3.0 spec предоставляет механизм "асинхронного сервлета", который позволяет методу запроса сервлета приостанавливать связь с текущим потоком запросов. Это освобождает поток для перехода и обработки другого запроса.

Если веб-приложение может быть спроектировано для использования "асинхронного" механизма, оно, вероятно, будет более масштабируемым, чем поток-за-запрос или поток за соединение.

Followup

Предположим, что одна веб-страница имеет 1000 изображений. Это приводит к 1001 HTTP-запросам. Далее предположим, что HTTP-постоянные соединения используются. Благодаря стратегии TPR это приведет к 1001 управлению пулами потоков (TPMO). Благодаря стратегии TPC это приведет к 1 TPMO... Теперь, в зависимости от фактических затрат для одного TPMO, я могу представить сценарии, в которых TPC может масштабироваться лучше, чем TPR.

Я думаю, что есть некоторые вещи, которые вы не рассматривали:

• Веб-браузер, столкнувшийся с большим количеством URL-адресов для извлечения для завершения страницы, может открыть несколько соединений.

• При использовании TPC и постоянных подключений поток должен ждать, пока клиент получит ответ и отправит следующий запрос. Это время ожидания может быть значительным, если высокая латентность сети.

• Сервер не может знать, когда данное (постоянное) соединение может быть закрыто. Если браузер не закрывает его, он может "задерживаться", привязывая поток TPC до тех пор, пока сервер не завершит соединение.

• Накладные расходы TPMO не огромны, особенно если вы отделяете накладные расходы пула от накладных расходов на коммутатор. (Вам нужно это сделать, поскольку TPC будет подвергать коммутаторы контекста постоянным соединениям, см. Выше.)

Я чувствую, что эти факторы, вероятно, перевешивают сохранение TPMO при наличии одного потока, посвященного каждому соединению.

Ответ 2

HTTP 1.1 - Поддерживает постоянные соединения, что означает, что более одного запроса/ответа могут быть получены/отправлены с использованием одного и того же HTTP-соединения. Поэтому для запуска этих запросов, полученных с использованием того же соединения параллельно, для каждого запроса создается новый Thread.

HTTP 1.0 - В этой версии только один запрос был получен с использованием соединения, и соединение было закрыто после отправки ответа. Таким образом, для одного соединения был создан только один поток.

Ответ 3

Thread per connection - это концепция повторного использования того же HTTP Connection из multiple requests (keep-alive).

Thread per request создаст поток для each request из client. Сервер может создать число threads в соответствии с request.

Ответ 4

Thread за запрос создаст поток для каждого HTTP-запроса, который получает сервер.

Thread для каждого соединения будет повторно использовать одно и то же HTTP-соединение из нескольких запросов (keep-alive).AKA HTTP-постоянное соединение но учтите, что это поддерживается только с HTTP 1.1

Thread Per Request выполняется быстрее, поскольку большинство веб-контейнеров используют объединение потоков.

Количество максимальных параллельных подключений, которые вы должны установить на количество ядер на вашем сервере. Больше ядер = > больше параллельных потоков.

См. здесь, как настроить... Tomcat 6: http://tomcat.apache.org/tomcat-6.0-doc/config/executor.html

Tomcat 7: http://tomcat.apache.org/tomcat-7.0-doc/config/executor.html

Пример

Ответ 5

Thread за запрос должен быть лучше, потому что он повторно использует потоки, в то время как некоторый клиент может быть бездействующим. Если у вас много одновременных пользователей, их можно обслуживать с меньшим количеством потоков и иметь равное количество потоков будет дороже. Также есть еще одно соображение - мы не знаем, работает ли пользователь с приложением, поэтому мы не можем знать, когда нужно уничтожить поток. С механизмом потока на запрос мы просто используем пул потоков.