套接字緩衝區大小：優點和缺點更大或更小

Question

我從來沒有真正使用過COM套接字，現在有一些代碼正在監聽相當穩定的數據流（500Kb/s - 2000Kb/s）。

我已經嘗試過不同的尺寸，但我不太確定自己在做什麼。

byte[] m_SocketBuffer = new byte[4048]; 
//vs 
byte[] m_SocketBuffer = new byte[8096]; 

套接字我使用的是System.Net.Sockets.Socket，這是我的構造函數：

​​

我的問題是：

1. 是否有一般貿易大型vs.小型緩衝區？
2. 如何確定緩衝區大小？你應該用什麼作爲衡量標準？

我檢索數據是這樣的：

string socketData = Encoding.ASCII.GetString(m_SocketBuffer, 0, iReceivedBytes) 
while (sData.Length > 0) 
{ //do stuff } 

是否當緩衝區滿我的閱讀事件發生？就像套接字緩衝區達到閾值時那樣，我什麼時候可以讀取它？

Answer 1

短版：

• 最佳緩衝區大小取決於很多因素，包括基礎網絡傳輸方式以及您自己的代碼處理I/O。
• 對於大容量服務器移動大量數據，K的10個字符可能是正確的。但是如果您知道遠程端點不會一次向您發送大量數據，則可以使用更小的端點。
• 緩衝區在I/O操作期間被固定，這會導致或加劇堆碎片。對於真正高容量的服務器，分配非常大的緩衝區（大於85,000字節）可能是有意義的，以便從大對象堆中分配緩衝區（該緩衝區沒有碎片問題，或處於永久狀態碎片，這取決於你如何看待它:)），然後使用每個大緩衝區的一部分用於任何給定的I/O操作。

回覆：您的具體問題：

1. 是否有一個一般的權衡與大小緩衝區？

也許最明顯的就是平常：一個緩衝區大於你永遠不會真正需要的只是浪費空間。

使緩衝區太小會強制執行更多的I/O操作，可能會強制執行更多的線程上下文切換（取決於您如何執行I/O），並且肯定會增加必須執行的程序語句的數量。

當然還有其他的折衷，但是對於這個論壇來說，每一個都會涉及太多的討論。

1. 如何確定緩衝區大小？你應該用什麼作爲衡量標準？

我會從一個看似「合理」的尺寸開始，然後從那裏進行實驗。在各種負載測試場景中調整緩衝區大小，增加和減少，看看是否會對性能產生影響。

1. 當緩衝區已滿時，我的閱讀事件是否發生？就像套接字緩衝區達到閾值時那樣，我什麼時候可以讀取它？

當您從套接字讀取，網絡層就會把儘可能多的數據到您的緩衝區，因爲它可以。如果有更多的數據可用，它將填充緩衝區。如果可用的數據少於將要填充的數據，則該操作將在沒有填充緩衝區的情況下完成（但總是當至少一個字節已被放入緩衝區中時）;只有當讀取操作以零長度完成時，連接正在進行關閉）