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

Test scenario

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)

REST endpoints

We will work with User POJO.

Will measure Save, Get, Delete and Get List endpoints. Will use JMeter for the performance test.

1. We will add for an empty user table 100.000 users (200 parallel JMeter users, 500 times)
2. Select the user by id (200 parallel JMeter users, 500 times))
3. Select the first 100 users(200 parallel JMeter users, 500 times))
4. Delete 100.000 users(200 parallel JMeter users, 500 times)

Blocking Spring MVC and Spring Data JDBC + HikariCP

Let’s start with plain Spring MVC and Spring Data JDBC. By default it uses the most poverfull connection pool HikariCP. It’s the most effecient connection pool for JDBC.

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

JVisualVM view for Select the first 100 users. No blocking threads

RESULT

Throughput(200 parallel JMeter users)

CPU utilization(200 parallel JMeter users)

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.

R2DBC profile for top 100 users

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.

Conclusion

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.