我有两个Java进程之间的连接，双方都使用Netty。解码端使用ReplayingDecoder并使用它来反序列化更复杂的消息类型。
大多数消息都很小。但是，我今天发现了较大的消息（~4MB）的性能问题，这种情况很少发生。
我已经推测了以下
除此之外，我不确定它为何如此缓慢。我花了好几分钟的时间将信息从一方传送到另一方。
写操作如下
这似乎相当快（观察未来何时完成）。消息大小约为4MB。
在解码方面，我可以看到它每隔几秒就会触及我的处理程序，它会尝试解析某些内容，抛出，重放，等待更多数据等。
然而，我只看到缓冲区大小，表明每次调用处理程序时每隔一秒左右，可用数据就会增加50k左右。我希望缓冲区的填充速度比这快得多。
我在本地网络上，实际上在同一台机器上使用环回地址连接到网络速度的两个进程不应该是一个主要因素。
这是预期的行为吗？我的重复解析过程是否会阻塞处理程序以及运行它的任何序列化的事情，并且可能会像我预期的那样快速填充缓冲区？
我正在使用Netty 3.1.1.GA（相当陈旧，可以升级以测试是否有可能改进了这一点）
我可以提供更多信息或进一步调试的地方请告诉我。
答案 0 :(得分：1)
根据ReplayingDecoder Java doc
“如果网络速度慢且消息格式复杂，性能会更差。您的解码器可能不得不一遍又一遍地解码消息的相同部分。”
为避免这种情况，您必须使用检查点维护解码状态。
您可以从ReplayingDecoder Java doc评论中获取更多信息。
答案 1 :(得分：0)
查看Netty中的HttpMessageDecoder源代码。您将了解如何处理大量内容。基本上，您可以像Jestan建议的那样频繁地呼叫checkpoint()，并生成较小的消息块。