Действительно один из лучших докладов на тему. Не просто теория, но практика с анализом большого количества данных. Особенно порадовал трюк с обработкой CSV с помощью постргес. Гениально! :)
Как может быть бедный Hikari при R2DBC, если там используется специальный реактивный пул? То есть автор указал причину бессмысленности реактивного стека из-за HikariCP, хотя сам и не использовал реактивный пул. К тому же данный пул уже автоматически идет со стартером spring-data-reactive
я что-то не услышал главного в этом докоаде, а зачем реактивный подход в crud функциях? микроскопом тоже гвозди забивать не удобно, значит ли, что микроскоп как инструмент не оправдал ожиданий?
Комментарий от автора доклада: просто в последнее время все ударились в реактивщину, в том числе тащат ее для работы с реляционными базами данных, я же показал, что в большинстве случаев в этом как раз нет смысла. Я оставил свой развернутый комментарий к этому видео.
@@kotoant спасибо за ответ. поясню что я услышал в докладе "перечисленные варианты использования реактивного подхода с crud функционалом не состоятельны, следовательно вам не нужен реактивный подход в 99%". я считаю что это не корректный посыл. нет смысла перебирать разные варианты реализации реактивного подхода в случае с crud. потому что в функции crud нет тех проблем, которые решаются реактивным подходом. то есть вся ценность этих сравнений производительности разных реализации сводится к нулю просто потому что рассматриваемая функция в принципе своём не должна решаться реактивно. но при этом реактивный подход может помочь в 95% функции всего проекта, если эти функции НЕ crud.
не понятно почему loom так обладжался там же подкапотом используется forkjoin pool а он берет количество потоков из количества процессоров кот у вас было 4 следовало бы увеличить его размер явно
@@xz8928 правильное замечание, на него ответ "нигде" :) Я хотел сказать, что виртуальные потоки не создают своих ограниченных пулов, но работают поверх обычных пулов потоков, емнип. Тот же ForkJoin по дефолту. То есть JVM эффективно управляет этими виртуальными потоками и для запросов по сети они будут большую часть времени спать, когда при запросах в базу будут блокироваться на чтение/запись и быстро выжирать предоставленный пул коннекта к базе. Наверно можно сказать так: пулы будут везде, просто виртуальные потоки получат преимущество там, где нет блокировок
@@xz8928 нигде нет) Наверно стоило сказать что Project Loom юзается там, где потоки могут ожидать (сетевые запросы), поэтому от размера пула нет сильной зависимости. Но работают виртуальные потоки все равно поверх пулов и в коннектах к базе, например, пул будет забиваться блокирующими операциями в потоках.
@@xz8928 нигде нет) Наверно стоило сказать что Project Loom юзается там, где потоки могут ожидать (сетевые запросы), поэтому от размера пула нет сильной зависимости. Но работают виртуальные потоки все равно поверх пулов и в коннектах к базе, например, пул будет забиваться блокирующими операциями в потоках.
@@xz8928 нигде нет) Наверно стоило сказать что Project Loom юзается там, где потоки могут ожидать (сетевые запросы), поэтому от размера пула нет сильной зависимости. Но работают виртуальные потоки все равно поверх пулов и в коннектах к базе, например, пул будет забиваться блокирующими операциями в потоках.
Дак в итоге где выигрыш от реактивщины будет, если не в CRUD то где? Получается чисто в модулях сетевой логики, роутинга и расчётов типа ETL? НО ETL это тоже EXTARCT и LOAD.... НУ ок выделим TRANSFORM в отдельный Async модуль - ну хрень какая-то....
Доклад начинается с 6:05
Действительно один из лучших докладов на тему. Не просто теория, но практика с анализом большого количества данных. Особенно порадовал трюк с обработкой CSV с помощью постргес. Гениально! :)
Как может быть бедный Hikari при R2DBC, если там используется специальный реактивный пул?
То есть автор указал причину бессмысленности реактивного стека из-за HikariCP, хотя сам и не использовал реактивный пул. К тому же данный пул уже автоматически идет со стартером spring-data-reactive
я что-то не услышал главного в этом докоаде, а зачем реактивный подход в crud функциях? микроскопом тоже гвозди забивать не удобно, значит ли, что микроскоп как инструмент не оправдал ожиданий?
Комментарий от автора доклада: просто в последнее время все ударились в реактивщину, в том числе тащат ее для работы с реляционными базами данных, я же показал, что в большинстве случаев в этом как раз нет смысла. Я оставил свой развернутый комментарий к этому видео.
@@kotoant спасибо за ответ. поясню что я услышал в докладе "перечисленные варианты использования реактивного подхода с crud функционалом не состоятельны, следовательно вам не нужен реактивный подход в 99%". я считаю что это не корректный посыл. нет смысла перебирать разные варианты реализации реактивного подхода в случае с crud. потому что в функции crud нет тех проблем, которые решаются реактивным подходом. то есть вся ценность этих сравнений производительности разных реализации сводится к нулю просто потому что рассматриваемая функция в принципе своём не должна решаться реактивно. но при этом реактивный подход может помочь в 95% функции всего проекта, если эти функции НЕ crud.
не понятно почему loom так обладжался
там же подкапотом используется forkjoin pool а он берет количество потоков из количества процессоров кот у вас было 4
следовало бы увеличить его размер явно
Доклад - хорош.
Ну да, смысл Project Loom больше в запросах по сети, где нет ограниченных пулов коннекта, которые будут блокировать все потоки
а где вообще есть неограниченные пулы коннекта ?
@@xz8928 правильное замечание, на него ответ "нигде" :)
Я хотел сказать, что виртуальные потоки не создают своих ограниченных пулов, но работают поверх обычных пулов потоков, емнип. Тот же ForkJoin по дефолту.
То есть JVM эффективно управляет этими виртуальными потоками и для запросов по сети они будут большую часть времени спать, когда при запросах в базу будут блокироваться на чтение/запись и быстро выжирать предоставленный пул коннекта к базе.
Наверно можно сказать так: пулы будут везде, просто виртуальные потоки получат преимущество там, где нет блокировок
@@xz8928 нигде нет)
Наверно стоило сказать что Project Loom юзается там, где потоки могут ожидать (сетевые запросы), поэтому от размера пула нет сильной зависимости. Но работают виртуальные потоки все равно поверх пулов и в коннектах к базе, например, пул будет забиваться блокирующими операциями в потоках.
@@xz8928 нигде нет)
Наверно стоило сказать что Project Loom юзается там, где потоки могут ожидать (сетевые запросы), поэтому от размера пула нет сильной зависимости. Но работают виртуальные потоки все равно поверх пулов и в коннектах к базе, например, пул будет забиваться блокирующими операциями в потоках.
@@xz8928 нигде нет) Наверно стоило сказать что Project Loom юзается там, где потоки могут ожидать (сетевые запросы), поэтому от размера пула нет сильной зависимости. Но работают виртуальные потоки все равно поверх пулов и в коннектах к базе, например, пул будет забиваться блокирующими операциями в потоках.
Очень хороший доклад. Действительно, развенчивает миф о асинхронщине.
Дак в итоге где выигрыш от реактивщины будет, если не в CRUD то где? Получается чисто в модулях сетевой логики, роутинга и расчётов типа ETL? НО ETL это тоже EXTARCT и LOAD.... НУ ок выделим TRANSFORM в отдельный Async модуль - ну хрень какая-то....
Интересно
Код на корутинах выглядит, как костыли, какой же котлин все таки убогий стал - превращается в джаваскрипт потихонечку)
Код на корутинах выглядит как код без корутин если убрать ключевое слово suspend.