Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Java Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2 3 4 5 6      [все]
 Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
questioner
Member

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

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

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

Я что-то не могу понять в чём принципиальное отличие.
27 июн 19, 16:59    [21916432]     Ответить | Цитировать Сообщить модератору
 Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 552
questioner,
Зачем дубль темы?
27 июн 19, 17:12    [21916452]     Ответить | Цитировать Сообщить модератору
 Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
questioner
Member

Откуда:
Сообщений: 1712
servlet 3.1 вполне себе использует NIO https://stackoverflow.com/questions/39802643/java-async-in-servlet-3-0-vs-nio-in-servlet-3-1
27 июн 19, 17:22    [21916457]     Ответить | Цитировать Сообщить модератору
 Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
questioner
Member

Откуда:
Сообщений: 1712
Tomcat 8.5+ поддерживает это всё.

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

Зачем тогда webflux?
27 июн 19, 17:25    [21916462]     Ответить | Цитировать Сообщить модератору
 Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 552
questioner
Зачем тогда webflux?
а зачем ты подымаешь всё Г. которое на земле валяется?
Это хайповое реактивное программирование.
Совсем другое по сути.
27 июн 19, 17:30    [21916466]     Ответить | Цитировать Сообщить модератору
 Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
redwhite90
Member

Откуда:
Сообщений: 1901
PetroNotC Sharp
questioner
Зачем тогда webflux?
а зачем ты подымаешь всё Г. которое на земле валяется?
Это хайповое реактивное программирование.
Совсем другое по сути.


Ты тут чтоб на вентилятор накинуть? Нечего ответить - помолчи.


Weblflux построен на servlet 3.1 для томката, так что никакой магии нет. Еще есть Фишечка, что эта либа умеет в рантайме размеры внутренних пулов тюнить
27 июн 19, 18:36    [21916520]     Ответить | Цитировать Сообщить модератору
 Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 552
redwhite90
Нечего ответить - помолчи.
жду твое молчание на
Flux<T>
27 июн 19, 18:53    [21916538]     Ответить | Цитировать Сообщить модератору
 Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
redwhite90
Member

Откуда:
Сообщений: 1901
PetroNotC Sharp
redwhite90
Нечего ответить - помолчи.
жду твое молчание на
Flux<T>


Что?
27 июн 19, 19:08    [21916558]     Ответить | Цитировать Сообщить модератору
 Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3247
questioner
Суть использования асинхронных сервлетов в том, что мы можем вернуть DefferedResult(Если работать через spring). Это приводит к тому, что тред томката освобождается после того как мы передали управление в контроллер(если код правильно написать) освобождается и сразу становится свободным для принятия новых запросов. Далее контроллер вызывает сервис, базу в отдельном треде и как только у нас есть ответ, то мы говорим, что досчитали defferedResult и работа передаётся в тред томката.
В что что вы описали нет никакого смысла, какая разница между тем, что запрос обрабатывается в http-потоке или в каком-то другом? Разницы нет никакой, а профит появляется только тогда, когда мы умеем обрабатывать отложенные запросы пачками.
27 июн 19, 19:19    [21916572]     Ответить | Цитировать Сообщить модератору
 Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 552
redwhite90
PetroNotC Sharp
пропущено...
жду твое молчание на
Flux<T>


Что?
нечего по теме сказать - молчи.
27 июн 19, 19:44    [21916585]     Ответить | Цитировать Сообщить модератору
 Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
questioner
Member

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


Это фича сервлет 3.0. Как я понимаю суть в том, чтобы сервер мог хотя бы принимать запросы даже если он не справляется с нагрузкой, чтобы все потоки контейнера не были заняты.
Например в томкате 100 потоков по дефолту и скажем запрос занимает 5 секунд. И к нам прилетает 101-ый запрос В случае 2.5 мы не можем принять запрос вообще, а в случае 3.0 мы спокойно примем запрос и передадим в другой пул с очередью. Если я ошибаюсь - хочу доказательства ибо такое не в одном месте встречал - например тут: https://stackoverflow.com/a/18187372/2674303
27 июн 19, 23:48    [21916669]     Ответить | Цитировать Сообщить модератору
 Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
questioner
Member

Откуда:
Сообщений: 1712
Андрей Панфилов, https://stackoverflow.com/a/3810625/2674303

