IG
Так как тред пул для Netty ограничен.
Size: a a a
2020 September 22
SA
Так как тред пул для Netty ограничен.
Так это аксиома, что в IO пуле нельзя ничего блокирующего запускать, при получении запроса из нетти нужно всегда переходить в другой, рабочий пул.
AE
Интересно, были ли хоть у кого-нибудь проблемы с производительностью блокирующего jdbc.
если есть реально долгие запросы, то нетти с r2dbc даст обгромный буст по сравнению с jdbc, даже на классическом mvc
SA
Т.е. r2dbc используется, чтобы не настраивать самим рабочий пул для jdbc? Ну, можно и так, конечно.
IG
Т.е. r2dbc используется, чтобы не настраивать самим рабочий пул для jdbc? Ну, можно и так, конечно.
r2dbc -> non-blocking driver
AE
Т.е. r2dbc используется, чтобы не настраивать самим рабочий пул для jdbc? Ну, можно и так, конечно.
r2dbc не блокирует потоки на работе с бд
AE
меньше ресурсов потребляется
TI
Интересно, были ли хоть у кого-нибудь проблемы с производительностью блокирующего jdbc.
Дело же не только в производительности, но и в утилизации ресурсов. Сервер без блокировок экономнее и может обработать больше запросов (нет ограничения на количество тредов). Да и расходы на переключение контекста меньше
TI
А сам запрос может за такое же время в итоге обработаться как и блокирующий код
SA
Дело же не только в производительности, но и в утилизации ресурсов. Сервер без блокировок экономнее и может обработать больше запросов (нет ограничения на количество тредов). Да и расходы на переключение контекста меньше
Это верно в общем случае, но неверно для jdbc, т.к. кол-во параллельных транзакций жестко ограничено сервером. Учитывая, что RDBMS - это не очень быстро (единицы-десятки миллисекунд на запрос), затраты цпу на переключение контекстов потоков ничтожны на общем фоне.
TI
Для клауд окружения утилизировать ресурсы наиболее эргономно актуально
AE
Дело же не только в производительности, но и в утилизации ресурсов. Сервер без блокировок экономнее и может обработать больше запросов (нет ограничения на количество тредов). Да и расходы на переключение контекста меньше
главное еще базу при этом прокачать на соответствующее количество подключений и запросов
AE
А сам запрос может за такое же время в итоге обработаться как и блокирующий код
так время обработки естественно то же самое. просто количество запросов обработать можно больше
TI
Это верно в общем случае, но неверно для jdbc, т.к. кол-во параллельных транзакций жестко ограничено сервером. Учитывая, что RDBMS - это не очень быстро (единицы-десятки миллисекунд на запрос), затраты цпу на переключение контекстов потоков ничтожны на общем фоне.
Ну в целом я согласен, что блокирующий пул делает реактивное приложение хуже
TI
Просто настолько хуже, что вся реактивщина уже не имеет смысл - с таким тезисом не согласен.
B
Он быстрее чем async. Производительность приложения может пострадать если используется netty pool для incoming http requests (webflux)
А что Webflux использует для этого? Он же вроде использует скедулер контейнера, для томката по крайней мере точно
IG
Balas
А что Webflux использует для этого? Он же вроде использует скедулер контейнера, для томката по крайней мере точно
там ограниченный пул тредов, который он может использовать. Если блокируешь выделенный тредик -> беда.
B
Я не про блокировку, про incoming http request
SA
И правда. spring webflux вызывает контроллеры из потока IO пула нетти. Позорище....
IG
Balas
Я не про блокировку, про incoming http request
netty. (но может я не особо понял вопрос)