Асинхронные сервлеты против синхронных сервлетов

Question

Начиная с Servlet 3.0 поддерживается асинхронная обработка . Было бы лучше, чтобы всегда использовать асинхронную обработку? Или в каких случаях синхронная обработка лучше?

Answer 1

Большая вещь, которую вы получаете с асинхронными сервлетами, - это HTTP push , где сервер может отправлять информацию обратно клиенту по своему усмотрению, а не когда клиент запрашивает ее. Предварительно асинхронные сервлеты, это потребует длительных HTTP-соединений, каждое из которых связано с серверным потоком, что очень неэффективно. Эта новая модель отделяет обработку на стороне сервера от обработки соединения.

Answer 2

Читая статью, поддержка асинхронной обработки в спецификации Servlet 3.0 имеет очень специфический вариант использования - он предназначен для обработки случая, когда у вас есть приложение AJAX, которое выполняет запросы, которые запускают потенциально длительные процессы в фоновом режиме.

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

В частности, если запрос AJAX вызывает что-то потенциально медленное или блокирующее, например, операцию с базой данных, мы возвращаемся к тому, с чего начали - потоки из пула потоков сервера потенциально простаивают.

Поддержка асинхронной обработки пытается смягчить это, помещая запросы в централизованную очередь, так что потоки не всегда застревают в ожидании результатов запросов, которые еще не начали обрабатываться. Короче говоря, мы пытаемся извлечь максимальную выгоду из наших потоков из всех потоков - то есть, уменьшая количество времени, когда они простаивают (но могут обслуживать какое-то другое соединение).

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

Answer 3

Асинхронная обработка была введена для случаев, когда нет необходимости удерживать поток в течение всего цикла обработки запроса. Типичным примером такого случая является комета -подобная функциональность.

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

Answer 4

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

Подводя итог статьи:

Вы хотели бы использовать асинхронные сервлеты в ситуации, когда у вас загружается множество запросов (аналогично загрузке вашего сервера запросами AJAX), и вы не хотите обслуживать один поток на запрос. TPR может быть опасным в этом сценарии, когда время обработки занимает немного времени, что приводит к исчерпанию пула потоков.

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

Довольно классные вещи.

Answer 5

Он основан на требованиях, при которых шансы получить поток в состоянии простоя в такой ситуации вам следует использовать асинхронный сервлет, в противном случае мы не можем создать столько потоков

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

Чтобы включить асинхронную обработку в сервлете, задайте для параметра asyncSupported значение true в @Аннотация WebServlet выглядит следующим образом:

@ WebServlet (urlPatterns = {"/ asyncservlet"}, asyncSupported = true) открытый класс AsyncServlet расширяет HttpServlet {...}

Синхронный (классическая модель веб-приложений)) Синхронный запрос блокирует клиента до завершения операции, т.е. браузер не перестает отвечать на запросы.В этом случае механизм java-скриптов браузера блокируется.

Асинхронный (модель веб-приложения AJAX) Асинхронный запрос не блокирует клиента, т. Е. Браузер реагирует.В это время пользователь может выполнять и другие операции.В этом случае движок java-скриптов браузера не блокируется.

При синхронном взаимодействии оба активны одновременно, тогда как в асинхронном режиме не требуется активировать одновременно, например, асинхронный относится к обмену сообщениями там.блокирование операции для нового потока и запуск потока, связанного с контейнером

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

Существует два распространенных сценария, в которых поток связан с запросом.можно сидеть без дела.

The thread needs to wait for a resource to become available or process data before building the response. For example, an application may need to query a database or access data from a remote web service before generating the response.

The thread needs to wait for an event before generating the response. For example, an application may have to wait for a JMS message, new information from another client, or new data available in a queue before generating the response.