Pull to refresh

Comments 8

Стоит указать, что реактивщина побеждает в случае Spring. Предыдущая статья того же автора: https://technology.amis.nl/2020/03/27/performance-of-relational-database-drivers-r2dbc-vs-jdbc/ не менее интересна — там в гонке добавлен Quarkus (JDBC & R2DBC) и он в варианте JDBC бъет спринг с реактивщиной. Интересно посмотреть и на компромисы — процессор против памяти против пропускной способности.

Это тру бенчмарк от главного контрибьютера в R2DBC
https://github.com/r2dbc/r2dbc-postgresql/pull/158
Видно что R2DBC проигрывает по перфомансу JDBC во всех кейсах.


https://github.com/spring-projects/spring-data-r2dbc/issues/203
Здесь можно почитать очень интересное обсуждение

Vertx клиент никто не архивировал и он активно развивается: github.com/eclipse-vertx/vertx-sql-client
R2DBC для продакшена еще не готов, то там то здесь вылазят баги — лично сталкивался и постил им тикеты. Да и проскальзывало, что разработчики сосредоточены на доведением его до ума, а не попытках выжать максимум производительности.
Так же Вертх очень быстр: www.techempower.com/benchmarks/#section=data-r15&hw=ph&test=db
Единственное пришлось сделать свою прослойку чтобы удобно работать с ним через Flux/Mono.
Ох, что-то я пропустил этот клиент от Vertx. Спасибо!

я тут накидал проект для теста *без веба и запросов, чтобы исключить влияние блокирующего и неблокирующего "веба" и вынес базу на внешний сервер, чтобы он не мешал бенчмарку. VertX vs R2DBC vs JDBC Postgres, все с пулом соединений. Результаты:
1) Очень сильно зависит от пула соединений. Это важно, потому что иногда можно позволить себе большой пул, а иногда нельзя. И пул все равно всегда используется. Пул для JDBC можно выбрать, а для реактивных — только по одному поддерживаемому.
2) Сильно зависит от количества конкурентных акторов.
3) Сильно зависит от того, медленные запросы в базу или быстрые.


В двух словах для старого linux jdk 11 ноута: затраты на переключение потоков невелики, пока их сотни. На тысячах начинает проявляться, если пул к базе относительно большой, но все равно довольно слабо влияет на общее время. Да, во JFR/JMC потоки на jdbc красненькие все, а в reactive все зелененькое, но толку от красок? Памяти жрет больше с потоками. Быстрее всего vertx-pg, медленнее всех r2dbc. Но на отдельных тестах все могут давать одинаковые результаты или вырываться вперед/отставать.
Ну и надо смотреть на конкретные места — маршаллинг данных, сколько прилетает в ответе данных, нужны ли транзакции, сколько запросов в транзакции. Тюнинг пула дает больше всего — там и настройки кэширования prepared statement могут быть, и прочая и прочая....

Спасибо за отличный комментарий, который, как обычно на хабре бывает, полезнее статьи :)

Не хотите написать свою статью, с этими бенчмарками? Может, кто-то еще что-то интересное расскажет, а то в этой статье как-то совсем пусто получилось :(

демотивирован — за прошлую статью получил плюсов в статью и минусов в карму. Хорошо хоть на минимуме для голосования остался.
А подобная статья с базами — тема холиварная, не упомянешь какую-то деталь вроде "а вот -XXUncompressShit" или кто-то запутается в подписках реактора — у всех настроение испорчено. Слишком обширная тема, я пока остыну и, может, соберусь…
А вот GitHub, если интересно.

Sign up to leave a comment.

Articles