使用java計算Tcp往返時間

當我使用10 Gig網絡接口從一個solaris m/c到另一個solaris m/c進行跟蹤路由時，它需要0.073 ms的40字節數據包。使用java計算Tcp往返時間

當我在java中做同樣的事情時間更長。即使經過10K迭代，時間也更長。可能是什麼原因？

的Java：發件人（摘錄）

Socket sendingSocket = new Socket(address, RECEIVER_PORT); 
sendingSocket.setTcpNoDelay(true); 
OutputStream outputStream = sendingSocket.getOutputStream(); 
byte[] msg = new byte[64]; // assume that it is populated. 
for (int i = 0; i < 10000; i++) { 
    long start = System.nanoTime(); 
    outputStream.write(msg,0,64); 
    outputStream.flush(); 

    inputStream.read(msg,0,64); // inputStream is initialized like outputstream 
    long end = System.nanoTime(); 
}

它需要較長的方式米利斯69和它甚至不取決於字節大小。即使我減少它說1個字節的數組，它仍然需要69毫秒。有何評論/建議？

其他觀察： 1. OutputStream.write和flush只需要6個micros。 2.同樣在接收和寫回的另一端TCPReceiver端，它只需要6個micros。

解決方案： 謝謝大家，你迴應了這個查詢。我發現這是由於套接字緩衝區大小造成的：

在solaris m/c上設置的默認緩衝區大小。

接收緩衝區大小49152

發送緩衝區的大小7552.

我增加了套接字緩衝區大小和性能幾乎一致的traceroute。

來源

2011-07-06 2sb

你不喜歡與喜歡。 ICMP和TCP是不同的協議。

如果要決定是否延遲是在你的代碼中，JVM，的Solaris TCP協議棧或網絡你就必須開始使用tcpdump/Wireshark的等

來源

2011-07-06 16:33:30

雖然我同意你的比較ICMP和TCP是兩種不同的東西，但65毫秒在TCP方面太過分了。 – 2sb

@ 2sb你也發送了更多的TCP數據，實際上幾乎是兩倍。 – EJP

@ 2sb：我同意 - 65毫米似乎不合理。這就是爲什麼我想從tcpdump開始，以幫助消除一些潛在的原因。 –

這可能是由於一些因素。對於初學者來說，建立TCP通道需要時間。在兩個端點之間必須發送幾個數據包來建立可靠的介質。 ICMP消息並非如此，它們僅僅是單個數據包。事實上，因爲您看到傳輸數據所花費的時間無關大小，所以您可能會認爲實際傳輸數據所需的時間量（您所談論的數據量非常小在任何情況下在10gig連接上）與建立信道所花費的時間相比是微不足道的。另外，與使用Java（字節碼語言）而不是像硬件上本地運行的C或C++之類的事實相比，完全有可能存在一些開銷。

來源

2011-07-06 16:34:04

雖然，建立連接（即打開套接字）並不在被測量的塊內。 –

那麼字節碼語言並不是那麼糟糕。如果Java可以添加65毫秒的延遲，那麼永遠不會使用它:) – 2sb

連接所花費的時間可能約爲20毫秒。您需要使用現有連接進行測試。

TCP堆棧通過內核很慢。在許多機器上大約需要50-100個。您可以使用內核旁路驅動程序/支持來持續減少這種情況。

來源

2011-07-06 16:42:19

是的，我沒有使用現有的連接。 5-100我們很好，但在我的情況下，它是驚人的65毫米，這太多了。 – 2sb

使用java計算Tcp往返時間

回答

相關問題