Странно, только что закончил перф-тест последнего (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, я ожидал все на оборот
Тоже никак не могу получить эту обещанную производительность( Ни db, ни походы на api. Ничего не выигрывает у MVC. Уже устал искать где я ошибаюсь. Методы максимально коробочные - без какой либо моей логики. Чисто вызов webClient/Repository
Это же основа асинхронного выполнения - асинхронное выполнение всегда медленнее обычного синхронного, потому операция переключения потоков далеко не бесплатная, плюс создание объектов Mono и Flux тоже не бесплатные. Но в асинхронном выполнении минимизируется время простоя потоков, то есть если потоку требуется прождать где-то секунду или несколько, например дождаться ответа от другого сервера, то в синхронном программировании поток будет просто ждать, а в асинхронном поток не ждёт, и может заняться обработкой других вещей - например параллельно отправить другой запрос, или что-то подсчитать. Это очень полезно, потому что практически везде используются пулы потоков с ограниченным количеством потоков, и многие не знают, как увеличить тот или иной пул потоков, плюс вообще то каждый поток по умолчанию тратит 1МБ памяти под стек и приложение с 1000 потоков будет потреблять 1ГБ памяти только для потоков
Разницы нет. За время отклика отвечает сервер, т.к. он отдает веб-страницу. И делает он это всегда одинаково, независимо от того, кто у него запрашивают страницу - webflux или обычный httpClient. Если нагрузка маленькая то лучше использовать httpClient, т.к. код будет проще как для написания так и для отладки
Ммм, чел сравнил многопоточность с однопоточностью и решил, что это заслуги вебфлакса. А прикол реактивного программирования вообще не в этом. То, что ты сделал, это обычная многопоточность.
Нет, ты ошибаешься. В данном примере будет использован 1 main поток + io потоки netty (их число равно числу ядер). Итого, на 8-ядерной машине одновременное скачивание 256 страниц будет обеспечено 9 потоками. Это не многопоточка. Попробуй в 9 потоков скачать с помощью синхронного http-клиента 1000 страниц, и посмотри сколько у тебя уйдет времени. Гарантирую что удивишься.
Но ведь действительно эта асинхронность достигается через выполнение задачи в отдельном потоке. А поскольку вы запускаете много таких задач, то и получается многопоточность. Вообще я почти уверен, что если сделать загрузки через многопоточность, используя обычный http клиент, то результат будет как на webflux
@@flamencoag Так тут нет многопоточности. Тут ассинхронность. Мы просто избегаем блокировки при выполнении. Ты при многопоточности такого не добьешься, один поток это примерно 1мб, 256 потоков, удачи.
Спасибо за понятное объяснение!
Крутой пример, крутое объяснение! Спасибо!!!
Ёмкая наглядная демонстрация, спасибо!
Спасибо за видео! Вообще супер )
Extremely interesting! Plz countinue
супер можете еще снять видео с разбором оператора groupby
Странно, только что закончил перф-тест последнего (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, я ожидал все на оборот
Тоже никак не могу получить эту обещанную производительность( Ни db, ни походы на api. Ничего не выигрывает у MVC. Уже устал искать где я ошибаюсь. Методы максимально коробочные - без какой либо моей логики. Чисто вызов webClient/Repository
Товарищ тоже тестил и тоже подметил, что прироста скорости нет. Может разве что по памяти будет выгоднее, что тредов меньше крутится, но такое
Это же основа асинхронного выполнения - асинхронное выполнение всегда медленнее обычного синхронного, потому операция переключения потоков далеко не бесплатная, плюс создание объектов Mono и Flux тоже не бесплатные. Но в асинхронном выполнении минимизируется время простоя потоков, то есть если потоку требуется прождать где-то секунду или несколько, например дождаться ответа от другого сервера, то в синхронном программировании поток будет просто ждать, а в асинхронном поток не ждёт, и может заняться обработкой других вещей - например параллельно отправить другой запрос, или что-то подсчитать. Это очень полезно, потому что практически везде используются пулы потоков с ограниченным количеством потоков, и многие не знают, как увеличить тот или иной пул потоков, плюс вообще то каждый поток по умолчанию тратит 1МБ памяти под стек и приложение с 1000 потоков будет потреблять 1ГБ памяти только для потоков
А время отклика от 1 запроса в спринге с webflux при малой нагрузке быстрее? Чем в обычном спринге?
Разницы нет. За время отклика отвечает сервер, т.к. он отдает веб-страницу. И делает он это всегда одинаково, независимо от того, кто у него запрашивают страницу - webflux или обычный httpClient. Если нагрузка маленькая то лучше использовать httpClient, т.к. код будет проще как для написания так и для отладки
Ммм, чел сравнил многопоточность с однопоточностью и решил, что это заслуги вебфлакса. А прикол реактивного программирования вообще не в этом. То, что ты сделал, это обычная многопоточность.
Нет, ты ошибаешься.
В данном примере будет использован 1 main поток + io потоки netty (их число равно числу ядер). Итого, на 8-ядерной машине одновременное скачивание 256 страниц будет обеспечено 9 потоками. Это не многопоточка.
Попробуй в 9 потоков скачать с помощью синхронного http-клиента 1000 страниц, и посмотри сколько у тебя уйдет времени. Гарантирую что удивишься.
Но ведь действительно эта асинхронность достигается через выполнение задачи в отдельном потоке. А поскольку вы запускаете много таких задач, то и получается многопоточность.
Вообще я почти уверен, что если сделать загрузки через многопоточность, используя обычный http клиент, то результат будет как на webflux
@@flamencoag это сравнение я делаю в начале видео. Можете пересмотреть и увидеть разницу в скорости 3:51
@@flamencoag Так тут нет многопоточности. Тут ассинхронность. Мы просто избегаем блокировки при выполнении. Ты при многопоточности такого не добьешься, один поток это примерно 1мб, 256 потоков, удачи.
Супер 👍