Affects: 3.0.3
Hi, yesterday I finished small performance tests between Spring Boot MVC (classic) vs Spring Boot WebFlux with R2DBC.
Originally I heard that WebFlux provides +30% to performance out of the box (ok, maybe 30% is too much, but still it is supposed to be faster)
Though my results are very opposite, long story short here are the results of Troughput/s
Non-DB calls (Actuator: health/info):
MVC: 310.17
WebFlux: 225.94
With DB Calls (create/get all)
MVC: 115.51
WebFlux with R2DBC: 33.50
So the result is the completly opposite, WebFlux x3 times slower than MVC, which doesn't sound right at all.
I published projects and all reports, including *.jmx files which were used during the tests in JMeter folders in each project:
During the tests I used 3 AWS EC2 instances: 1) DB Instance - running Postgres in docker (just for easier wipe) (t3.small) 2) Service instance - where I was starting mvc and reactive Jars (t2.micro - 1 Core 1 RAM) 3) JMeter instance - where I was starting tests (t3.medium)
So is it me doing something wrong and WebFlux requires additional tuning? Or something was changed in last Spring Boot 3+ and before it was performing faster? Or it was always like that and the reactive performance is the myth?
Comment From: bclozel
Related: https://matrix.to/#/!poRJqCihtKxXkqtIDZ:gitter.im/$PgUic38mdOVx9Ghn0j_r1ghOCHTI1ERw_4L-efK30GE?via=gitter.im&via=matrix.org&via=hive-mind.network
As explained in the related conversation:
Reactive web isn't as much about raw performance improvement as it is about enabling async behaviors, better thread management, more predictable throughput, etc.
I'm not sure where this "+30%" number comes from - it really depends on the use case. An MVC application with little latency and well tuned thread pools could perform better than a reactive variant. This issue shows that under certain conditions, MVC performs better than reactive; there always will be such cases.
We got many similar reports in the past, and most of them turn out to be issues in the benchmark setup. For a JMeter setup, the coordinated emissions issue is a common one. Looking at raw throughput is also the wrong indicator: it could be that MVC is processing more requests, but the 95 percentile for latency is unacceptable. The important part is really to come up with a realistic benchmark for your application and decide yourself. If throughput is the main goal (and high latency isn't much of a problem), then MVC will do a great job and I don't think this should be a driver for considering reactive in the first place.
Unless you can point to a particular bottleneck in our codebase by using a profiler (see these PRs for good examples), I don't think investigating here is a good investment for the project. I'm closing this issue as a result.