數據速率
你試圖移動800兆字節/秒。這是什麼樣的聯繫?對於運輸級的tcp://
,它必須非常快速,例如100 Gbit/s以太網,這是非常奇特的。
所以我假設它是一個ipc://
傳輸級連接。在這種情況下,您可以使用ZeroMQ zerocopy函數進行改進,從而節省了重複複製數據的時間。
正常傳輸時,必須將數據複製到zmq消息中,該消息必須複製到ipc
管道中,再次複製出來並複製回接收端的新zmq消息中。所有這些拷貝都需要4 x 800 = 2.4 GByte/sec的內存帶寬,在緩存衝突發揮作用時,這是典型PC系統總內存帶寬的一個相當大的百分比。使用zerocopy 應該減半。
替代零拷貝 - 零換乘
如果使用ipc://
,然後再考慮不通過套接字發送數據,而是通過套接字發送到數據的引用。
我以前混合使用ZMQ和旗語鎖定C++ stl::queue
,(在我的情況PUSH/PULL
)使用ZMQ簡單地爲它的模式,stl::queue
進行共享數據指針,並保留數據依然。發送方鎖定隊列,將共享指針放入隊列中,然後通過zmq套接字發送一條簡單消息(例如「1」)。收件人讀取「1」並將其用作提示來鎖定隊列並從中拉出共享指針。因此,通過stl::queue
以ZMQ模式將共享數據指針從一個線程轉移到另一個線程,但數據本身保持不變。我所做的只是在線程之間傳遞數據的所有權。只要發送完成後發送已經超出範圍的共享指針並且發件人未使用它來修改或訪問數據,它就會工作。
PUSH/PULL
不算太差處理 - 每條消息都只有一個收件人。需要花費更多的努力來與PUB/SUB
進行混合,並且接收到的消息必須被視爲只讀,因爲每個接收者將與其他人有相同的數據塊的共享指針。
郵件大小
我已經不知道我有多大塊zmqtp同時傳輸,但猜想,它在協議方面相對有效的:數據率。
@ user3666197,感謝您的精彩! – bazza