Андрей Панфилов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" Сгинул отсюда(

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