Суть использования асинхронных сервлетов в том, что мы можем вернуть DefferedResult(Если работать через spring). Это приводит к тому, что тред томката освобождается после того как мы передали управление в контроллер(если код правильно написать) освобождается и сразу становится свободным для принятия новых запросов. Далее контроллер вызывает сервис, базу в отдельном треде и как только у нас есть ответ, то мы говорим, что досчитали defferedResult и работа передаётся в тред томката.

Есть какой-то новый reactive spring webflux

https://stackoverflow.com/questions/46606246/spring-mvc-async-vs-spring-webflux/46621923

Я что-то не могу понять в чём принципиальное отличие.

servlet 3.1 вполне себе использует NIO https://stackoverflow.com/questions/39802643/java-async-in-servlet-3-0-vs-nio-in-servlet-3-1

Tomcat 8.5+ поддерживает это всё.

https://dzone.com/articles/servlet-31spring-mvc-non-blocking-io

Зачем тогда webflux?

Андрей ПанфиловquestionerСуть использования асинхронных сервлетов в том, что мы можем вернуть DefferedResult(Если работать через spring). Это приводит к тому, что тред томката освобождается после того как мы передали управление в контроллер(если код правильно написать) освобождается и сразу становится свободным для принятия новых запросов. Далее контроллер вызывает сервис, базу в отдельном треде и как только у нас есть ответ, то мы говорим, что досчитали defferedResult и работа передаётся в тред томката.В что что вы описали нет никакого смысла, какая разница между тем, что запрос обрабатывается в http-потоке или в каком-то другом? Разницы нет никакой, а профит появляется только тогда, когда мы умеем обрабатывать отложенные запросы пачками.

Это фича сервлет 3.0. Как я понимаю суть в том, чтобы сервер мог хотя бы принимать запросы даже если он не справляется с нагрузкой, чтобы все потоки контейнера не были заняты.
Например в томкате 100 потоков по дефолту и скажем запрос занимает 5 секунд. И к нам прилетает 101-ый запрос В случае 2.5 мы не можем принять запрос вообще, а в случае 3.0 мы спокойно примем запрос и передадим в другой пул с очередью. Если я ошибаюсь - хочу доказательства ибо такое не в одном месте встречал - например тут: https://stackoverflow.com/a/18187372/2674303

Андрей Панфилов, https://stackoverflow.com/a/3810625/2674303

Вот вообще похожая формулировка вопроса

PetroNotC SharpАндрей Панфилов,
+1

questionerЭто фича сервлет 3.0. Как я понимаю суть в том,
Все время суть от вас ускользает.
Вы писали хоть одно асинхронное на сервлетах?
То которое, крнтейнер не смог, а вы своим кодом смогли?
Теория без практики мертва.
Опять рассуждаете о DI не написав ни строчки кода в топике.

Уважаемый(нет), уймись уже. от тебя толку ноль.

Андрей ПанфиловquestionerЕсли я ошибаюсь - хочу доказательства ибо такое не в одном месте встречал - например тут: https://stackoverflow.com/a/18187372/2674303 Бгг, доказательств... вы сначала на пальцах попробуйте рассказать каким боком асинхронная обработка будет снимать нагрузку, в первом же приближении нам что "по классике", что "по новомодному" нужно один и тот же объем данных обработать и оснований полагать, что перенос обработки из одного места в другое что-то там может улучшить, нет никаких (есть малосущественный кейс с отдачей контента клиенту, но он решается более другими простыми способами).

Вот вы откуда-то выдумали:questionerЭто приводит к тому, что тред томката освобождается после того как мы передали управление в контроллер(если код правильно написать) освобождается и сразу становится свободным для принятия новых запросов.Ну освободили вы поток, что это дало-то? http-клиенту ничего не дало: он как ждал, так и будет продолжать ждать. Какой выигрыш вы получили для сервера? С большой долей вероятности вы наоборот потеряли: пока клиентские запросы висят в очереди они ничего не стоят, а как только вы их "частично обработали" и переложили в другую очередь то по крайней мере на памяти потеряли (плюс к этому контеншн с tcp-стека в лучшем случае на планировщик операционной системы переложили, а в худшем на базу). Думаете что у сервера приложений маленький пул? ну так увеличьте его, какая вам разница какой пул потоков увеличивать-то? Вот вам примеры из интернетов:
https://dzone.com/articles/spring-and-servlet-30-asynchronous-processing - мужик все правильно расписал

