В чем разница между потоком на соединение и потоком на запрос?
Можете ли вы объяснить две методологии, которые были реализованы в различных реализациях сервлетов:
- Поток на соединение
- Поток за запрос
Какая из двух вышеупомянутых стратегий лучше масштабируется и почему?
5 ответов
Какая из двух вышеупомянутых стратегий лучше масштабируется и почему?
Поток на запрос масштабируется лучше, чем поток на соединение.
Потоки Java довольно дороги, обычно используют каждый сегмент памяти по 1 Мб, независимо от того, активны они или нет. Если вы предоставляете каждому соединению свой собственный поток, поток обычно будет бездействовать между последовательными запросами на соединение. В конечном счете, фреймворк должен либо прекратить принимать новые соединения (потому что он не может создавать больше потоков), либо начать отключать старые соединения (что приводит к оттоку соединений, если / когда пользователь просыпается).
HTTP-соединение требует значительно меньше ресурсов, чем стек потоков, хотя существует ограничение в 64 КБ на каждый IP-адрес из-за способа работы TCP/IP.
Напротив, в модели потока на запрос поток ассоциируется только во время обработки запроса. Обычно это означает, что службе требуется меньше потоков для обработки одинакового количества пользователей. А поскольку потоки используют значительные ресурсы, это означает, что служба будет более масштабируемой.
(И обратите внимание, что поток на запрос не означает, что инфраструктура должна закрывать TCP-соединение между HTTP-запросом...)
Сказав это, модель потока на запрос не идеальна, когда есть длинные паузы во время обработки каждого запроса. (И это особенно неидеально, когда служба использует кометный подход, который предусматривает поддержание потока ответов открытым в течение длительного времени.) Для поддержки этого в спецификации Servlet 3.0 предусмотрен механизм "асинхронного сервлета", который позволяет методу запроса сервлета приостановить его связь с текущим потоком запросов. Это освобождает поток для обработки и обработки другого запроса.
Если веб-приложение может быть спроектировано для использования "асинхронного" механизма, оно, вероятно, будет более масштабируемым, чем поток-на-запрос или поток-на-соединение.
СЛЕДОВАТЬ ЗА
Давайте предположим одну веб-страницу с 1000 изображений. Это приводит к 1001 HTTP-запросам. Далее давайте предположим, что используются постоянные соединения HTTP. При стратегии TPR это приведет к 1001 операциям управления пулом потоков (TPMO). С помощью стратегии TPC это приведет к 1 TPMO... Теперь, в зависимости от фактических затрат на один TPMO, я могу представить сценарии, в которых TPC может масштабироваться лучше, чем TPR.
Я думаю, что есть некоторые вещи, которые вы не учли:
Веб-браузер, сталкивающийся с большим количеством URL-адресов для извлечения страницы, может открыть несколько соединений
При наличии TPC и постоянных соединений поток должен ждать, пока клиент получит ответ, и отправит следующий запрос. Это время ожидания может быть значительным, если задержка сети высока.
Сервер не может знать, когда данное (постоянное) соединение может быть закрыто. Если браузер не закроет его, он может "затянуться", связывая нить TPC до тех пор, пока сервер не прервет соединение.
Издержки TPMO невелики, особенно когда вы отделяете накладные расходы пула от накладных расходов на переключение контекста. (Это необходимо сделать, поскольку TPC будет выполнять переключение контекста на постоянных соединениях; см. Выше.)
Мне кажется, что эти факторы могут перевесить экономию TPMO, связанную с тем, что для каждого соединения выделен один поток.
HTTP 1.1 - Имеет поддержку постоянных соединений, что означает, что более одного запроса / ответа может быть получено / отправлено с использованием одного и того же соединения HTTP. Таким образом, чтобы запустить те запросы, полученные с использованием того же соединения параллельно, новый Thread создается для каждого запроса.
HTTP 1.0 - В этой версии только один запрос был получен через соединение, и соединение было закрыто после отправки ответа. Таким образом, только один поток был создан для одного соединения.
Thread per connection Концепция повторного использования одного и того же HTTP Connection от multiple requests( сохранить в живых).
Thread per requestсоздаст тему для each request из client.Server может создать ряд threads согласно request,
Поток на запрос создаст поток для каждого HTTP-запроса, который получает сервер.
Поток на соединение будет повторно использовать одно и то же соединение HTTP из нескольких запросов (keep-alive) .AKA Постоянное соединение HTTP, но обратите внимание, что это поддерживается только с HTTP 1.1
Thread Per Request быстрее, так как большинство веб-контейнеров используют Thread Pooling.
Максимальное количество параллельных соединений, которое вы должны установить на количество ядер на вашем сервере. Больше ядер => больше параллельных потоков.
Смотрите здесь, как настроить... 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
пример
Поток на запрос должен быть лучше, потому что он повторно использует потоки, в то время как некоторые клиенты могут простаивать. Если у вас много одновременных пользователей, они могут обслуживаться с меньшим количеством потоков, а одинаковое количество потоков будет более дорогим. Есть еще одно соображение - мы не знаем, работает ли пользователь с приложением, поэтому мы не можем знать, когда уничтожать поток. С механизмом потока на запрос мы просто используем пул потоков.