使用ReplayingDecoder的大消息

Question

我在两个Java进程之间建立了连接，双方都使用Netty。解码端使用ReplayingDecoder并使用它来反序列化更复杂的消息类型。

大部分消息都很小。不过，我今天发现了一个性能问题，它发生的消息很少（〜4MB），而这种消息很少出现。

我已经猜到下面

• 的消息并不需要是4MB，我可以让他们更小
• ReplayingDecoder可能是不适合处理像这样大的消息是最好的选择，没有一些那种长头的节约解析一遍又一遍

这且不说我是不确定的，为什么它是如此缓慢。我花了好几分钟让信息从一边传到另一边。

的写操作如下

• 创建动态缓冲区
• 写整个消息缓冲
• 呼叫channel.write（）一旦与缓冲

这似乎是相当快的（观察未来何时完成）。该消息大小约为4MB。

寻找在解码端，我可以看到它击中我的处理程序它试图解析东西每隔几秒钟，罚球，回放，等待更多的数据等

但是我只看到了缓冲区大小指示每次处理程序被调用时（每秒钟左右），可用数据增加50k左右。我会希望缓冲区填充比这更快。

我在本地网络上，实际上在同一台机器上使用环回地址连接网络速度的两个进程不应该是主要因素。

这是预期的行为？我的重复解析过程是否会阻塞处理程序以及任何与其运行时序列化的处理程序，并且可能会像我预期的那样快速填充缓冲区？

我使用了Netty 3.1.1.GA（很老了，可升级测试，如果事情可能已经改善这一点）

任何更多的信息，我可以提供或地方进一步调试，请让我知道。

Answer 1

根据ReplayingDecoder Java文档

“如果网络速度慢，消息格式是复杂的性能可能会更糟。您的解码器可能不得不一遍又一遍的消息的相同部分进行解码。”

为了避免这种情况，您必须保持使用检查点的解码状态。

您可以从这些求职者处获得更多信息ReplayingDecoder Java doc comments。

Answer 2

在Netty中查看HttpMessageDecoder源代码。你会发现你如何处理大量的内容。基本上，您可以按照Jestan的建议经常致电checkpoint()，并生成更小的消息块。