java - 响应式编程比非响应式编程消耗更多的资源吗？

我们目前正面临Spring webFlux的性能问题。
为了确定反应式编程的好处，我们实现了Spring Boot服务，该服务从MongoDB中获取数据，并通过REST API将其返回给使用者。

该服务有两种变体:

使用Spring Boot MongoRepository的非反应性实现。该服务将数据返回为列表

使用Spring Boot，ReactiveMongoRepository，spring-boot-starter-webflux的反应式实现。该服务以Flux返回数据。

在这两种实现中，REST Controller 都直接从存储库中获取数据，并将其作为List resp返回。作为助焊剂。不再执行任何应用程序逻辑。

我们对100个调用该服务的用户进行了小型负载/性能测试，我们发现非反应式实现的性能远好于反应式实现。

实际上，不仅非响应式实现具有更好的HTTP吞吐量，而且也许更有趣的是，与响应式实现相比，它消耗更少的CPU和更少的线程!
这与预期特别相反，因为我们预计响应式版本会随着https://spring.io/blog/2016/07/28/reactive-programming-with-spring-5-0-m1中提到的少量线程扩展

我们需要在设置中进行一些调整吗？

有人遇到过类似的问题吗？

最佳答案

我们使用Spring-Data-Reactive-Cassandra和Spring-Webflux对Spring-Data-Cassandra和Spring-MVC进行了类似的测试。

我们对这两个服务器的10000个请求进行了基准测试，并发率为100 req/sec。结果并不令人惊讶:

Non Reactive Stack:-
         Concurrency Level:      100
         Time taken for tests:   22.945 seconds
         Complete requests:      10000
         Failed requests:        0
         Percentage of the requests served within a certain time (ms)
           50%    190
           66%    253
           75%    288
           80%    314
           90%    384
           95%    465
           98%    627
           99%    824
          100%   1208 (longest request)

Reactive Stack:-
         Concurrency Level:      100
         Time taken for tests:   30.061 seconds
         Complete requests:      10000
         Failed requests:        0
         Percentage of the requests served within a certain time (ms)
           50%    304
           66%    379
           75%    421
           80%    443
           90%    507
           95%    589
           98%    694
           99%    736
          100%    858 (longest request)

如果比较结果，则非电抗堆栈比电抗堆栈要快一些。它在大约23秒内将10,000个对象持久存储在数据库中，而反应式堆栈则花费了大约30秒。但是，如果比较两个堆栈中最慢的2％请求，则反应堆栈快将近28％。

具有较少线程数的反应堆具有更均匀分布的响应时间。没有一个请求被拖延。对于非反应堆，请求的1％相对而言要慢得多。

在持续的时间内增加 call 数量时，与非反应式堆栈相比，反应式堆栈将能够更好地扩展。由于您可以在服务器上产生的线程数比您可以在服务器上打开的套接字数少得多。同样，在这些测试中，在两种情况下，CPU利用率均低于33％，从而证明CPU利用率并没有限制可扩展性。

如果不受线程上下文切换和线程创建的限制，则非反应堆可以扩展更多。