Webflux 号称性能强悍，实际项目里却发现性能不升反降。经验上，当后端服务的响应时间小于10ms，则异步非阻塞提升不明显，甚至效果变差。本文会将对此做验证。
（注：性能相关的结论只能作为经验结论，实际程序的表现还是需要实际 profile）
实验设置
数据流如下：通过 jmeter 发送 POST 请求到 TestService，转发流量到后端服务。
这里发送的请求是 POST 请求，发送内容是约为 800B 的 Json 来保证一定程度上的计算量，目的是为了模拟真实的使用场景。事实上如果只是转发 GET 而没有任何计算，则 webflux 完胜 blocking 的方式。
实验结果
结论：在 Backend 低延时(<10ms)的情况下，Webflux 的的彼时和吞吐都普遍不如 blocking 的方式。
上图中，左图代表延时，右图代表吞吐，横坐标是后端 sleep 的毫秒数。横坐标是 log 坐标，用以保证 <10ms 的密集区可以较好地展示。延时只关心 99 分位和 999 分位（图中同颜色的线，下方代表 99 分位，上方代表 999 分位），不用关心绝对值，只需要关注蓝线和红线的相对位置。解读如下：
- 左边 4 图中，当后端 sleep < 10ms 时，99 分位的蓝线都要低于红线，代表同步延时要低于 webflux
- sleep < 10ms 时，999 分位的蓝线普遍低于红线，但也有例外
- 右边 4 图的吞吐，在 sleep < 10ms 时蓝线均低于红线。代表同步的吞吐更高
- 灰线代表的直接发送的方式不同情况下延时和吞吐都有波动，目前还没想明白原因
- 当压力和后端延时增加时，webflux 的优势也慢慢体现