[host2]$ ./iperf3 -c host1 -i 5 -t 1000
...
[  5]   0.00-5.00   sec   983 MBytes  1.65 Gbits/sec  31545   2.49 MBytes      
[  5]   5.00-10.00  sec   839 MBytes  1.41 Gbits/sec  35645    889 KBytes      
[  5]  10.00-15.00  sec   830 MBytes  1.39 Gbits/sec  35863    954 KBytes
...
可以看到大概也就是1.4Gbps(175MBps)左右，和 grpc的測試結(jié)果差不多 。

為什么會這樣呢？事實上，當(dāng)提高socket數(shù)后，結(jié)果就會大大改觀，總的傳輸速率會達(dá)到9.3 Gbps左右，從而和理論值接近：

[host2]$ ./iperf3 -c host1 -i 5 -t 1000 -P 8
...
[  5]  40.00-45.00  sec   621 MBytes  1.04 Gbits/sec  9936   2.06 MBytes      
....
[ 19]  40.00-45.00  sec   206 MBytes   346 Mbits/sec  922   90.5 KBytes      
[SUM]  40.00-45.00  sec  5.43 GBytes  9.33 Gbits/sec  33646
這里我們可以看到的一個結(jié)論是： 單個socket可能(遠(yuǎn)遠(yuǎn))無法用滿網(wǎng)卡的帶寬 。

那么如果把grpc的socket數(shù)增加如何？遺憾的是，目前grpc還不支持這樣的特性。在grpc里，通信是用 channel 來進(jìn)行抽象的。 哪怕你在兩個機(jī)器間創(chuàng)建多個channel, 他們在底層也是會共享socket的 。

4. 單個socket用不滿網(wǎng)卡？

當(dāng)我通過測試得出這個結(jié)論時，我內(nèi)心也是無法接受的。我嘗試了

手動調(diào)整擁塞窗口(事實上也沒有必要，因為TCP會自發(fā)的增大它；穩(wěn)定后的擁塞窗口大小，也沒有達(dá)到Linux的上限)。

關(guān)閉Nagel算法
傳輸速率仍然沒有變化。

后來在組里boss的建議下，我換了兩臺機(jī)器做測試。發(fā)現(xiàn)對于不同的機(jī)器組合，單socket的傳輸性能是不同的。 也存在一些機(jī)器，他們的單socket性能是可以達(dá)到網(wǎng)卡理論上限的 。

對于這一問題，現(xiàn)在懷疑可能和網(wǎng)絡(luò)布局以及中間的交換機(jī)有關(guān)系。但具體的根源究竟是什么，還無從得知。

5. 繼續(xù)測試

在我換了 單socket可以打滿帶寬 的兩臺機(jī)器后，我把1和2中的實驗使用相同的參數(shù)重新做了一遍。結(jié)論如下：

grpc在單server單client的前提下，網(wǎng)卡傳輸?shù)睦寐蔬€是非常高的。在我的實驗中大概能到9Gbps左右，比iperf的結(jié)果稍遜一點，目測也就是5%左右。這可能和grpc在數(shù)據(jù)傳輸時的一些數(shù)據(jù)結(jié)構(gòu)的分配、處理有關(guān)，但整理來說grpc性能已經(jīng)比較可觀了。

對于傳輸tensor的測試而言，傳輸速率大概能到5Gbps左右，是裸grpc的一多半。

這里有兩個問題：

1. 為什么 傳輸tensor 的吞吐要低于 裸的grpc傳輸 ，問題在哪里？

2. 在我們最開始的兩個實驗中，由于單socket極限帶寬較低，這二者的傳輸效率類似。為什么提高單socket的極限帶寬后，二者開始體現(xiàn)出差別來？

其實這兩個問題并不難解釋：

在傳輸tensor時，除了有效的傳輸數(shù)據(jù)外，還有master驅(qū)動worker運行、序列化、反序列化、數(shù)據(jù)assign等其他操作。而我們測試看到的throughput，是把這些操作都當(dāng)成 有效傳輸 而平均化后的一個結(jié)果。

兩個機(jī)器間帶寬越高，額外操作的占比就越大，對總throughput的影響就越大。

6. 驗證假設(shè)

為了驗證我們的假設(shè)，我們需要知道 tensorflow在傳輸tensor時，真正用于數(shù)據(jù)傳輸?shù)臅r間是多少 ，從而可以根據(jù)數(shù)據(jù)量大致推算一下傳輸時的網(wǎng)絡(luò)帶寬。

可以先用timeline看一下每一步所有op的耗時，以及RecvTensor這個op的耗時。

run_options = tf.RunOptions(trace_level=tf.RunOptions.FULL_TRACE)
run_metadata = tf.RunMetadata()
sess.run(add_op.op, options=run_options, run_metadata=run_metadata)

trace = timeline.Timeline(step_stats=run_metadata.step_stats)
trace_file = open('timeline.ctf.json', 'w')
trace_file.write(trace.generate_chrome_trace_format())
結(jié)果(dur表示op的耗時，單位為us)：

{
    "name": "RecvTensor",
...
    "dur": 183311
},
....
{
    "name": "Assign",
...
    "dur": 19925
}
耗時主要在RecvTensor和Assign上，總耗時有200ms左右。對于100M數(shù)據(jù)而言，這個耗時也和觀察到的5Gbps的吞吐大致吻合。