Comments 9
Традиционный первый комментарий: скрипач не нужен, родной, он только топливо жрёт. Скоро подвезут файберы и корутины, и всё само заработает, а мы будем ничего не делать и получать свои 300к/сек. Верно, bsideup ?
Конечно, конечно… нет :D
Файберы и корутины упрощают для юзера, а реактивщина — делает чтобы быстро было!
Одно другому не мешает ;)
ИМХО файберы виртуальные потоки только улучшат adoption реактивных технологий — потому что можно будет не бояться "что-то там заблокировать", а всякие flatMapconcatMap превратятся в обычный map.
А не поделитесь ссылками чтобы подтвердить своё мнение? На открытые баг репорты, бенчмарки.
А то иначе выглядит как вброс ;)
так же можно посмотреть: www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=db
Из проблем с чем я столкнулся: github.com/r2dbc/r2dbc-postgresql/issues/207 и не обленился сделать ишью.
Так же периодически зависали конекты и приходилось убивать джава процесс.
Если сделать матрешку из конекшена, пула и прокси то у меня на мультитредовых тестах вылетала 34000 постгрес ошибка, хотя никакими курсорами я не пользовался. Стоило убрать либо прокси либо пул и все становилось хорошо.
Периодически получал ошибку, что конекшен неожиданны был закрыт.
До текущего релиза шел в комплекте r2dbc-client, а сейчас то-ли на него забили то-ли еще что, но в bom его уже нет. Что также неприятно.
За репорт — респект!
Про "мультитредовые тесты" — надеюсь тоже репортил.
По ссылке на TechEmpower (который я кстати не очень люблю, учитывая что он был создан чтобы показать какой их фреймворк быстрый и ни раз был замечен делающим некорректные бенчмарки для других) r2dbc не нашёл.
Опять же, стоит мерять производительность реальных реактивных сервисов (JDBC + Thread Pool vs R2DBC), где каждый вызов JDBC будет идти через context switch т.к. блокировать текущий реактивный поток нельзя.
В "песочнице" R2DBC vs JDBC показывает себя неплохо (особенно с MSSQL, кстати), а так же есть куда оптимизировать. В таких вещах обычно первым идёт "сделать чтобы работало" а потом уже "чтобы быстро".
Про «мультитредовые тесты» — надеюсь тоже репортил.
не — я понял, что надо убирать r2dbc иначе в проде будет беда и в авральном режиме переписывал все на vertx.io/docs/vertx-pg-client/java
В таких вещах обычно первым идёт «сделать чтобы работало» а потом уже «чтобы быстро».
Согласен, поэтому и написал, что в качестве PoC все смотрится красиво :)
учитывая что он был создан чтобы показать какой их фреймворк быстрый
А какой из фреймворков их?
R2DBC Arabba-RELEASE — новый взгляд на реактивное программирование для SQL