Spring Webflux - Почему он такой быстрый?

Разбираемся почему WebClient от SpringWebflux работает в 20 раз быстрее обычного http-клиента.

[@KonstantDev]

Спасибо за понятное объяснение!

[@pulato000]

Extremely interesting! Plz countinue

[@VadimBryksin]

Странно, только что закончил перф-тест последнего (3.0.3) Spring Boot MVC vs Spring Boot WebFlux - и как-то результаты совсем не порадовали... вот что получилось Throughput/s: Non-DB Calls (Actuator helath/info) MVC: 310.17 WebFlux: 225.94 With DB Calls (create / get) MVC: 115.51 WebFlux (+R2DBC): 33.50 получилось что WebFlux аж в 4 раза медленнее чем MVC, я ожидал все на оборот

[@СтасРусаков-т2э]

Тоже никак не могу получить эту обещанную производительность( Ни db, ни походы на api. Ничего не выигрывает у MVC. Уже устал искать где я ошибаюсь. Методы максимально коробочные - без какой либо моей логики. Чисто вызов webClient/Repository

[@nyrhog3740]

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

[@alexshpaq]

Это же основа асинхронного выполнения - асинхронное выполнение всегда медленнее обычного синхронного, потому операция переключения потоков далеко не бесплатная, плюс создание объектов Mono и Flux тоже не бесплатные. Но в асинхронном выполнении минимизируется время простоя потоков, то есть если потоку требуется прождать где-то секунду или несколько, например дождаться ответа от другого сервера, то в синхронном программировании поток будет просто ждать, а в асинхронном поток не ждёт, и может заняться обработкой других вещей - например параллельно отправить другой запрос, или что-то подсчитать. Это очень полезно, потому что практически везде используются пулы потоков с ограниченным количеством потоков, и многие не знают, как увеличить тот или иной пул потоков, плюс вообще то каждый поток по умолчанию тратит 1МБ памяти под стек и приложение с 1000 потоков будет потреблять 1ГБ памяти только для потоков

[@milordplus]

Крутой пример, крутое объяснение! Спасибо!!!

[@АлександрБугримов-о1е]

Спасибо за видео! Вообще супер )

[@Akio_F]

Ёмкая наглядная демонстрация, спасибо!

[@alexandersmirnov4274]

супер можете еще снять видео с разбором оператора groupby

[@ram0973]

А время отклика от 1 запроса в спринге с webflux при малой нагрузке быстрее? Чем в обычном спринге?

[@Bomber765]

Разницы нет. За время отклика отвечает сервер, т.к. он отдает веб-страницу. И делает он это всегда одинаково, независимо от того, кто у него запрашивают страницу - webflux или обычный httpClient. Если нагрузка маленькая то лучше использовать httpClient, т.к. код будет проще как для написания так и для отладки

[@iKorvik]

Ммм, чел сравнил многопоточность с однопоточностью и решил, что это заслуги вебфлакса. А прикол реактивного программирования вообще не в этом. То, что ты сделал, это обычная многопоточность.

[@Bomber765]

Нет, ты ошибаешься. В данном примере будет использован 1 main поток + io потоки netty (их число равно числу ядер). Итого, на 8-ядерной машине одновременное скачивание 256 страниц будет обеспечено 9 потоками. Это не многопоточка. Попробуй в 9 потоков скачать с помощью синхронного http-клиента 1000 страниц, и посмотри сколько у тебя уйдет времени. Гарантирую что удивишься.

[@flamencoag]

Но ведь действительно эта асинхронность достигается через выполнение задачи в отдельном потоке. А поскольку вы запускаете много таких задач, то и получается многопоточность. Вообще я почти уверен, что если сделать загрузки через многопоточность, используя обычный http клиент, то результат будет как на webflux

[@Bomber765]

@@flamencoag​​⁠​⁠​⁠ это сравнение я делаю в начале видео. Можете пересмотреть и увидеть разницу в скорости 3:51

[@МаксимСеменченко-ы9ъ]

@@flamencoag Так тут нет многопоточности. Тут ассинхронность. Мы просто избегаем блокировки при выполнении. Ты при многопоточности такого не добьешься, один поток это примерно 1мб, 256 потоков, удачи.

[@xandrviking1113]

Супер 👍