这是一个创建于 2180 天前的主题，其中的信息可能已经有所发展或是发生改变。
第 1 条附言 · 2018-12-29 10:48:09 +08:00
自问自答一下
性能方面官方也没有打包票说完爆 SpringMVC
> Performance has many characteristics and meanings. Reactive and non-blocking generally do not make applications run faster. They can, in some cases, (for example, if using the WebClient to execute remote calls in parallel). On the whole, it requires more work to do things the non-blocking way and that can increase slightly the required processing time.
> The key expected benefit of reactive and non-blocking is the ability to scale with a small, fixed number of threads and less memory. That makes applications more resilient under load, because they scale in a more predictable way. In order to observe those benefits, however, you need to have some latency (including a mix of slow and unpredictable network I/O). That is where the reactive stack begins to show its strengths, and the differences can be dramatic.
性能方面官方也没有打包票说完爆 SpringMVC
> Performance has many characteristics and meanings. Reactive and non-blocking generally do not make applications run faster. They can, in some cases, (for example, if using the WebClient to execute remote calls in parallel). On the whole, it requires more work to do things the non-blocking way and that can increase slightly the required processing time.
> The key expected benefit of reactive and non-blocking is the ability to scale with a small, fixed number of threads and less memory. That makes applications more resilient under load, because they scale in a more predictable way. In order to observe those benefits, however, you need to have some latency (including a mix of slow and unpredictable network I/O). That is where the reactive stack begins to show its strengths, and the differences can be dramatic.
 |
1
putaozhenhaochi 2018-12-28 17:36:35 +08:00
同关注+1
|
 |
2
cyhulk 2018-12-28 18:06:23 +08:00
来，我们可以一起骂骂 spring webflux，一个还不是很完整的生态，以及可读性和可理解性垃圾的 api，测试不好有测试不好的原因，为啥，因为你的 redis 请求都是 block 的，而且并不是 publishOnParallel 的，webflux 的 thread 可能只有你的核心数，你 webmvc，默认就 200 个，效果差肯定的
|
 |
3
Inside 2018-12-28 20:53:08 +08:00
我的文件服务器用上了，性能不理想大概率是代码写的不对，在 event loop 线程里做 block 操作。
在 IO bound 的场景，响应式性能好是可以预期的，比如 redis 这种单线程应用、比如 nginx 刚出世时让人惊讶的性能。 |
 |
4
zhyzhy OP @cyhulk 我的 redis 用的官方推荐的 reactive 的呀，这么写有问题吗？？？要手动 publishOnParallel，我看官方例子中没有手动 publish。。。
|
 |
5
kkllxy 2018-12-29 08:00:02 +08:00
关注+1
|
 |
6
godoway 2018-12-29 08:56:50 +08:00
同关注，坐等 spring data r2dbc 成熟。
|
 |
7
sagaxu 2018-12-29 09:04:51 +08:00 via Android
写一个这样的 http 接口，请求 /echo?q=foo，服务端过 20 秒钟返回 hello foo。传统阻塞型写法，1000 个 worker 线程最高能有 50rps。然后换 webflux 实现，可以轻松提高 100 倍性能。
|
 |
9
Tengdw 2018-12-29 09:31:39 +08:00
WebFlux 可以提高应用吞吐量，吞吐量提高并不代表响应时间降低。这个问题小马哥有讲过
|
|
10
cyhulk 2018-12-29 11:01:38 +08:00
@zhyzhy sorry 没注意看代码，你确实写了两个，但是你写在的是同一个项目里面，你最好分开写，一个全部用 Webflux 的统一，也就是 reactor-netty，另个一个完全 servlet，如果两个写在一个里面，可能使用的是 serverletcontainer，这样导致只能部分用的 reactor。没看到全部代码无法判断。还有 spring 官方并没说可以完胜传统的 servlet，但是可以保证不会像 servelet 那样启动 N 多的 worker。
|
 |
11
luosuosile 2018-12-29 11:39:14 +08:00
帮楼主顶一下，我也要开始玩 webflux
|
Select Language