反应式编程比非反应式编程消耗更多的资源吗？

Question

null

在这两种实现中，REST控制器都直接从存储库中获取数据，并将其作为列表RESP返回。作为通量。不执行进一步的应用程序逻辑。

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

事实上，非反应实现不仅有更好的HTTP吞吐量，而且更有趣的是，它比反应实现消耗更少的CPU和线程！这与预期尤其相反，因为我们预期反应版本只需少量线程即可扩展，如https://spring.io/blog/2016/07/28/reactive-programming-with-spring-5-0-M1中所述

有人面临过类似的问题吗？

Answer 1

我们使用spring-data-active-cassandra和Spring-Webflux对Spring-Data-Cassandra和spring-mvc执行了类似的测试。

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

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)

在执行这些测试时，非Reactor栈产生了147个线程，而Reactor栈产生了48个线程。

如果您比较结果，非Reactor栈比Reactor栈稍微快一点。它在大约23秒内将10,000个对象持久化到数据库中，而Reactor栈大约需要30秒。但是，如果比较两个堆栈中最慢的2%请求，Reactor栈几乎快了28%。

反应式堆栈的线程数较少，响应时间分布较均匀。没有一个请求被搁置。而对于无Reactor栈，1%的要求相对来说慢得可怕。

在一段持续的时间内，随着调用次数的增加，与非Reactor栈相比，Reactor栈将能够更好地扩展。因为与在服务器上打开的套接字数量相比，可以在服务器上生成的线程数量要少得多。同样，在这些测试中，CPU利用率在两个场景中都低于33%，从而证明CPU利用率并没有限制可伸缩性。