https://plumbr.io/blog/java/how-to-use-asynchronous-servlets-to-improve-performance - а вот это дичь, на которую вы ведетесь: подменили одно выполнение другим и говорим что стало лучше


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

Во первых контролировать тредпул на стороне приложения в любом случае удобнее. Мне не приходилось настраивать пул потоков в томкате, но могу предположить, что это несколько менее гибко, и скорее всего менее удобно. К тому же где гарантия, что все контейнеры это позволяют? Если в томкате 100 потоков и все они сейчас занимаются обработкой запроса, то 101 просто обломится, а не в очередь встанет. В случае с приложением мы можем настроить тредпул с очередью.

Ну вот ещё(автор если что ROSSEN STOYANCHEV):
https://spring.io/blog/2012/05/07/spring-mvc-3-2-preview-introducing-servlet-3-async-support In some cases you can return to the client immediately while a background job completes processing. For example sending an email, kicking off a database job, and others represent fire-and-forget scenarios that can be handled with Spring's @Async support or by posting an event to a Spring Integration channel and then returning a confirmation id the client can use to query for the results.

In other cases, where the result is required, we need to decouple processing from the Servlet container thread or else we'll exhaust its thread pool. Servlet 3 provides just such support where a Servlet (or a Spring MVC controller) can indicate the response should be left open after the Servlet container thread is exited.

To achieve this, a Servlet 3 web application can call request.startAsync() and use the returned AsyncContext to continue to write to the response from some other separate thread. At the same time from a client's perspective the request still looks like any other HTTP request-response interaction. It just takes longer to complete. The following is the sequence of events:

Client sends a request
Servlet container allocates a thread and invokes a servlet in it
The servlet calls request.startAsync(), saves the AsyncContext, and returns
The container thread is exited all the way but the response remains open
Some other thread uses the saved AsyncContext to complete the response
Client receives the response
https://spring.io/blog/2012/05/07/spring-mvc-3-2-preview-introducing-servlet-3-async-support

Про очередь конкретно у томката я прогнал, признаю - https://tomcat.apache.org/tomcat-9.0-doc/config/executor.html

PetroNotC SharpquestionerНу вот ещё(автор если что ROSSEN STOYANCHEV):
вы у автора уточните.
Он беспокоится за оптимизацию бэка или клиента?
У клиента при асинхронном программировании методом AJAX и так всё шеколадно.
Он ждёт Асинхронно ответ (в разумных пределах таймаута) и его ничего не парит.
Ему не нужно сразу возвращать управление(ответ).
Поэтому забудьте о клиенте при доказательствах нужности.

Вот неуёмный какой)) не угомониться ему никак.

Андрей Панфиловquestionerнагрузку не снимается, сервер имеет возможность лучше обрабатывать пиковые нагрузки.Физика под этим "лучше обрабатывать" какая лежит? Вот мы берем "типичное" приложение и затаскиваем весь говнокод из контроллеров в DefferedResult - в каком месте и из-за чего оно начнет что-то "лучше обрабатывать"? или таки есть специфичные кейсы где мы можем получить неиллюзорный профит а в остальных случаях ничего кроме геморроя не получить? Вы вообще задумывались по какой причине топят за всякие фиберы в жаве и реактивное программирование? почему поток - это плохо?

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

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

А вот тут Вы правильно заметили, но не развили мысль, а я уже забыл про это хотя пару лет назад читал.

https://www.javacodegeeks.com/2013/10/how-to-use-asynchronous-servlets-to-improve-performance.html
а лучше тут(в предыдущей ссылке не очень понятно как событие вызывается) https://plumbr.io/blog/java/how-to-use-asynchronous-servlets-to-improve-performance

