實現高效能穩定的socket tcp通訊經驗分享

其實在.net socket編寫高效能穩定方面的資料真的比較少,乙個實質性的測試資料結果對比就更少了.我們可以從看到ms說net 2.0 sp1後的socket通訊能力非常強勁,可以同時掛起6w個io(可以簡單地認為可以在一秒內send+receive可以達到6w或更高),但要找這個資料的測試似乎很難.但在一篇ms關於wcf的效能測試中基於tcp部署的效能在一台4路伺服器中可以達到這個量(那wcf可以達到那基於c# socket實現達到這樣的io處理能力應該完成沒問題.經常一段時間的努力即使在一台core e4300 5年前的pc上完全勝任每秒6w io的處理能力,還包括資料接收,協議分析對像序列化寫入.

以下是一些經驗總結:

buffer pool

這個相信不用說,msdn上也介紹這種用法.但如何分配這個buffer大小呢?我們一般會一條訊息用乙個buffer,這個時候我們就很難分配了,不得不按最大訊息長度來定義buffer長度,這樣做從記憶體分配上來說是極其不合理的.不過現在記憶體多不用計較(也許).但還存在一種問題就是send的時候一般針對buffer的,當訊息小的時候就不得不按訊息的數量來操作io,如果buffer的靈活性更好如小的訊息可以多個寫入乙個buffer,大的訊息可以寫入幾個buffer.這樣即能達到記憶體使用合理.也能控制最少的io處理最多的資訊達到更好的效能.

socketasynceventargs池需要嗎?

這個msdn上也有介紹這種用法,但就存在乙個如何分配的問題,連線產生的時候分配,連線斷開的時候**?如果是這個saea怎樣分配buffer大小(別輕易地使用setbuffer(byte,int,int)方法);不得不面對以上buffer說的問題.所以seae和buffer pool一樣大小來分配池結合使用,用的時候拿用完**到池. 其實seae最好是和buffer整合在一起,這樣做的好處就是在高併發的時候可以節省大量的byte copy.

佇列的使用

佇列的使用就是更好控制線程處理資料,既然乙個執行緒就能更好地完成工作,可必要用更多的執行緒去做呢.記住用最少的執行緒完成最多的事情.

在執行期內你能做到最少化記憶體分配嗎?

你能讓一些getbyes方法不產生new byte嗎?好好看下msdn相關對像方法看有什麼途徑來達到這種效果.

不於過於自信多用些分析工具

也許你有著很多年的經驗,也用一些計時器來衡量過**的執行行效能.但有時候你真的很難發現原來效能並不存在於你測的地方.不要只關注於**的cpu執行時間,別忘了.net下還有乙個巨頭gc.用效能分析工具分析**的執行時間同時,不要忘了分析一下**在某些情況下的記憶體分配情況.vs2010就提供了這些方便的分析工具.

以下是這段時間優化的測試情況

測試結果一:

1k連線分別獲取乙個對像和乙個列表對像

單一對像資訊

class getresponse : imessage
class user : imessage
public void load(bufferreader reader)
}

列表對像資訊(5條)

class response : imessage}}
class order : imessage
public void load(bufferreader reader)
}

測試結果

測試結果2:

由於區域網頻寬限制,所以只能測試2k和3k連線下的單一物件獲取

除了以上測試結果外,還進行了同場景500物體狀態變更廣播,在core e4300也完全能勝任,每秒**50w的訊息量.每個client的訊息延時在100ms以內.

同場景物體廣播測試程式: (想測試效果請分開電腦執行,如果你的網路是100mb的話最大只能執行5個client,如果伺服器的cpu低於core e4300也有可能支援不了500同屏)

實現高效能穩定的socket tcp通訊經驗分享

高效能穩定可靠的記憶體加密

構建穩定高效能團隊的思考

穩定高併發高效能程式設計原則簡單總結

實現高效能穩定的socket tcp通訊經驗分享

高效能穩定可靠的記憶體加密

構建穩定高效能團隊的思考

穩定高併發高效能程式設計原則簡單總結

相關推薦