ZMQ Pub-Sub 延遲峰值

Question

我正在使用 ZMQ pub-sub 將消息從 C++ 程序傳遞到 Python 腳本。

我每秒傳遞大約 5000 條消息，它們的重量從 100 到 4500 字節不等，平均每條約 300 字節。 平均而言，我通過這個套接字每秒發送大約 2.5 兆字節的數據。

我的監控腳本是這樣工作的：

• 將 C++ 程序綁定到套接字並使其運行。
• 為 C++ 程序發出的每條消息添加一個時間戳。
• 啟動 python 腳本，連接到套接字，接收消息，獲取時間戳並減去 output 時間戳，獲取延遲測量值。
• 跟蹤滾動 x 條消息的平均延遲。

我的問題：當我啟動腳本時，套接字延遲徘徊在 200 微秒左右。 這在我的預料之內，而且似乎是正確的。 但是，1 分鍾后平均延遲約為 1.5 毫秒，4 分鍾后約為 10-15 毫秒，10 分鍾后穩定在 50 毫秒左右。 如果我重新啟動我的 Python 腳本，延遲會回到 200 微秒。 我不認為問題是消息積壓，因為如果是這種情況，延遲會不斷增加，偶爾也會減少，而不是以可預測的方式線性增加到某個閾值。

可能是什么問題？ 有沒有辦法更改 ZMQ 設置以嘗試改進它，或者查看它是否有一些內部積壓問題？

Answer 1

當您提到 50ms 時，我立即想到了 Nagle 算法。

但是，正如您所說的那樣，您在雙方都使用 ZMQ 並且默認情況下禁用 Nagle，那么我有點退縮了。

以下是調試的一些想法：

1. 使用strace <binary> args在 strace 下啟動 C++ 進程並查看日志，尤其是在套接字創建之后的日志。 檢查套接字上是否設置了TCP_NODELAY 。

2. 以管理員身份啟動 wireshark 並在您發布的界面上進行捕獲。 按照給定的 TCP stream並嘗試檢查明顯的錯誤（例如重傳）和模式。