使用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()，並生成更小的消息塊。