R2DBC vs JDBC performance
I would like to talk about SQL clients for Java application. In this article, we will compare the performance of good old JDBC(Spring Data JDBC) with new and promising R2DBC(Spring Data R2DBC). There is no such performance comparison in open access.
The source code is available in my GitHub
We will measure performance for fully reactive service(WebFlux, Netty, Spring Data R2DBC) and plain blocking service(Spring MVC, Tomcat, Spring Data JDBC)
Machine: Windows 10 Pro, i7–4710HQ, 12 GB RAM
Java: Oracle Java 11
Database: Postgres 11( running locally in Docker on the same machine, reserved limit 1 CPU)
We will work with User POJO.
Will measure Save, Get, Delete and Get List endpoints. Will use JMeter for the performance test.
- We will add for an empty user table 100.000 users (200 parallel JMeter users, 500 times)
- Select the user by id (200 parallel JMeter users, 500 times))
- Select the first 100 users(200 parallel JMeter users, 500 times))
- Delete 100.000 users(200 parallel JMeter users, 500 times)
Blocking Spring MVC and Spring Data JDBC + HikariCP
JVisualVM view for Select the first 100 users. 224 Threads with blocking.
Reactive Spring WebFlux with Spring Data R2DBC and R2DBC-Pool
Spring Data R2DBC by default doesn’t have connection pool. Fortunatly, we have a true reactive connection pool https://github.com/r2dbc/r2dbc-pool.
JVisualVM view for Select the first 100 users. No blocking threads
Select top 100 slowness
The throughput for get/add/delete endpoints is the same for R2DBC and JDBC. But select top 100 users two times slower for R2DBC. I’ve profiled the application the snapshot is here https://github.com/Aleksandr-Filichkin/r2dbc-vs-jdbc/blob/master/r2dbc-select-list.nps. As expected, the biggest total time we have for parsing responses from DB.
I’ve created the ticket( https://github.com/spring-projects/spring-data-r2dbc/issues/203) in R2DBC GitHub. Not sure if it can be improved.
We see that Spring Data R2DBC is a true reactive driver, doesn’t have any blocking and it doesn’t need addition threads. The throughput for get/add/delete endpoints is the same for R2DBC and JDBC. But select top 100 users two times slower for R2DBC.