В общем суть в том, что есть 100500 клиентов которые ждут например какой-то котировки, которая обновляется раз в 5 секунд и соответственно для клиента это ОК ждать какое-то время.

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


Андрей Панфилов ,
Теперь насчёт 3.0 мы одной волне?

PetroNotC SharpquestionerНу вот ещё(автор если что ROSSEN STOYANCHEV):
вы у автора уточните.
Он беспокоится за оптимизацию бэка или клиента?
У клиента при асинхронном программировании методом AJAX и так всё шеколадно.
Он ждёт Асинхронно ответ (в разумных пределах таймаута) и его ничего не парит.
Ему не нужно сразу возвращать управление(ответ).
Поэтому забудьте о клиенте при доказательствах нужности.

Всё таки умение увидеть в тексте абсолютно противоположное это искусство.

ОзверинquestionerА вот тут Вы правильно заметили, но не развили мысль, а я уже забыл про это хотя пару лет назад читал.

https://www.javacodegeeks.com/2013/10/how-to-use-asynchronous-servlets-to-improve-performance.html
а лучше тут(в предыдущей ссылке не очень понятно как событие вызывается) https://plumbr.io/blog/java/how-to-use-asynchronous-servlets-to-improve-performance

В общем суть в том, что есть 100500 клиентов которые ждут например какой-то котировки, которая обновляется раз в 5 секунд и соответственно для клиента это ОК ждать какое-то время.

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


Андрей Панфилов ,
Теперь насчёт 3.0 мы одной волне?

highload и low latency проекты могут пересекать, но в данном случае - latency вряд ли будет радовать, но пропускная способность - да.


Согласен, что на throughput оптимизация выглядит более очевидной, но у автора статьи и latency выросла тоже не кисло.

https://plumbr.io/blog/java/how-to-use-asynchronous-servlets-to-improve-performance This bit of code is a little more complex, so maybe before we start digging into solution details, I can outline that this solution performed ~5x better latency - and ~5x better throughput-wise Но это конкретный пример, надо это понимать.

Итого мы разобрались с поддержкой async в servlet 3.0

Давайте теперь с 3.1

Я понимаю, что 3.0 использует блокирующее IO и если у нас плохая сеть, большие запросы/ответы или медленный клиент, то тред контейнера может надолго захватиться и все наши усилия пойдут лесом. Servlet 3.1 использует NIO, что позволяет побороть данную проблему.
Теперь вернёмся к WebFlux:
https://spring.io/blog/2016/07/20/notes-on-reactive-programming-part-iii-a-simple-http-server-application Remember the same application code runs on Tomcat, Jetty or Netty. Currently, the Tomcat and Jetty support is provided on top of Servlet 3.1 asynchronous processing, so it is limited to one request per thread. When the same code runs on the Netty server platform that constraint is lifted, and the server can dispatch requests sympathetically to the web client. As long as the client doesn’t block, everyone is happy. Performance metrics for the netty server and client probably show similar characteristics, but the Netty server is not restricted to processing a single request per thread , so it doesn’t use a large thread pool and we might expect to see some differences in resource utilization. We will come back to that later in another article in this series.


Ну то есть servlet 3.1 и webFlux для томката это по сути одно и то же.

Я вот не могу понять смысла выделенной фразы. Что он имеет ввиду? в случае асинхронных сервлетов мы ведь уже принимаем запрос одним потоком, а возвращаем другим(скорее всего)
Следующей статьи я не нашёл) Видимо он её так и не написал

Озверин3. все таки надо понимать, что spring стал работать одноврменно над reactive репозиториями, без которых освобождение потока - такое себе счастье.
а кто там уже есть?

в 2016 году на момент написания статьи:

https://spring.io/blog/2016/07/20/notes-on-reactive-programming-part-iii-a-simple-http-server-application Very few databases support non-blocking clients at this point in time (MongoDB and Couchbase are notable exceptions, but even those are not as mature as the HTTP clients)

