与传统 IO 相比，网络流量 Netty NIO 性能降低了约 30 倍

Question

我们在使用Spring Boot 2.0、Webflux 5.0.7和Netty 4.1.25时遇到了网络传输问题。我们想将100000个序列化为JSON的项目(大约10Mb的网络流量)传输到一个客户端。

NIO和传统IO的网络传输性能有显著差异。测试结果如下：

Start reading 100000 from server in 5 iterations
Avg HTTP 283 ms
Avg stream 8130 ms

目前每秒的请求数量不是问题，但网络传输速度是问题。我们已经了解到，就网络速度而言，NIO可能会慢30%左右，但1/30倍是多余的。

在对客户端和服务器端进行采样时，我们发现原因主要是服务器端实现。从下面的屏幕截图可以看出，服务器花费在方法select（）和doWrite（）上的时间最多。

endpoint代码本身:

@RestController
@RequestMapping(produces = {APPLICATION_JSON_VALUE, APPLICATION_STREAM_JSON_VALUE})
@Validated
public class StreamingController {

    @GetMapping("/instruments/{eodDate}")
    public Flux<TestItem> getInstruments(
            @PathVariable @DateTimeFormat(pattern = "yyyy-MM-dd") LocalDate eodDate,
            @RequestParam(required = false) Instant asOfTimestamp) {
        //Generate test data in memory
        List<TestItem> collect = IntStream.range(0, 100000)
             .mapToObj(i -> new TestItem.Builder().build())
             .collect(Collectors.toList());
        return Flux.fromIterable(collect);
    }
}

我们对Netty使用Spring Boot配置，我们怀疑默认情况下Netty配置错误。我们正在寻求你的帮助。我会根据你的要求添加任何其他细节。

Upd：目标是批量读取整个响应，以避免将所有响应放入内存，因为预期的数据量很大（几Gb）。在客户端消耗一批数据而不是一个元素是可以接受的。

Answer 1

您实际上并没有测试蔚来与IO。SpringWebFlux应用程序始终在服务器级别使用非阻塞IO（使用Netty，Undertow或任何符合Servlet 3.1异步IO的服务器）。

在这种情况下，您要比较:

< li >使用Spring WebFlux一次性提供< code >“application/JSON”有效负载 < li >使用Spring WebFlux提供流< code >“应用程序/流JSON”响应

在第一种情况下，SpringWebFlux以一种被动的方式生成响应主体，但将缓冲和刷新决策留给服务器本身。向网络写入是有成本的，缓冲一个但写入更大的块是有效的。

在第二种情况下，你要求SpringWebFlux为通量的每个元素编写和刷新。当客户端正在侦听（可能是无限的）事件流并且两个不同的事件之间可能有一些时间时，这很有用。这种方法消耗了更多的资源，并解释了性能差异。

因此，这个基准测试并没有显示IO与NIO，而是流媒体与非流媒体。

如果您想对响应写入/刷新进行细粒度控制，可以降到ServerHttpResponse级别，并使用writeAndFlushWith（Flux

另一种方法是创建包含< code>TestItem列表的中间JSON对象，比如:

public Flux<TestItemBatch> batch() {
    Flux<TestItem> items= //...;
    Flux<List<TestItem>> itemsLists = items.buffer(100);
    return itemsLists.map(list -> new TestItemBatch(list));
}