【问题标题】:How to write a high performance Netty Client如何编写高性能的 Netty 客户端
【发布时间】:2012-01-16 16:09:30
【问题描述】:

我想要一个非常高效的 TCP 客户端来发送 google 协议缓冲区消息。我一直在使用 Netty 库来开发服务器/客户端。

在测试中,服务器似乎能够每秒处理多达 500k 事务,没有太多问题,但客户端往往达到每秒 180k 事务的峰值。

我的客户基于 Netty 文档中提供的示例,但不同之处在于我只想发送消息并忘记,我不想要响应(大多数示例都会得到)。有没有办法优化我的客户端,让我可以达到更高的TPS?

我的客户应该维护多个通道,还是应该能够通过单个通道实现比这更高的吞吐量?

【问题讨论】:

  • 时间确实听起来就像客户端正在等待响应......只是一个想法 - 因为它听起来像一个相当简单的服务,你是否尝试过使用原始套接字?
  • 如果有人解决了此类客户端的问题,您能否分享一下客户端代码,例如使用哪个netty版本?目前我被版本更改卡住了

标签: tcp protocol-buffers netty


【解决方案1】:

1) 如果客户端只对发送感兴趣,对接收不感兴趣,您可以随时禁用从通道读取,如下所示

channel.setReadable(false);

2) 通过每个客户端拥有多个客户端通道,您可以非常轻松地提高吞吐量,而且它也可以扩展。

3) 并且您可以进行以下调整以提高总体性能(对于读/写)

  • 最好通过添加带有 OrderdMemoryAwareThreadPoolExecutor 的 EXecutionHandler 来拥有类似 SEDA 的管道,(具有最佳值的最小、最大通道内存)

    bootstrap.setPipelineFactory(new ChannelPipelineFactory() {
        @Override
        public ChannelPipeline getPipeline() throws Exception {
            return Channels.pipeline(
                    executionHandler1,//sharable
                    new MessageDecoderHandler(),
                    new MessageEncoderHandler(),
                    executionHandler2,//sharable
                    new BusinessLogicHandler1(),
                    new BusinessLogicHandler2());
        }
    });
    
  • 将通道的writeBufferHighWaterMark设置为最优值(确保设置大的值不会造成拥塞)

    bootstrap.setOption("writeBufferHighWaterMark", 10 * 64 * 1024);

  • 设置 SO_READ、SO_WRITE 缓冲区大小

    bootstrap.setOption("sendBufferSize", 1048576); bootstrap.setOption("receiveBufferSize", 1048576);

  • 启用 TCP 无延迟

    bootstrap.setOption("tcpNoDelay", true);

【讨论】:

  • 谢谢,关于第 2 点的一个问题)。最好的方法是什么,我应该创建多个通道,并将它们的处理程序放在某种工作队列中,以处理请求?
  • @Dave 看看这个答案,看看客户端如何使用多个连接stackoverflow.com/a/7905761/596720
  • 我发现setReadable(false) 可能不是一个好主意,除非您有办法知道远程端在不尝试读取频道的情况下已断开连接。 read() 远端挂断时返回-1
【解决方案2】:

我不确定“tcpNoDelay”是否有助于提高吞吐量。延迟是为了提高性能。尽管如此,我尝试了一下,发现吞吐量实际上下降了 90% 以上。

【讨论】:

    猜你喜欢
    • 2018-07-10
    • 1970-01-01
    • 2023-03-19
    • 1970-01-01
    • 1970-01-01
    • 2015-12-25
    • 1970-01-01
    • 2015-07-25
    • 1970-01-01
    相关资源
    最近更新 更多