PetroNotC Sharpquestioner,
Ты не огрызайся, а думай. У тебя не первый топик с шиворот навыворот выводами.
Пиши код вместе с рассуждениями.
Про DI инверсию код написал?

У тебя всё хорошо? я за тебя переживаю. Все люди как люди, вносят вклад в топик, а ты ничего не понимаешь, а чего-то всё строчишь. ЧСВ повышаешь?

https://spring.io/blog/2018/12/07/reactive-programming-and-relational-databases As of now, there are three driver implementations:

PostgreSQL
H2
Microsoft SQL Server

Андрей ПанфиловquestionerВ общем суть в том, что есть 100500 клиентов которые ждут например какой-то котировки, которая обновляется раз в 5 секунд и соответственно для клиента это ОК ждать какое-то время.

Соответственно мы должны просто принять запрос и положить его в очередь. Когда пришло событие с новой котировкой мы просто забираем из очереди все запросы и отправляем клиентам эту котировку. Throughput взлетел до небес, Latency тоже радует.
Вы пытаетесь натянуть сову на глобус: чтобы отдать клиентам один и тот же ответ не нужно их ставить в очередь и обрабатывать запросы по два раза, достаточно результат в памяти разместить (или html под nginx положить и кроном обновлять ) и производительность будет заоблачной.



1. Где у меня по 2 раза обработка запроса?
2. Зависит от того чего хотим добиться. Если нужно отдавать старую котировку, то можно старую отдавать. Если хотят самую свежую, то придётся повисеть и подождать. Да и вообще, чтобы отдавать старую котировку асинхронные сервлеты вообще не нужны)


По Вашему то какой для 3.0 сервлетов юзкейс ?

questioner

https://spring.io/blog/2016/07/20/notes-on-reactive-programming-part-iii-a-simple-http-server-application Remember the same application code runs on Tomcat, Jetty or Netty. Currently, the Tomcat and Jetty support is provided on top of Servlet 3.1 asynchronous processing, so it is limited to one request per thread. When the same code runs on the Netty server platform that constraint is lifted, and the server can dispatch requests sympathetically to the web client. As long as the client doesn’t block, everyone is happy. Performance metrics for the netty server and client probably show similar characteristics, but the Netty server is not restricted to processing a single request per thread, so it doesn’t use a large thread pool and we might expect to see some differences in resource utilization. We will come back to that later in another article in this series.

Я вот не могу понять смысла выделенной фразы. Что он имеет ввиду? в случае асинхронных сервлетов мы ведь уже принимаем запрос одним потоком, а возвращаем другим(скорее всего)
Следующей статьи я не нашёл) Видимо он её так и не написал

Вот кстати с автором статьи связался и он исправил на

https://spring.io/blog/2016/07/20/notes-on-reactive-programming-part-iii-a-simple-http-server-application Remember the same application code runs on Tomcat, Jetty or Netty. Currently, the Tomcat and Jetty support is provided on top of Servlet 3.1 asynchronous processing, so it is no longer limited to one request per thread. It is build on top of a Reactive bridge that adapts the Servlet 3.1 concepts to the reactive paradigm. In the case of Reactor Netty, the backpressure and reactive support is built-in. Depending on your choice of HTTP client library, server and client might share the same HTTP resources and optimize things even more. We will come back to that later in another article in this series.

[quot Озверин]
В чем плюс? В том, что мы возвращаем ссылку на поток из другого пула, либо вообще на новый поток, таким образом не расходуя пул потоков веб сервера.


тут мы уже обсудили, что это весьма иллюзорно и иногда заменяемо конфигом сервера.

ОзверинТут на сцену выходит блоикровка ресурсов. Не смотря на то, что мы пытаемся вернуть ответ асинхронно, все равно некоторые операции могут "держать" поток запроса. Например, чо нить мы заливаем на сервак долгое. Что делать? Да тоже самое, но немного в другом ключе:

