我们目前正面临Spring webFlux的性能问题。为了确定反应式编程的好处,我们实现了一个Spring Boot服务,该服务从MongoDB中获取数据并通过REST API将其返回给使用者。
该服务有两个变体:
在这两种实现中,REST控制器都直接从存储库中获取数据,并将其作为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)
[执行这些测试时,非反应式堆栈产生147个线程,而反应式堆栈产生48个线程。
如果比较结果,则非反应堆比反应堆要快一些。它在大约23秒内将10,000个对象保留在数据库中,而反应式堆栈大约花费了30秒。但是,如果比较两个堆栈中最慢的2%请求,则反应式堆栈快将近28%。
具有较少线程数量的反应堆具有更均匀分布的响应时间。没有一个请求被拖延。对于非反应堆,请求的1%相对而言要慢得多。
在持续的时间内增加呼叫数量后,与非反应式堆栈相比,反应式堆栈将能够更好地扩展。由于您可以在服务器上产生的线程数比您可以在服务器上打开的套接字数少得多。同样,在这些测试中,在两种情况下,CPU利用率均低于33%,从而证明CPU利用率并没有限制可扩展性。
如果非活动堆栈不受线程上下文切换和线程创建的限制,则可以扩展更多。