Netty 是否适合长时间运行的高 TPS 客户端

Question

我已经尝试使用几个不同的库来构建通过 TCP 提供市场数据的服务器，Netty.io 就是其中一个候选者。本质上，我已经构建了一个小型 POC，并且在 64K TPS 等高注入率下遇到了一些性能问题。它似乎在 32K TPS 下运行良好，但在 64K TPS 以上时跌落悬崖并有效地停了下来。

以下时序图显示了服务器在 64K TPS 时的消息 IN 和 OUT。正如您在高注入率下看到的那样，它无处不在。

这是 32K TPS 的类似图表

代码很简单。我使用客户端的请求，将其提交给市场数据服务，该服务通过我拥有的 RXJava 管道将消息流式传输。消息被编码为二进制响应并通过 TCP 发送回客户端。我试图弄清楚我需要从哪里开始寻找。我确实知道瓶颈在编码方面非常重要，因为进入服务器的消息数量一开始就很高。每次收到消息时我都会刷新频道，所以我不确定这是否是导致它的原因。任何指导表示赞赏。

ServerBootstrap serverBootstrap = new ServerBootstrap();
    serverBootstrap
        .group(parentGroup, workerGroup)
        .channel(NioServerSocketChannel.class)
        .localAddress(port)
        .childOption(ChannelOption.SO_SNDBUF, 16777216)
        .childOption(ChannelOption.WRITE_BUFFER_WATER_MARK, new WriteBufferWaterMark(16777216,33554432))
        .childHandler(new ChannelInitializer<SocketChannel>() {
            @Override
            protected void initChannel(SocketChannel socketChannel) throws Exception {
                //Build Pipeline to decode, process messages and encode response
                socketChannel.pipeline()
                    .addLast(
                        new FlushConsolidationHandler(1000, true),
                        createMessageFrameBuilder(),
                        new InboundMessageDecoder<>(),
                        new MarketDataReqResponseHandler<>(),
                        new MessageEncoder()
                    );
            }
        });

Answer 1

您很可能应该批量处理刷新，因为flush() 很昂贵。您可以做的一件事是将FlushConsolidationHandler 添加到管道中。这将确保在安全的情况下将刷新合并在一起，从而最大限度地减少系统调用。