Spring Data R2DBC two times slower than Spring Data JDBC for Flux response

[Aleksandr-Filichkin]

Hi,

I've compared Spring Data R2DBC with Spring Data JDBC (Postgres DB) and see that add/get/delete performance almost the same. But for the method
public Flux<User> getWithLimit(@RequestParam int limit) { return userRepository.findWithLimit(limit); }

@Query("select * from blog.user limit $1") Flux<User> findWithLimit(int limit);

the throughput two times worse.

Here

• full article https://medium.com/@filia.aleks/r2dbc-vs-jdbc-19ac3c99fafa
• the code https://github.com/Aleksandr-Filichkin/r2dbc-vs-jdbc
• profiler snapshot https://github.com/Aleksandr-Filichkin/r2dbc-vs-jdbc/blob/master/r2dbc-select-list.nps

[Aleksandr-Filichkin]

@mp911de Not sure if it's possible to improve the performance.
Also maybe the problem with postgres-r2dbc, not with this repo.

[mp911de]

Thanks for having a look. Please check out our performance efforts at pgjdbc/r2dbc-postgresql#158 that contain JMH benchmarks. Results clearly show that PGJDBC is significantly faster in extended query mode than R2DBC.

We're happy to receive contributions in the form of optimizations or if someone is able to pin down a specific issue that we can address.

On a related note: With a bare-bone netty client that just receives and sends Postgres frames (without decoding these and without all the reactive dance), we weren't able to significantly improve SELECT performance. The best value there was about 60% of the PGJDBC performance. We'd be happy to get you involved in that efforts.

[Aleksandr-Filichkin]

@mp911de, Thank you. Didn't see this great JMH benchmarks. I got pretty the same result.

[mp911de]

Closing this issue as this isn't something we can work on for now.

[marccollin]

so actually no way to improve performance of select query?

[mp911de]

Primarily, this is a gap in the Postgres driver. PGJDBC yields on localhost about ~15.000 queries per sec, the R2DBC driver ~11.000 queries/sec (measurements as of my machine). Putting Postgres into docker yields ~ 1360 queries/sec with PGJDBC and about ~1355 queries/sec (both on localhost). So inducing latency as in real-world applications narrows the gap from ~36% difference to 1% difference.

Please also note that due to heavy Mono and Flux creation we experience an increased GC pressure and a 25% performance drop in queries/second returning a small number of items is the normal mode of operation. Strengths of reactive data access come into play when the queried amount of data is huge, the database requires multiple roundtrips as with cursors, or the application can benefit from pipelining. These aren't the benchmark cases found in archetypical benchmark comparisons.

/cc @davecramer

[marccollin]

thanks a lot for theses explications

[davecramer]

It's actually fairly difficult to get better performance than the blocking driver when testing a single connection. I don't think anyone has tried to measure concurrent bandwidth

[marccollin]

it should have some... to help people to choose between two way of development

[davecramer]

@marccollin some ?
The bigger difference is how many threads you require to read N JDBC connections vs R2DBC connections. JDBC is 1:1 whereas R2DBC should be 1:many

[mp911de]

You don't buy into reactive programming because you want your queries to run faster. You apply reactive programming patterns to improve your application scalability and resilience.