1. Сказать, хочу асинхронной работы
2. Дождаться когда контекст вернет новый поток, в котором будут средства для неблокирующего чтения ваших данных
3. В этом потоке уже заливать данные
4. Поток запроса отпустить.

Я вот это не совсем понял. Мне кажется это релевантно для медленного коннекшена или медленного клиента, который медленно шлёт или принимает. Какие ещё могут быть точки торможения я не представляю. То как там NIO будет работать с вводом выводом это уже не так интересно. Меня вполне удовлетворит абстракция, что она это сделает эффективно.



Озверин

В java8 никаких реактив стримов не было, была собственная имплементация от нетфликса - rxjava(вроде, если не ошибаюсь). Ее то и использовали поцоны из спринга. В java9 уже была rxjava2 вроде как, короче, реактив стримы стали ядром системы.



WebFlux построен на основе своего же спрингового Proactor(Не Rxjava то бишь)


авторЖаль тут парень какой-то black чего-то там не пишет больше. И форум в руках ...короче не у кого даже спросить, чтобы поправили.


Ага вот он "Blazkowicz" Сгинул отсюда(

Андрей ПанфиловНу вы рассказали что происходит, а в чем же плюс рассказать забыли :)
ешё раз повторю к Вам вопрос:
Так просветите тогда уж раз уж Вы не согласны)

Озверинquestioner, чето был уверен, что все таки с rxjava они, оказалось да..Reactor у них свой. Просто они черпали идеи из rxjava - где-то читал, потому и осело в голове.


авторЯ вот это не совсем понял. Мне кажется это релевантно для медленного коннекшена или медленного клиента, который медленно шлёт или принимает. Какие ещё могут быть точки торможения я не представляю. То как там NIO будет работать с вводом выводом это уже не так интересно. Меня вполне удовлетворит абстракция, что она это сделает эффективно.

не понял, если честно ;)
Вот что пишет чувак из Pivotal:

https://stackoverflow.com/a/56808576/2674303 When using Servlet 2.5, Servlet containers will assign a request to a thread until that request has been fully processed.

When using Servlet 3.0 async processing, the server can dispatch the request processing in a separate thread pool while the request is being processed by the application. However, when it comes to I/O, work always happens on a server thread and it is always blocking. This means that a "slow client" can monopolize a server thread, since the server is blocked while reading/writing to that client with a poor network connection.

With Servlet 3.1, async I/O is allowed and in that case the "one request/thread" model isn't anymore. At any point a bit request processing can be scheduled on a different thread managed by the server.

Servlet 3.1+ containers offer all those possibilities with the Servlet API. It's up to the application to leverage async processing, or non-blocking I/O. In the case of non-blocking I/O, the paradigm change is important and it's really challenging to use.

With Spring WebFlux - Tomcat, Jetty and Netty don't have the exact same runtime model, but they all support reactive backpressure and non-blocking I/O.

Андрей Панфиловquestionerешё раз повторю к Вам вопрос:
Так просветите тогда уж раз уж Вы не согласны)Ваш вопрос на самом деле звучит так: я решил что с левой ноги вставать лучше, обоснуйте почему я неправ. Операционная система предоставляет две возможности, вокруг которых крутится вся оптимизация: Zero Copy (DMA и sendfile) - не копируем данные в user space, и Async I/O - не ждем ответа, а узнаем есть что новое для нас или нет. Если у вас приложение не умеет ни то, ни другое, то толку от асинхронной обработки http нет никакого, потому что совершенно нет никакой разницы в каком потоке выполнятьсяждать.


Продолжайте мысль....
Вопрос вполне конкретный. Приведите пример при каком юзкейсе servlet 3.0 даст преимущество перед servlet 2.5

Basil A. SidorovСемантика асинхронного контекста сервлетов 3.0 позволяет контейнеру оптимизировать управление ресурсами. Реализованы эти оптимизации в конкретном контейнере и возможно ли их задействовать в конкретном сценарии - вопрос отдельный.

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

Хотелось бы побольше конкретики