Вот вообще похожая формулировка вопроса
28 июн 19, 00:02    [21916673]     Ответить | Цитировать Сообщить модератору
 Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3247
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 - а вот это дичь, на которую вы ведетесь: подменили одно выполнение другим и говорим что стало лучше
  • 28 июн 19, 01:23    [21916679]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    Андрей Панфилов,
    +1

    questioner
    Это фича сервлет 3.0. Как я понимаю суть в том,

    Все время суть от вас ускользает.
    Вы писали хоть одно асинхронное на сервлетах?
    То которое, крнтейнер не смог, а вы своим кодом смогли?
    Теория без практики мертва.
    Опять рассуждаете о DI не написав ни строчки кода в топике.
    28 июн 19, 09:23    [21916741]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    Андрей Панфилов
    Ну освободили вы поток, что это дало-то?

    OFF/2
    В шарпе MS такая парадигма. Потому что у них нет контейнера с потоками и прогеры сами пишут Async через строчку.
    Типо помогают серверу.
    Но думаю что скоро перейдут к решению из java. Уж очень муторный код в итоге на бэке.
    Имхо
    28 июн 19, 09:37    [21916752]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

    Откуда:
    Сообщений: 1712
    PetroNotC Sharp
    Андрей Панфилов,
    +1

    questioner
    Это фича сервлет 3.0. Как я понимаю суть в том,

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


    Уважаемый(нет), уймись уже. от тебя толку ноль.
    28 июн 19, 11:17    [21916864]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    questioner,
    Почему то каждый, кто пилит код лет 5, или около того считает что может разговаривать про архитектуру.
    Увы. Это другая область знаний.
    ДРУГАЯ.
    Поэтому, мембер, мне не надо отвечать. Разговаривай по теме топика.
    28 июн 19, 11:31    [21916874]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

    Откуда:
    Сообщений: 1712
    Андрей Панфилов
    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
    28 июн 19, 11:33    [21916879]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

    Откуда:
    Сообщений: 1712
    Про очередь конкретно у томката я прогнал, признаю - https://tomcat.apache.org/tomcat-9.0-doc/config/executor.html
    28 июн 19, 11:56    [21916902]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Андрей Панфилов
    Member

    Откуда: Москва > Melbourne
    Сообщений: 3247
    questioner
    нагрузку не снимается, сервер имеет возможность лучше обрабатывать пиковые нагрузки.
    Физика под этим "лучше обрабатывать" какая лежит? Вот мы берем "типичное" приложение и затаскиваем весь говнокод из контроллеров в DefferedResult - в каком месте и из-за чего оно начнет что-то "лучше обрабатывать"? или таки есть специфичные кейсы где мы можем получить неиллюзорный профит а в остальных случаях ничего кроме геморроя не получить? Вы вообще задумывались по какой причине топят за всякие фиберы в жаве и реактивное программирование? почему поток - это плохо?
    28 июн 19, 12:22    [21916929]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    сладкий бубалех
    Member

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


    почему нет смысла? а как на счет того, что поток это жирно для ОС(процесс для ОС еще жирнее, к примеру) и мы можем переложить выполнение некоторых задач(чтение-запись файла) на потоки ядра, которые еще сильнее оптимизированы и тоньше.
    nginx работающий по такому принципу, значительно производительнее apache, который создает потоки для каждого подключения
    28 июн 19, 12:33    [21916943]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    questioner
    Ну вот ещё(автор если что ROSSEN STOYANCHEV):

    вы у автора уточните.
    Он беспокоится за оптимизацию бэка или клиента?
    У клиента при асинхронном программировании методом AJAX и так всё шеколадно.
    Он ждёт Асинхронно ответ (в разумных пределах таймаута) и его ничего не парит.
    Ему не нужно сразу возвращать управление(ответ).
    Поэтому забудьте о клиенте при доказательствах нужности.
    28 июн 19, 12:37    [21916946]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

    Откуда:
    Сообщений: 1712
    PetroNotC Sharp
    questioner
    Ну вот ещё(автор если что ROSSEN STOYANCHEV):

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


    Вот неуёмный какой)) не угомониться ему никак.
    28 июн 19, 12:40    [21916949]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    сладкий бубалех
    что поток это жирно для ОС

    Контейнер создавали чтобы в прикладном коде программист меньше думал о потоках.
    Иначе нужны цифры и доказательства. Накладные расходы растут.
    28 июн 19, 12:40    [21916950]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    questioner
    Вот неуёмный какой)) не угомониться ему никак.

    по теме, по теме пишите.
    А то вы сначала отвечаете, а потом ссылки читаете)).
    28 июн 19, 12:41    [21916952]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

    Откуда:
    Сообщений: 1712
    Андрей Панфилов
    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 мы одной волне?
    28 июн 19, 12:56    [21916963]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Андрей Панфилов
    Member

    Откуда: Москва > Melbourne
    Сообщений: 3247
    сладкий бубалех
    почему нет смысла? а как на счет того, что поток это жирно для ОС(процесс для ОС еще жирнее, к примеру) и мы можем переложить выполнение некоторых задач(чтение-запись файла) на потоки ядра, которые еще сильнее оптимизированы и тоньше.
    nginx работающий по такому принципу, значительно производительнее apache, который создает потоки для каждого подключения
    Потому что чтобы получить профит должен быть определенный паттерн работы сервиса, ну например как в сеансе одновременной игры в шахматы: гроссмейстер может одновременно с несколькими нубами играть, просто потому что может, а одновременно с такими же по уровню - кишка тонка. Здесь то же самое: тыще клиентов отправить один и тот же ответ с некоторой приемлемой задержкой - прекрасно перекладывается на асинхронную обработку, а посчитать классический Фибоначчи - профита не будет никакого. Хотим с СУБД как-то хитро работать? нет проблем, только нужно будет забыть про консистентность.
    28 июн 19, 13:04    [21916972]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    lleming
    Member

    Откуда:
    Сообщений: 1595
    Андрей Панфилов
    Чтобы получить профит должен быть определенный паттерн работы сервиса


    Прям резюмировал топик +5.
    28 июн 19, 13:33    [21917014]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

    Откуда:
    Сообщений: 1712
    PetroNotC Sharp
    questioner
    Ну вот ещё(автор если что ROSSEN STOYANCHEV):

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


    Всё таки умение увидеть в тексте абсолютно противоположное это искусство.
    28 июн 19, 13:38    [21917023]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Озверин
    Member

    Откуда: Ростов-на-Дону
    Сообщений: 5183
    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 вряд ли будет радовать, но пропускная способность - да.
    28 июн 19, 13:48    [21917035]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Озверин
    Member

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

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

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

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


    1. когда родились так называемые асинхронные сервлеты 3.0 - запросо то там были асинхронными, но io все еще было стандартным - блокирующим. В 3.1 исправили, но webflux стал рождаться раньше.

    2. webflux добавил сахаара из стримов

    3. все таки надо понимать, что spring стал работать одноврменно над reactive репозиториями, без которых освобождение потока - такое себе счастье.
    28 июн 19, 14:01    [21917049]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

    Откуда:
    Сообщений: 1712
    Озверин
    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 для томката это по сути одно и то же.

    Я вот не могу понять смысла выделенной фразы. Что он имеет ввиду? в случае асинхронных сервлетов мы ведь уже принимаем запрос одним потоком, а возвращаем другим(скорее всего)
    Следующей статьи я не нашёл) Видимо он её так и не написал
    28 июн 19, 14:11    [21917060]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    questioner,
    Ты не огрызайся, а думай. У тебя не первый топик с шиворот навыворот выводами.
    Пиши код вместе с рассуждениями.
    Про DI инверсию код написал?
    28 июн 19, 14:12    [21917061]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

    Откуда:
    Сообщений: 1712
    Озверин
    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)
    28 июн 19, 14:16    [21917065]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

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


    У тебя всё хорошо? я за тебя переживаю. Все люди как люди, вносят вклад в топик, а ты ничего не понимаешь, а чего-то всё строчишь. ЧСВ повышаешь?
    28 июн 19, 14:18    [21917072]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Андрей Панфилов
    Member

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

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

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

    questioner
    Теперь насчёт 3.0 мы одной волне?
    Определенно нет.
    28 июн 19, 14:18    [21917073]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

    Откуда:
    Сообщений: 1712
    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
    28 июн 19, 14:20    [21917078]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

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

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

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



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


    По Вашему то какой для 3.0 сервлетов юзкейс ?
    28 июн 19, 14:28    [21917085]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    questioner,
    И где в топике прошлом по DI ты что нибудь понял?
    Вот поэтому ты и флудишь мне)
    28 июн 19, 14:39    [21917094]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    redwhite90
    Member

    Откуда:
    Сообщений: 1901
    PetroNotC Sharp
    questioner,
    И где в топике прошлом по DI ты что нибудь понял?
    Вот поэтому ты и флудишь мне)


    Все, я больше умственно отсталым не отвечаю.
    28 июн 19, 14:56    [21917119]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    redwhite90, наконец то тебе дошло и больше флудить без аргументов не будем.
    28 июн 19, 15:25    [21917140]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Озверин
    Member

    Откуда: Ростов-на-Дону
    Сообщений: 5183
    questioner, если смотреть на всю архитектуру запросов и что изменилось:

    1. В версии http 1.0 каждый запрос порождал соединение. Запрос - соединение создается - ответ - соединение закрывается
    1.2. Один запрос - один поток. Причем это дорогой поток, потому что является блокироующим: и поток, и ресурсы(база, файл, io).


    Тут кроется проблема - скорость! http 1. 0 медленный из-за того, что на каждый запрос приходится открывать и закрывать соединение

    2. В версии http 1.1 в рамках одного соединения может быть несколько запросов, каждый из которых будет в своем отдельном потоке.
    Скорость увеличивается для клиентов, которые посылают запросы пачками, но, возникает проблема, что web container быстро расходует pool потоков.

    Для чего вообще пул потоков существует? Само собой для latency - создание потока - дорогая операция(и по скорости, и по памяти). Потому web server`ы на старте создают пул потоков и используют потоки для request`ов из него.

    Идем дальше, если у нас появилось большое кол-во потоков, то нам надо как-то сделать так, чтобы эти потоки были "короткими", т.е. чтобы они быстро возвращались в pool.
    Вот тут вступает асинхронность версии 3.0. Мы передаем запрос в новый поток, а в текущем потоке возвращаем "ссылку" на поток и текущий поток возвращаем в pool.

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

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

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


    Как-то так я себе все это представляю.
    28 июн 19, 17:06    [21917223]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

    Откуда:
    Сообщений: 1712
    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.
    28 июн 19, 17:18    [21917232]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Озверин
    Member

    Откуда: Ростов-на-Дону
    Сообщений: 5183
    questioner, теперь к webflux. Скажем так, в основе его лежит СОВЕРШЕНО другая парадигма, тем не менее, которая решает похожие задчи. В основе лежат reactive streams - асинхроннные потоки которые можно СЛУШАТЬ. По сути - это event driven архитектура с продюсерами и подписчиками. Я думаю, не надо тут глубок расписывать плюсы от подобной архитектуры - итак понятно.

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

    И насчет потоков и разницы между tomcat и netty.
    Tomcat - стандартный веб контейнер, который имплементирует текущую реализацию http 1.1 с переиспользованием одного соединения для нескольких запросов, КАЖДЫЙ ИЗ КОТОРЫХ порождает один поток.

    Тогда как Netty - ну это в первую очреедь некий event driven инструмент, из которого МОЖНО сделать web сервер, у которого правда будет совершенно другая начинка, нежели чем у Tomcat`а. Но тут я честно сказать netty не использовал особо, потому ...не сварщик.
    28 июн 19, 17:20    [21917234]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Озверин
    Member

    Откуда: Ростов-на-Дону
    Сообщений: 5183
    Жаль тут парень какой-то black чего-то там не пишет больше. И форум в руках ...короче не у кого даже спросить, чтобы поправили.
    28 июн 19, 17:23    [21917235]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    Озверин
    СОВЕРШЕНО другая парадигма
    +1
    Реактивная.
    Причем эта парадигма не подменяет и не улучшает rest.
    Она просто идет рядом и не факт что не сгинет через пару лет.
    Можно пробовать, но переписывать классику на "это" не стоит.
    Мои сожаления автору топика.
    28 июн 19, 17:33    [21917240]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    Озверин
    МОЖНО сделать web сервер

    Угу.
    Типа
    HttpServer
    .create("localhost", 8080)
    .newHandler(new ReactorHttpHandlerAdapter(httpHandler))
    .block();
    ...
    MS счас этим балуется со своим kestrel.
    28 июн 19, 17:40    [21917243]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Андрей Панфилов
    Member

    Откуда: Москва > Melbourne
    Сообщений: 3247
    Озверин
    Тут кроется проблема - скорость! http 1. 0 медленный из-за того, что на каждый запрос приходится открывать и закрывать соединение
    Не совсем так, насколько я помню, разницы между включенным и выключенным keepalive нет, если не используется SSL/TLS, вот рукопожатие TLS действительно дорогое и без keepalive никуда, в тоже время всякие forward-proxy и терминаторы TLS к бэкенду как раз без keepalive ходят (не уверен как сейчас, но когда я этими вещами занимался года до 2008 все так и было)

    Озверин
    Для чего вообще пул потоков существует? Само собой для latency - создание потока - дорогая операция(и по скорости, и по памяти). Потому web server`ы на старте создают пул потоков и используют потоки для request`ов из него.
    дорого - понятие относительное, относительно создания объекта или сложения 1+1, да, дорого, а в сравнении со "сходить в базу", уже и не дорого Основная проблема тут больше в том, что "глупый" планировщик ОС ничего о приложении не знает и наивно выдает кванты времени потокам, которым выполнение в данный момент не нужно ну и про между прочим контексты переключает и пр, вообщем performance penalty здесь очевидный, и пулы потоков используют больше не потому что дорого создавать, а потому что это довольно простой способ ограничить число экзекьюшн юнитов сверху.

    Озверин
    В чем плюс? В том, что мы возвращаем ссылку на поток из другого пула, либо вообще на новый поток, таким образом не расходуя пул потоков веб сервера.
    Ну вы рассказали что происходит, а в чем же плюс рассказать забыли :)
    28 июн 19, 17:56    [21917249]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

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


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

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

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

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



    Озверин


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



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


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


    Ага вот он https://www.sql.ru/forum/memberinfo.aspx?mid=88056 Сгинул отсюда(
    28 июн 19, 18:17    [21917257]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

    Откуда:
    Сообщений: 1712
    Андрей Панфилов
    Ну вы рассказали что происходит, а в чем же плюс рассказать забыли :)

    ешё раз повторю к Вам вопрос:
    Так просветите тогда уж раз уж Вы не согласны)
    28 июн 19, 18:22    [21917262]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Андрей Панфилов
    Member

    Откуда: Москва > Melbourne
    Сообщений: 3247
    questioner
    ешё раз повторю к Вам вопрос:
    Так просветите тогда уж раз уж Вы не согласны)
    Ваш вопрос на самом деле звучит так: я решил что с левой ноги вставать лучше, обоснуйте почему я неправ. Операционная система предоставляет две возможности, вокруг которых крутится вся оптимизация: Zero Copy (DMA и sendfile) - не копируем данные в user space, и Async I/O - не ждем ответа, а узнаем есть что новое для нас или нет. Если у вас приложение не умеет ни то, ни другое, то толку от асинхронной обработки http нет никакого, потому что совершенно нет никакой разницы в каком потоке выполнятьсяждать.
    28 июн 19, 18:53    [21917285]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Озверин
    Member

    Откуда: Ростов-на-Дону
    Сообщений: 5183
    Андрей Панфилов, так плюсов в использовании servlet 3.1 нет?
    28 июн 19, 19:58    [21917318]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Озверин
    Member

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


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


    не понял, если честно ;)
    28 июн 19, 20:02    [21917321]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    lleming
    Member

    Откуда:
    Сообщений: 1595
    Озверин
    Андрей Панфилов, так плюсов в использовании servlet 3.1 нет?


    в плане производительности ?

    Тащем та я как понял, это еще один API который позволяте использовать потоки контейнера вместо самодельного велосипета что вкупе с особоненостями tomcat можно получить неприятные эффекты.

    Из гуд ньюз то потоки управляемые контейнером, контейнер имеет доступ и может управлять их жизненным циклом. Ежели томкату скажут "все" то он сможем им передать этим потокам что "все". С самодельными потоками часто никто не заморачивается их привзякой к томкату.
    28 июн 19, 20:22    [21917329]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

    Откуда:
    Сообщений: 1712
    Озверин
    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.
    28 июн 19, 20:50    [21917340]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

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



    Продолжайте мысль....
    Вопрос вполне конкретный. Приведите пример при каком юзкейсе servlet 3.0 даст преимущество перед servlet 2.5
    28 июн 19, 20:53    [21917342]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    Озверин
    плюсов в использовании servlet 3.1 нет?
    народ скорее кафкой масштабировать будет)
    28 июн 19, 21:03    [21917348]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Basil A. Sidorov
    Member

    Откуда:
    Сообщений: 9178
    Озверин
    1. В версии http 1.0 каждый запрос порождал соединение. Запрос - соединение создается - ответ - соединение закрывается
    1.2. Один запрос - один поток. Причем это дорогой поток, потому что является блокироующим: и поток, и ресурсы(база, файл, io).

    Тут кроется проблема - скорость! http 1. 0 медленный из-за того, что на каждый запрос приходится открывать и закрывать соединение

    2. В версии http 1.1 в рамках одного соединения может быть несколько запросов, каждый из которых будет в своем отдельном потоке.
    Скорость увеличивается для клиентов, которые посылают запросы пачками, но, возникает проблема, что web container быстро расходует pool потоков.
    "Смешались в кучу кони, люди ..."
    Постоянные подключения появились уже в HTTP/1.0 (прагма keep-alive). HTTP/1.1 сделал постоянные подключения вариантом по умолчанию (Connection: close). Детали когда "можно постоянные подключения" - опускаются.
    Постоянные подключения сами по себе не увеличивают число потоков исполнения - запросы продолжают поступать и обрабатываться строго последовательно.
    Установление подключения - десятки-сотни миллисекунд и для запросов продолжительнее трёх-пяти секунд это не очень существенно. При некоторых оговорках, которые могут и не выполняться.
    Поток не может быть "дорогим" - если для исполнения требуются определённые ресурсы, то придётся их потратить в любом случае.

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

    Асинхронный ввод-вывод в сервлетах 3.1 позволяет задействовать (и достаточно просто) оптимизации ввода-вывода не только на уровне контейнера, но и в прикладном коде. Будет с этого какой-то выигрыш - вопрос, опять-таки, отдельный.
    28 июн 19, 21:23    [21917356]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    Basil A. Sidorov
    Будет с этого какой-то выигрыш - вопрос, опять-таки, отдельный.

    если ты заметил, то ТС докопался до разницы между левой ногой и правой. Или между 3.1 и WebFlux
    ))
    28 июн 19, 22:22    [21917367]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

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

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


    Хотелось бы побольше конкретики
    28 июн 19, 23:33    [21917386]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

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


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


    не понял, если честно ;)

    вот ещё по этому поводу что пишут: https://stackoverflow.com/a/40231294/2674303
    28 июн 19, 23:35    [21917388]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Андрей Панфилов
    Member

    Откуда: Москва > Melbourne
    Сообщений: 3247
    Озверин
    так плюсов в использовании servlet 3.1 нет?
    Если видосики не стримить, то в текущей реализации/инфраструктуре как-то никаких преимуществ не видно - оно же определяет только общение с клиентом, а не весь стэк (медленный клиент - это страшилка из начала 2000-х, когда P4 с гигабайтом памяти считалось приличным железом, сейчас же мощности совсем другие, да и жава голой жопой в интернеты обычно не торчит: либо intranet, либо через балансировщик/reverse-proxy)
    29 июн 19, 08:08    [21917416]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Озверин
    Member

    Откуда: Ростов-на-Дону
    Сообщений: 5183
    Можно почитать некоторые тесты:
    https://medium.com/@filia.aleks/microservice-performance-battle-spring-mvc-vs-webflux-80d39fd81bf0
    1 июл 19, 09:54    [21917931]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    Озверин,
    Ссылка требует регистрации.
    1 июл 19, 10:37    [21917956]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Озверин
    Member

    Откуда: Ростов-на-Дону
    Сообщений: 5183
    PetroNotC Sharp, у меня не требует, язх.
    1 июл 19, 10:38    [21917958]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    Озверин,
    Открыл в режиме инкогнито - работает. Наверно куки влияют.
    Более 3х раз сайт читать не дает))))
    1 июл 19, 10:46    [21917963]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

    Откуда:
    Сообщений: 1712
    Андрей Панфилов
    Озверин
    так плюсов в использовании servlet 3.1 нет?
    Если видосики не стримить, то в текущей реализации/инфраструктуре как-то никаких преимуществ не видно - оно же определяет только общение с клиентом, а не весь стэк (медленный клиент - это страшилка из начала 2000-х, когда P4 с гигабайтом памяти считалось приличным железом, сейчас же мощности совсем другие, да и жава голой жопой в интернеты обычно не торчит: либо intranet, либо через балансировщик/reverse-proxy)


    Как-то звучит странно. Особо никто про стриминг не пишет в описании servlet 3.1

    Думается, что не идиоты это придумали и у них была мотивация делать то, что они сделали
    1 июл 19, 10:54    [21917968]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    Озверин
    Можно почитать некоторые тесты:
    https://medium.com/@filia.aleks/microservice-performance-battle-spring-mvc-vs-webflux-80d39fd81bf0
    опять микросервисы)
    1 июл 19, 10:58    [21917971]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Андрей Панфилов
    Member

    Откуда: Москва > Melbourne
    Сообщений: 3247
    Озверин
    Можно почитать некоторые тесты:
    https://medium.com/@filia.aleks/microservice-performance-battle-spring-mvc-vs-webflux-80d39fd81bf0
    Написанное можно по разному читать. Для начала, ну вот есть там ограниченные ресурсы и возможность использовать async i/o, ну и используют. С другой стороны получается так: был прекрасный монолит с общением через память, заменили микросервисами с тормозным http, с апломбом что якобы монолит не масштабируется, как итог сторонний сервис умеет 4 тыщи запросов в секунду, а тормознутые микросервисы и до 2 тыщ не дотянули, зато масштабируется.
    1 июл 19, 11:34    [21917992]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Андрей Панфилов
    Member

    Откуда: Москва > Melbourne
    Сообщений: 3247
    questioner
    Как-то звучит странно. Особо никто про стриминг не пишет в описании servlet 3.1

    Думается, что не идиоты это придумали и у них была мотивация делать то, что они сделали
    Не представляю как можно так тупить-то.... вот зачем вы приводите ссылки, цитаты и прочую ересь, если сами их не читаете?
    questioner
    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.
    Вопрос: сколько можно в сокет написать без блокировки?
    1 июл 19, 11:57    [21918019]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Озверин
    Member

    Откуда: Ростов-на-Дону
    Сообщений: 5183
    Андрей Панфилов
    Озверин
    Можно почитать некоторые тесты:
    https://medium.com/@filia.aleks/microservice-performance-battle-spring-mvc-vs-webflux-80d39fd81bf0
    Написанное можно по разному читать. Для начала, ну вот есть там ограниченные ресурсы и возможность использовать async i/o, ну и используют. С другой стороны получается так: был прекрасный монолит с общением через память, заменили микросервисами с тормозным http, с апломбом что якобы монолит не масштабируется, как итог сторонний сервис умеет 4 тыщи запросов в секунду, а тормознутые микросервисы и до 2 тыщ не дотянули, зато масштабируется.


    читать можно как угодно, конечно. Но я эту фразу(точнее, потаеенный ее смысл) - совершенно не понял. Есть среды, где необходимо масштбаривание и где монолит не тянет. Если такие среды и задачи есть - к чему подобные комментарии?
    1 июл 19, 12:08    [21918030]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Андрей Панфилов
    Member

    Откуда: Москва > Melbourne
    Сообщений: 3247
    Озверин
    Но я эту фразу(точнее, потаеенный ее смысл) - совершенно не понял.
    Выглядит это все несколько притянутым за уши: у чувака без какой-либо пре/пост-обработки throughput в два раза упал в сравнении с оригинальным сервисом, скорее всего если добавить еще авторизацию, то наскребется на порядок. Получается что сначала мы сами придумываем себе проблемы, а потом героически их решаем, при всем при этом за "банкет" платит заказчик: вместо того чтобы разогнать дебилов и взять нормальный хостинг, приходится ютиться на t2.micro и оплачивать время идиотов.
    1 июл 19, 12:39    [21918057]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Озверин
    Member

    Откуда: Ростов-на-Дону
    Сообщений: 5183
    Андрей Панфилов
    Озверин
    Но я эту фразу(точнее, потаеенный ее смысл) - совершенно не понял.
    Выглядит это все несколько притянутым за уши: у чувака без какой-либо пре/пост-обработки throughput в два раза упал в сравнении с оригинальным сервисом, скорее всего если добавить еще авторизацию, то наскребется на порядок. Получается что сначала мы сами придумываем себе проблемы, а потом героически их решаем, при всем при этом за "банкет" платит заказчик: вместо того чтобы разогнать дебилов и взять нормальный хостинг, приходится ютиться на t2.micro и оплачивать время идиотов.


    ну других более гениальных тестов я не нашел, а от вас слышу только про идиотов, воду, бесполезность микросеврисов и уши ;)
    1 июл 19, 12:48    [21918064]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    Озверин,
    Статья интересная, но я согласен с Андрей Панфиловым что аргумент с микросервисами притянут за уши.
    Мы в сабже сравниваем сервлеты по классике и рактивное программирование библиотеку.
    Без юз кейса общения микросервисов и побочных от этого эффектов.
    1 июл 19, 12:58    [21918071]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    Озверин
    других более гениальных тестов
    за артистизм 5, за технику 3.
    Вот такая оценка статьи к данному сабжу.
    Можно пометить OFF/2.
    А то что нет статей, это ожидаемо.
    1 июл 19, 13:01    [21918074]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Озверин
    Member

    Откуда: Ростов-на-Дону
    Сообщений: 5183
    PetroNotC Sharp
    Озверин,
    Статья интересная, но я согласен с Андрей Панфиловым что аргумент с микросервисами притянут за уши.
    Мы в сабже сравниваем сервлеты по классике и рактивное программирование библиотеку.
    Без юз кейса общения микросервисов и побочных от этого эффектов.


    почему без? А если раскрывается все именно в микросервисах?
    1 июл 19, 13:05    [21918081]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    Озверин
    раскрывается все именно в микросервисах?
    ты первый про это сказал.
    Это меняет дело.
    То есть сабж рассматриваем только как борьба с недостатками микросервисов.
    ОК.
    1 июл 19, 13:08    [21918083]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

    Откуда:
    Сообщений: 1712
    Андрей Панфилов
    questioner
    Как-то звучит странно. Особо никто про стриминг не пишет в описании servlet 3.1

    Думается, что не идиоты это придумали и у них была мотивация делать то, что они сделали
    Не представляю как можно так тупить-то.... вот зачем вы приводите ссылки, цитаты и прочую ересь, если сами их не читаете?


    Честно читаю то, что привожу. Суть в том, что целостного представления у меня нет, поэтому и пишу тут. Если бы я на 100 процентов был уверен я бы и не спрашивал

    Андрей Панфилов
    questioner
    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.
    Вопрос: сколько можно в сокет написать без блокировки?

    Вот вообще не представляю даже. И вообще не понимаю этот механизм. Для меня NIO это некая выведенная унифицированная абстракция над улучшениями ОС, которая на Юниксе дать один прирост, а на Винде ничего не дать.
    1 июл 19, 13:34    [21918108]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

    Откуда:
    Сообщений: 1712
    PetroNotC Sharp
    Озверин,
    Мы в сабже сравниваем сервлеты по классике и рактивное программирование библиотеку.


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

    P.S. я конечно понимаю, что это русский форум, но всё таки
    1 июл 19, 13:42    [21918117]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Андрей Панфилов
    Member

    Откуда: Москва > Melbourne
    Сообщений: 3247
    Озверин
    от вас слышу только про идиотов, воду, бесполезность микросеврисов и уши ;)
    Ну а как иначе? Вот пишут:
    автор
    Option 1: Increase the thread pool size
    Yes, this is a good workaround, BUT only workaround!!! Because we cannot set this value to several thousand, because it’s is Docker with very limited memory. And each thread requires stack memory.
    У кота, по моим наблюдениям, http-поток отжирает где-то в районе аж 100Kb, т.е. на тысячу потоков будет аж целых 100Mb, а пишут что это много (на машине времени чтоли на 30 лет назад сгоняли?), я бы понял еще если бы написали что слишком много экзекьюшн юнитов и все начинает тупить (ну и там график бы еще с насыщением привели), а здесь какая-то левая отмазка про память. Если продолжать верить в то, что они таки в количестве памяти ограничены, то в реальности получается так: разница межу t2.micro и t2.medium в цене 15$ в месяц, при этом 1Gb против 4Gb, "исследование" по ссылке заняло наверное дня 4 и стоило заказчику косаря 2, вопрос: на сколько обули заказчика?
    1 июл 19, 13:44    [21918121]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Озверин
    Member

    Откуда: Ростов-на-Дону
    Сообщений: 5183
    Андрей Панфилов, я не понял: вы не отличаете stack memory от heap или не понимаеет, что у микросервисов есть своя ниша?
    1 июл 19, 13:55    [21918134]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Андрей Панфилов
    Member

    Откуда: Москва > Melbourne
    Сообщений: 3247
    questioner
    Андрей Панфилов
    пропущено...
    Вопрос: сколько можно в сокет написать без блокировки?

    Вот вообще не представляю даже. И вообще не понимаю этот механизм. Для меня NIO это некая выведенная унифицированная абстракция над улучшениями ОС, которая на Юниксе дать один прирост, а на Винде ничего не дать.
    Ну а чего не нагулили-то?
    man 2 send:

    When the message does not fit into the send buffer of the socket,
    send() normally blocks, unless the socket has been placed in
    nonblocking I/O mode. In nonblocking mode it would fail with the
    error EAGAIN or EWOULDBLOCK in this case. The select(2) call may be
    used to determine when it is possible to send more data.

    размер send buffer по-умолчанию в linux 122Kb, причем его еще можно увеличивать, теперь второй вопрос: с повальным увлечением REST в вебе, 122Kb - это большой размер для ответа или маленький?
    1 июл 19, 14:00    [21918137]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    questioner
    Кажется кому-то надо опохмелиться
    продолжаете плеваться и сморкаться?
    questioner
    Приведенная статья именно о теме топика. Микро, Макро сервисы....это вообще по барабану.

    Вам по барабану или профисообществу?
    1 июл 19, 14:01    [21918138]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    questioner,
    Ты ТС, и за это время просто обязан был сделать собственные тесты.
    1 июл 19, 14:06    [21918148]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    redwhite90
    Member

    Откуда:
    Сообщений: 1901
    Андрей Панфилов
    questioner
    пропущено...

    Вот вообще не представляю даже. И вообще не понимаю этот механизм. Для меня NIO это некая выведенная унифицированная абстракция над улучшениями ОС, которая на Юниксе дать один прирост, а на Винде ничего не дать.
    Ну а чего не нагулили-то?
    man 2 send:

    When the message does not fit into the send buffer of the socket,
    send() normally blocks, unless the socket has been placed in
    nonblocking I/O mode. In nonblocking mode it would fail with the
    error EAGAIN or EWOULDBLOCK in this case. The select(2) call may be
    used to determine when it is possible to send more data.

    размер send buffer по-умолчанию в linux 122Kb, причем его еще можно увеличивать, теперь второй вопрос: с повальным увлечением REST в вебе, 122Kb - это большой размер для ответа или маленький?


    Процентное соотношение мне не известно, но с уверенностью можно сказать, что не редки случаи когда ответ превышает 122 кб
    1 июл 19, 14:22    [21918170]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    redwhite90
    Member

    Откуда:
    Сообщений: 1901
    Озверин
    PetroNotC Sharp
    Озверин,
    Статья интересная, но я согласен с Андрей Панфиловым что аргумент с микросервисами притянут за уши.
    Мы в сабже сравниваем сервлеты по классике и рактивное программирование библиотеку.
    Без юз кейса общения микросервисов и побочных от этого эффектов.


    почему без? А если раскрывается все именно в микросервисах?


    На этом месте мог быть сервис с котировками на бирже, который никогда не был и быть не мог частью монолита
    1 июл 19, 14:26    [21918174]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Андрей Панфилов
    Member

    Откуда: Москва > Melbourne
    Сообщений: 3247
    Озверин
    я не понял: вы не отличаете stack memory от heap?
    Насколько я помню это у вас в прошлый раз возникали проблемы с размером стэка, вот из интернетов: 10 тысяч потоков на 2Gb кучи, чес про память из статьи, что вы привели, несостоятелен.

    Озверин
    или не понимаеет, что у микросервисов есть своя ниша
    Пока понимание такое, что ниша микросервисов - обуть лохов.
    1 июл 19, 14:29    [21918178]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Андрей Панфилов
    Member

    Откуда: Москва > Melbourne
    Сообщений: 3247
    redwhite90
    Процентное соотношение мне не известно, но с уверенностью можно сказать, что не редки случаи когда ответ превышает 122 кб
    больше 122Kb - это видосики чтоли? на странице A4 где-то 3000 печатных знаков, ну с пробелами пусть будет 4000, ладно, форум русскоязычный, пусть A4 - будет 8Kb, т.е. чтобы в попасть в блокировку на send() нужно отправить >15 страниц текста (и при этом ничего в ОС не крутить!)... вы точно адекватно оцениваете объемы передаваемой информации? или в JSON html пихаете?
    1 июл 19, 14:39    [21918190]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    Андрей Панфилов
    Пока понимание такое, что ниша микросервисов - обуть лохов.
    кто сказал что профи обязан дипломатично выражаться)))
    1 июл 19, 14:53    [21918218]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Андрей Панфилов
    Member

    Откуда: Москва > Melbourne
    Сообщений: 3247
    Андрей Панфилов
    чес про память из статьи, что вы привели, несостоятелен.
    Дальше, смотрим на картинку где сравнивается throughput разных подходов:
  • "классика" - 831
  • async - 1313
  • WebFlux - 1469

    замечаем, что цифры от WebFlux не особо-то и хорошо смотрятся на фоне servlet api 3.0 , теперь смотрим код:

        @GetMapping(value = "/sync")
        public String getUserSync(@RequestParam long delay) {
            return sendRequestWithJavaHttpClient(delay).thenApply(x -> "sync: " + x).join();
        }
    
        private CompletableFuture<String> sendRequestWithApacheHttpClient(long delay) {
            CompletableFuture<org.apache.http.HttpResponse> cf = new CompletableFuture<>();
            FutureCallback<org.apache.http.HttpResponse> callback = new HttpResponseCallback(cf);
            HttpUriRequest request = new HttpGet(userServiceHost+"/user/?delay="+delay);
            apacheClient.execute(request, callback);
            return cf.thenApply(response -> {
                try {
                    return EntityUtils.toString(response.getEntity());
                } catch (ParseException | IOException e) {
                    return e.toString();
                }
            }).exceptionally(Throwable::toString);
        }
    


    я правильно понял, что автор статьи в случае "синхронного" выполнения утилизирует 2 потока одновременно: один с CompletableFuture, второй с join, а потом говорит потоков как-то много и памяти не хватает?
  • 1 июл 19, 15:10    [21918244]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Озверин
    Member

    Откуда: Ростов-на-Дону
    Сообщений: 5183
    Андрей Панфилов
    Озверин
    я не понял: вы не отличаете stack memory от heap?
    Насколько я помню это у вас в прошлый раз возникали проблемы с размером стэка, вот из интернетов: 10 тысяч потоков на 2Gb кучи, чес про память из статьи, что вы привели, несостоятелен.

    Озверин
    или не понимаеет, что у микросервисов есть своя ниша
    Пока понимание такое, что ниша микросервисов - обуть лохов.


    netflix горько плачет
    1 июл 19, 15:13    [21918248]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

    Откуда:
    Сообщений: 1712
    Андрей Панфилов
    questioner
    пропущено...

    Вот вообще не представляю даже. И вообще не понимаю этот механизм. Для меня NIO это некая выведенная унифицированная абстракция над улучшениями ОС, которая на Юниксе дать один прирост, а на Винде ничего не дать.
    Ну а чего не нагулили-то?
    man 2 send:

    When the message does not fit into the send buffer of the socket,
    send() normally blocks, unless the socket has been placed in
    nonblocking I/O mode. In nonblocking mode it would fail with the
    error EAGAIN or EWOULDBLOCK in this case. The select(2) call may be
    used to determine when it is possible to send more data.

    размер send buffer по-умолчанию в linux 122Kb, причем его еще можно увеличивать, теперь второй вопрос: с повальным увлечением REST в вебе, 122Kb - это большой размер для ответа или маленький?


    Тут я что-то новое узнал))

    Правильно я понимаю, что вся история с NIO(1 или 2 кстати?) в том, что мы можем записать/прочитать некоторое количество данных(122 кб для linux) не блокируясь, а если больше, то блокируемся?

    То бишь хотим мы зааплоадить видос на пару гигабайтов через NIO и это будет выглядеть примерно так:

    У нас есть колбеки, которые вызывает ОС, говорящие о том, что "ОС готова записать в сокет 122кб". Причём на это не тратится даже CPU как я понял. Ок, мы записали эти 122 кб и пока следующий раз колбек не вызывется, то приложение ресурсы не тратит на запись и может тратить ресурсы.

    похоже на правду?
    1 июл 19, 15:17    [21918253]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Андрей Панфилов
    Member

    Откуда: Москва > Melbourne
    Сообщений: 3247
    Озверин
    netflix горько плачет
    у них же бизнес видосики стримить, не?
    1 июл 19, 15:18    [21918256]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Озверин
    Member

    Откуда: Ростов-на-Дону
    Сообщений: 5183
    Андрей Панфилов
    Озверин
    netflix горько плачет
    у них же бизнес видосики стримить, не?


    в том числе. Только микросервисы там выполняют совершенно разные ф-ии..идиоты, думаю.
    1 июл 19, 15:21    [21918262]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Андрей Панфилов
    Member

    Откуда: Москва > Melbourne
    Сообщений: 3247
    Озверин
    Только микросервисы там выполняют совершенно разные ф-ии..идиоты, думаю.
    ну а как еще? сидит там отдел разработки и думает: как бы вытянуть из бизнеса еще денег! о! нужно сказать что все что мы до этого делали чуть собачья и нужно все переписать заново. Мы вон в 2005 киношки стримили с посредственного сервера и спокойно забивали 4 гигабита, и никаких микросервисов не было, только perl и nginx.
    1 июл 19, 15:40    [21918274]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Озверин
    Member

    Откуда: Ростов-на-Дону
    Сообщений: 5183
    Андрей Панфилов
    Озверин
    Только микросервисы там выполняют совершенно разные ф-ии..идиоты, думаю.
    ну а как еще? сидит там отдел разработки и думает: как бы вытянуть из бизнеса еще денег! о! нужно сказать что все что мы до этого делали чуть собачья и нужно все переписать заново. Мы вон в 2005 киношки стримили с посредственного сервера и спокойно забивали 4 гигабита, и никаких микросервисов не было, только perl и nginx.


    мне нравится. Согласен. ТыТруба вон же как-то жила раньше - и все ок было.

    p.s. Представил 2005й в текущих разрешениях, про 4k говорить даже не буду - вдруг скажут, что это от сатаны!!!
    1 июл 19, 15:48    [21918282]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    Любыю тему в микросервисы переведут)
    1 июл 19, 15:49    [21918287]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Озверин
    Member

    Откуда: Ростов-на-Дону
    Сообщений: 5183
    PetroNotC Sharp
    Любыю тему в микросервисы переведут)


    в любую тему ворвутся люди, которые скажут - что микросервисы никому не нужны. Это странно, потому что вопрос ведь касается совершенно других тем, например - производительности околоструктурных решений, которые идеально раскрываются в микросервисах.
    1 июл 19, 15:51    [21918290]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

    Откуда:
    Сообщений: 1712
    Озверин
    PetroNotC Sharp
    Любыю тему в микросервисы переведут)


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



    Этим же персонажам нечего по теме сказать, зато пофлудить ой как хочется. Вот только вопрос на кой им это надо.
    1 июл 19, 16:08    [21918306]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Андрей Панфилов
    Member

    Откуда: Москва > Melbourne
    Сообщений: 3247
    questioner
    похоже на правду?
    Нет. за tcp/ip полностью отвечает ядро, если со стороны используются вызовы send/recv ("классика"), то концепция такая:
    - send блокируется только тогда, когда приложение хочет отправить данных больше, чем можно записать в send buffer (ядро читает оттуда и отправляет в сеть, т.е. в определенные моменты там могут находиться еще неотправленные данные, или данные, на которые не получено подтверждение)
    - recv блокируется только тогда приложение хочет прочесть данных больше чем сейчас есть в receive buffer (ядро получает данные из сети и складывает их туда), кроме этого через recv еще приходят ошибки таймаута от send (т.е. send для приложения асинхронный, однако о том что данные не доставлены нужно приложению сообщать, вот ядро сообщает в recv)

    и в случае "классики" основная беда в recv, потому что он блокирующий в большинстве случаев и в больших send, поэтому чтобы одновременно обрабатывать много соединений нужно много потоков (условно поток на соединение). В случае же асинхронного I/O много потоков не нужно, потому что там сценарий работы отличается: мы открываем сокетов столько сколько захотим, а у ядра ОС спрашиваем расклад по нашим сокетам, т.е. ответ будет:
    - сюда можно писать
    - отсюда можно читать
    - здесь ошибка

    по факту в примере из https://medium.com/@filia.aleks/microservice-performance-battle-spring-mvc-vs-webflux-80d39fd81bf0 написана какая-то дичь: там на 800 клиентов получается 60 потоков в пике, что для прокси несколько странно, например если сравнивать с "референсной реализацией" прокси-сервера, то там пишут так:
    nginx
    NGINX can run multiple worker processes, each capable of processing a large number of simultaneous connections. You can control the number of worker processes and how they handle connections with the following directives:

    - worker_processes – The number of NGINX worker processes (the default is 1). In most cases, running one worker process per CPU core works well, and we recommend setting this directive to auto to achieve that. There are times when you may want to increase this number, such as when the worker processes have to do a lot of disk I/O.
    - worker_connections – The maximum number of connections that each worker process can handle simultaneously. The default is 512, but most systems have enough resources to support a larger number. The appropriate setting depends on the size of the server and the nature of the traffic, and can be discovered through testing.

    т.е. с конфигурацией по-умолчанию, достаточной чтобы запускаться на каком-то хламе, Сысоев преполагает что один экзекьюшн юнит способен проксировать 512 соединений, если сравнивать с "результатами" полученным для WebFlux видно, что в консерватории что-то не так.
    1 июл 19, 16:08    [21918307]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Андрей Панфилов
    Member

    Откуда: Москва > Melbourne
    Сообщений: 3247
    Озверин
    p.s. Представил 2005й в текущих разрешениях, про 4k говорить даже не буду - вдруг скажут, что это от сатаны!!!
    нормально там все было с разрешением, а блюрей вроде как в 2006 появился.

    PS. ваш netflix бомжи какие-то, вот:

    https://muchneeded.com/netflix-statistics/
    Netflix users spend 1 billion hours watching movies weekly
    т.е. в год 53 миллиарда часов, если думать что видосик полтора часа занимает, то всего-лишь 35 миллиардов видосиков в год (при этом его еще куча провайдеров форсят включая в свои тарифные планы), а вот реальный король стриминга:

    https://www.pornhub.com/press
    Pornhub is one of the most prolific adult websites, averaging over 100 billion video views a year. That's about 12.5 porn videos per person on earth.
    - Over 100 million daily visits to Pornhub, and over 36 billion visits per year.
    - Over 125 million daily visits to the Pornhub Network of sites including YouPorn and Redtube.
    - 20 million registered Pornhub users.
    - Average streaming bandwidth of 120 Gigabytes per second.

    какая инфраструктура у порнхаба? тоже микросервисы?
    1 июл 19, 16:23    [21918322]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Озверин
    Member

    Откуда: Ростов-на-Дону
    Сообщений: 5183
    Андрей Панфилов, даже если не брать в расчет тот факт, что ты несешь какой бред , измеря трафик в кол-ве видосиков, почему ты не взял среднее время видосика на порнхабе, чтобы быть до конца логичным?;)
    1 июл 19, 16:42    [21918340]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    questioner
    Озверин
    пропущено...


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



    Этим же персонажам нечего по теме сказать, зато пофлудить ой как хочется. Вот только вопрос на кой им это надо.
    то есть ты пишешь прокси сервис, который обращается к внешнему чужому сервису и который жутко тормозит.
    Так?
    Или ты ничего не пишешь а только бла бла?
    1 июл 19, 16:44    [21918342]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    Озверин,
    Я сожалею что вы не нашли других примеров и юзкейсов.
    Туда Flux'y и дорога....для поддержки штанов микросервисов.
    1 июл 19, 16:48    [21918344]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Андрей Панфилов
    Member

    Откуда: Москва > Melbourne
    Сообщений: 3247
    Озверин
    даже если не брать в расчет тот факт, что ты несешь какой бред , измеря трафик в кол-ве видосиков, почему ты не взял среднее время видосика на порнхабе, чтобы быть до конца логичным?;)
    Пока с вашей стороны был только один унылый пример превосходства WebFlux, да и тот кривой. Смысла сравнивать продолжительность видосика нет: запрос от клиента обработали, дальше ядро через DMA/sendfile гонит его в сеть или вы полагаете что видосики в базе в виде блобов лежат? Вот примеры:
    - https://www.nginx.com/resources/wiki/start/topics/examples/xsendfile/
    - https://tomcat.apache.org/tomcat-9.0-doc/aio.html
    1 июл 19, 16:49    [21918345]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Озверин
    Member

    Откуда: Ростов-на-Дону
    Сообщений: 5183
    Андрей Панфилов
    Озверин
    даже если не брать в расчет тот факт, что ты несешь какой бред , измеря трафик в кол-ве видосиков, почему ты не взял среднее время видосика на порнхабе, чтобы быть до конца логичным?;)
    Пока с вашей стороны был только один унылый пример превосходства WebFlux, да и тот кривой. Смысла сравнивать продолжительность видосика нет: запрос от клиента обработали, дальше ядро через DMA/sendfile гонит его в сеть или вы полагаете что видосики в базе в виде блобов лежат? Вот примеры:
    - https://www.nginx.com/resources/wiki/start/topics/examples/xsendfile/
    - https://tomcat.apache.org/tomcat-9.0-doc/aio.html


    с моей стороны вообще не было заявок на победу, я скзаал - что тут есть тесты. А ты несешь дикий бред про то, что вебсиры никому не упали и про пропускную способность в видосиках )))
    1 июл 19, 16:50    [21918346]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Озверин
    Member

    Откуда: Ростов-на-Дону
    Сообщений: 5183
    *вебсиры - микросервисы.
    1 июл 19, 16:50    [21918347]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Озверин
    Member

    Откуда: Ростов-на-Дону
    Сообщений: 5183
    PetroNotC Sharp
    Озверин,
    Я сожалею что вы не нашли других примеров и юзкейсов.
    Туда Flux'y и дорога....для поддержки штанов микросервисов.


    мне, если честно, глубоко фиолетово, кто тут и о чем сожалеет.
    1 июл 19, 16:51    [21918349]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    Озверин
    я скзаал - что тут есть тесты
    комментами не сопроводил)))))
    1 июл 19, 16:55    [21918356]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    Озверин,
    Будем ждать других тестов). Занавес.
    1 июл 19, 16:56    [21918358]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Озверин
    Member

    Откуда: Ростов-на-Дону
    Сообщений: 5183
    PetroNotC Sharp
    Озверин
    я скзаал - что тут есть тесты
    комментами не сопроводил)))))


    ну когда 3 страницы разговоров без цифр - надо ж конструктива подкинуть ... а то тут видсиками трафик измеряют...я хз - совсем лето влияет.
    1 июл 19, 16:57    [21918360]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Озверин
    Member

    Откуда: Ростов-на-Дону
    Сообщений: 5183
    PetroNotC Sharp
    Озверин,
    Будем ждать других тестов). Занавес.


    вперед.
    1 июл 19, 16:57    [21918361]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

    Откуда:
    Сообщений: 1712
    Озверин
    PetroNotC Sharp
    пропущено...
    комментами не сопроводил)))))


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


    Некоторым конструктив вообще не нужен. Достаточно просто писать что-то бессвязное.
    1 июл 19, 17:00    [21918364]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    questioner,
    Это тебе ниже
    Озверин
    ну когда 3 страницы разговоров без цифр
    1 июл 19, 17:03    [21918368]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Андрей Панфилов
    Member

    Откуда: Москва > Melbourne
    Сообщений: 3247
    Озверин
    с моей стороны вообще не было заявок на победу, я скзаал - что тут есть тесты. А ты несешь дикий бред про то, что вебсиры никому не упали и про пропускную способность в видосиках )))
    Крутость микросевисов в нетфликсах начали измерять вы, на что получили разумное возражение, что объемы нетфликса хоть и внушительные, но не прямо TOP1. Какой-то странный у вас стиль общения: подпустить дешевого понта, что микросервисы - круто, сказать что оппонент пишет чушь и быстро слиться. Прямо пыонеры от разработки: сначала делаем еле-шевелящегося крокодила, создаем кучу проблем, а потом с гордостью их решаем (вот зачем в одном сервисе проксировать другой, а не сразу клиенту эндпойнт выставлять? давайте угадаю: авторизация-то у нас офигеть какая дорогая, и нужно ее в одном месте делать, а в эндойнты ходить уже с чем-то более лайтовым - не кажется что на пустом месте проблема возникает?). Какой следующий шаг будет в строительстве микросервисов? DMA-over-HTTP?
    1 июл 19, 17:13    [21918383]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    Озверин,
    Пусть ТС отдувается. Зачем это тебе?)
    1 июл 19, 17:31    [21918400]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

    Откуда:
    Сообщений: 1712
    Андрей Панфилов
    и в случае "классики" основная беда в recv, потому что он блокирующий в большинстве случаев и в больших send, поэтому чтобы одновременно обрабатывать много соединений нужно много потоков (условно поток на соединение). В случае же асинхронного I/O много потоков не нужно, потому что там сценарий работы отличается: мы открываем сокетов столько сколько захотим, а у ядра ОС спрашиваем расклад по нашим сокетам, т.е. ответ будет:
    - сюда можно писать
    - отсюда можно читать
    - здесь ошибка


    А это мы должны сами опрашивать или всё это скрыто от нас ?
    1 июл 19, 18:30    [21918441]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Андрей Панфилов
    Member

    Откуда: Москва > Melbourne
    Сообщений: 3247
    questioner
    А это мы должны сами опрашивать или всё это скрыто от нас ?
    В C руками, пример: https://gist.github.com/josephg/6c078a241b0e9e538ac04ef28be6e787

    в жаве по факту то же самое написано в sun.nio.ch.KQueuePort.EventHandlerTask#poll а разработчику отдали java.nio.channels.AsynchronousByteChannel
    1 июл 19, 19:24    [21918473]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Basil A. Sidorov
    Member

    Откуда:
    Сообщений: 9178
    questioner
    А это мы должны сами опрашивать или всё это скрыто от нас ?
    От реализации зависит.
    В "классическом" варианте делается select на наборе сокетов и "по тайм-ауту" или "по результату" возвращается или "тайм-аут" или счётчики сокетов, доступных для операций ввода, вывода или "с ошибками". Какие конкретно - надо "бегать" по набору и смотреть.
    Про устройство более современных и более продвинутых вариантов я не особо в курсе. Вроде, на обратные вызовы (calback) переходят и вообще - всячески минимизируют опросы.
    1 июл 19, 19:30    [21918476]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

    Откуда:
    Сообщений: 1712
    Вот кстати есть пример:
    https://github.com/violetagg/s1p2017-demo
    и его видео представление:
    [youtube=]
    2 июл 19, 09:57    [21918734]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    questioner,
    Умеешь ты экзотику находить с одним коммитом в год.
    2 июл 19, 12:02    [21918876]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

    Откуда:
    Сообщений: 1712
    PetroNotC Sharp
    questioner,
    Умеешь ты экзотику находить с одним коммитом в год.


    Зачем умственно отсталому смотреть видео, можно просто пофлудить
    2 июл 19, 13:17    [21918958]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    questioner,
    Прекращай задавать вопросы по архитектуре, которые не относятся к твоей работе или без кода.
    Тут ветка программистов а не теоретиков. Можешь плеваться и ругаться сколько влезет.
    2 июл 19, 13:51    [21919008]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

    Откуда:
    Сообщений: 1712
    PetroNotC Sharp,

    правильно, тебе тут не место. Шёл бы ты отсюда, пет****
    2 июл 19, 13:57    [21919011]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    questioner,
    21918342
    2 июл 19, 14:04    [21919021]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

    Откуда:
    Сообщений: 1712
    PetroNotC Sharp,

    Просто угомонись, засоряешь тему своими высерами. твоё мнение тут никому неинтересно
    2 июл 19, 14:07    [21919023]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    questioner,
    Твои проблемы. Ты ТС? Значит будешь арбайтен и тесты строить.
    А не чужие видосики постить.
    2 июл 19, 14:10    [21919029]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    questioner,
    Аргументов нет? Закрывай тему.
    2 июл 19, 14:11    [21919031]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

    Откуда:
    Сообщений: 1712
    PetroNotC Sharp,

    читай пока осознание не придёт

    Хотя до тебя не дойдёт, ты неизлечим
    2 июл 19, 14:20    [21919040]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    questioner,
    Скучный ты.
    Ждем другую твою тему без кода.
    Удачи!
    2 июл 19, 14:26    [21919049]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

    Откуда:
    Сообщений: 1712
    PetroNotC Sharp
    questioner,
    Скучный ты.
    Ждем другую твою тему без кода.
    Удачи!


    Пойми одну простую вещь - если тебе не нравится моя тема ты можешь просто в неё не писать. Те, кто может ответить - ответят. Потом те, кто будут гуглить смогут почерпнуть для себя что-то. А ты просто в каждой бочке затычка.
    2 июл 19, 14:46    [21919073]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    questioner
    PetroNotC Sharp
    questioner,
    Скучный ты.
    Ждем другую твою тему без кода.
    Удачи!


    Пойми одну простую вещь - если тебе не нравится моя тема ты можешь просто в неё не писать. Те, кто может ответить - ответят. Потом те, кто будут гуглить смогут почерпнуть для себя что-то. А ты просто в каждой бочке затычка.
    тебе 16 лет?
    Нужно объяснять, что вопрос надо задавать возле компа и с кодом?
    Абстрактно про технологии ты говорить не умеешь.
    2 июл 19, 14:55    [21919082]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    questioner,
    Вот здесь почему кода нет?
    И так ты пол года вопросы задаешь.
    Я последние 2 темы не вытерпел)
    Dependency inversion
    2 июл 19, 14:58    [21919086]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

    Откуда:
    Сообщений: 1712
    PetroNotC Sharp,

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

    Если хочешь больше кода - пиши что-то конструктивное с кодом, я только за, но от тебя конструктива ноль, только нытьё какое-то и поддакиванье.
    2 июл 19, 15:48    [21919144]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    questioner
    пиши что-то конструктивное с кодом
    зайди в мой профиль. Так и делаю когда вопрос задаю.
    И веду себя очень тихо))).
    Эх, всё тебе объяснять надо).
    Код давай! Развел сопли.
    2 июл 19, 16:04    [21919164]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

    Откуда:
    Сообщений: 1712
    PetroNotC Sharp
    questioner
    пиши что-то конструктивное с кодом
    зайди в мой профиль. Так и делаю когда вопрос задаю.
    И веду себя очень тихо))).
    Эх, всё тебе объяснять надо).
    Код давай! Развел сопли.


    Разница в том, что мне твои темы не интересны и заходить я туда не буду, а ты докопался как пьяный до радио со своими советами на которые мне абсолютно плевать. Избавь меня от своего внимания
    2 июл 19, 16:46    [21919217]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    questioner
    Избавь меня от своего внимания
    100 баксов. Либо кодом меня, кодом))
    2 июл 19, 16:59    [21919235]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    redwhite90
    Member

    Откуда:
    Сообщений: 1901
    PetroNotC Sharp
    questioner
    Избавь меня от своего внимания
    100 баксов. Либо кодом меня, кодом))


    Ты столько не стоишь
    3 июл 19, 01:14    [21919534]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Озверин
    Member

    Откуда: Ростов-на-Дону
    Сообщений: 5183
    Андрей Панфилов
    Озверин
    с моей стороны вообще не было заявок на победу, я скзаал - что тут есть тесты. А ты несешь дикий бред про то, что вебсиры никому не упали и про пропускную способность в видосиках )))
    Крутость микросевисов в нетфликсах начали измерять вы, на что получили разумное возражение, что объемы нетфликса хоть и внушительные, но не прямо TOP1. Какой-то странный у вас стиль общения: подпустить дешевого понта, что микросервисы - круто, сказать что оппонент пишет чушь и быстро слиться. Прямо пыонеры от разработки: сначала делаем еле-шевелящегося крокодила, создаем кучу проблем, а потом с гордостью их решаем (вот зачем в одном сервисе проксировать другой, а не сразу клиенту эндпойнт выставлять? давайте угадаю: авторизация-то у нас офигеть какая дорогая, и нужно ее в одном месте делать, а в эндойнты ходить уже с чем-то более лайтовым - не кажется что на пустом месте проблема возникает?). Какой следующий шаг будет в строительстве микросервисов? DMA-over-HTTP?



    я хотел обнаружить вдруг, где я говорил, что микросервисы настолько круты, что прямо везде необходимы. Есть подозрение, что я сказал, что у микросервисов есть своя ниша. Тогда ты просто говоришь , что фуфло для лохов, не так ли? И это у меня странная манера общения?

    Нетфликс предоставляет услугу более 100млн пользователей - это стриминговое телевидение ультравысокого качества в том числе. По трафику с такими требованиями(стриминг высокого качестве как замена телевидения) с ним может соперничать разве что тытруба.

    Замечу, что это ТЫ Нетфликс называешь идиотами и лохами, а манера общения все еще тупая у меня?

    Форум давно приобрел схожесть с политическими помойками, потому что уровень компетенций и выдержанности людей напоминает именно помойку.
    3 июл 19, 11:18    [21919667]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    Озверин
    я хотел обнаружить вдруг, где я говорил, что микросервисы настолько круты, что прямо везде необходимы. Есть подозрение, что я сказал, что у микросервисов есть своя ниша. Тогда ты просто говоришь , что фуфло для лохов, не так ли? И это у меня странная манера общения?

    Ты первый ввел в тему микросервисы. И что обижаться?
    То что во всем инете это buzzword?
    OK. Я готов принять, что webFlux пишут с микросервисами. ПИШИТЕ.
    3 июл 19, 11:43    [21919690]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    Озверин
    Форум давно приобрел

    А) почему то другого такого нет
    Б) ты не был в ветке шарп))). Там аргументы типа: "Фаулер придурок...
    Так что не оффтопь.
    3 июл 19, 11:46    [21919696]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Андрей Панфилов
    Member

    Откуда: Москва > Melbourne
    Сообщений: 3247
    Озверин
    я хотел обнаружить вдруг, где я говорил, что микросервисы настолько круты, что прямо везде необходимы. Есть подозрение, что я сказал, что у микросервисов есть своя ниша. Тогда ты просто говоришь , что фуфло для лохов, не так ли? И это у меня странная манера общения?
    Ну вот опять, то не говорил, этого не писал и пр. 21918030:
    Озверин
    Есть среды, где необходимо масштбаривание и где монолит не тянет. Если такие среды и задачи есть - к чему подобные комментарии?

    Масштабируемость в микросервисах - это то на что пытаются поймать лохов: сначала мы впариваем всем что в микросервисах какая-то необычайная масштабируемость и всем срочно их нужно использовать, а потом, спустя некоторое время говорим, что все что рассказывали ранее - все неправда, и теперь нужно срочно использовать WebFlux, потому что раньше масштабируемость была ненастоящая, а теперь будет настоящая.
    Озверин
    Нетфликс предоставляет услугу более 100млн пользователей - это стриминговое телевидение ультравысокого качества в том числе. По трафику с такими требованиями(стриминг высокого качестве как замена телевидения) с ним может соперничать разве что тытруба.
    Еще раз, для специально одаренных: прикладное ПО в генерации трафика не участвует - все делает ядро через DMA/sendfile, если у кого-то видосики раздаются не ядром ОС, то он явно что-то делает не так.
    Озверин
    Замечу, что это ТЫ Нетфликс называешь идиотами и лохами, а манера общения все еще тупая у меня?
    А это разве не netflix изначально написали хрень, растрындели всем про масштабируемость, а потом все переделали на то как нужно? Netflix Zuul Gets a Makeover to a Asynchronous and Non-Blocking Architecture


    Озверин
    Форум давно приобрел схожесть с политическими помойками, потому что уровень компетенций и выдержанности людей напоминает именно помойку.
    Я вот тоже не понимаю зачем приходить в каждый топик и нудеть про микросервисы.
    4 июл 19, 09:18    [21920465]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    questioner
    Member

    Откуда:
    Сообщений: 1712
    Андрей Панфилов
    Масштабируемость в микросервисах - это то на что пытаются поймать лохов: сначала мы впариваем всем что в микросервисах какая-то необычайная масштабируемость и всем срочно их нужно использовать, а потом, спустя некоторое время говорим, что все что рассказывали ранее - все неправда, и теперь нужно срочно использовать WebFlux, потому что раньше масштабируемость была ненастоящая, а теперь будет настоящая.


    У WebFlux применение только для криворуких программистов использующих ужасные микросервисы, которые были выбраны по ошибке, чтобы хоть как-то улучшить производительность?

    Я всё правильно понял?
    4 июл 19, 13:00    [21920691]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    questioner,
    "Как же тебя понять, если ты ничего не говоришь"? (с) Иван Васильевич.
    Применительно к твоему вопросу, глянь соседний топик где чел пишет и спрашивает одновременно.
    Если бы ты сделал пример WebFlux руками, то и вопрос бы твой давно отпал. Что делал неделю?
    ...
    WebFlux годится для проектов ИЗНАЧАЛЬНО с реактивной парадигмой (вики)
    4 июл 19, 13:23    [21920714]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    PetroNotC Sharp
    Member

    Откуда:
    Сообщений: 552
    questioner,
    Ну и
    автор
    Чем асинхронные сервлеты отличаются от Sping WebFlux

    доказывать что классика Хуже webFlux лежит на авторе топика или альтруистах. Что справедливо.
    Так получается что у тебя корысть в продвижении этой технологии)))
    4 июл 19, 13:32    [21920722]     Ответить | Цитировать Сообщить модератору
     Re: Чем асинхронные сервлеты отличаются от Sping WebFlux  [new]
    Андрей Панфилов
    Member

    Откуда: Москва > Melbourne
    Сообщений: 3247
    questioner
    У WebFlux применение только для криворуких программистов использующих ужасные микросервисы, которые были выбраны по ошибке, чтобы хоть как-то улучшить производительность?

    Я всё правильно понял?
    Вам для начала нужно понять откуда у асинхронного выполнения вообще ноги растут. А растут они из жава-скрипта: в браузере движок JS устроен таким образом, что есть один поток для UI и воркеры для всего остального, поэтому разработчикам JS просто необходимо исполнение всего что можно запихивать в воркеры, в противном случае у пользователя начинает тупить UI. Для всего этого там придумывают разного рода API, чтобы конечному разработчику было проще, однако путь устаканивания всего этого API не быстрый, в итоге в JS сейчас существует куча разных способов делать одно и то же: Async/await, Coroutines, Promises, Callbacks, может еще что забыл. WebFlux - это попытка принести то что сейчас есть в JS в мир Java (видимо, потому что одним только Future<?> пользоваться довольно уныло), однако реальных кейсов для использования не особо-то и много (ну вот нет у нас браузера, у которого существует ряд ограничений).
    4 июл 19, 13:55    [21920743]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: 1 2 3 4 5 6      [все]
    Все форумы / Java Ответить