等待/異步或SocketAsyncEventArgs？

所以我已經寫了一個帶有SocketAsyncEventArgs和socket的tcp-server。***異步方法。但我喜歡使用Stream.ReadAsync和Stream.WriteAsync方法編寫代碼的await/async方式。等待/異步或SocketAsyncEventArgs？

是否有任何不同的性能/內存明智，或者我只是在語法上有所不同？

來源

2013-02-13 Robin Heggelund Hansen

使用SocketAsyncEventArgs API的唯一好理由是用於非常高流量/低延遲的服務器，以減少GC必須執行的工作量。我通常不會考慮使用它，除非我使用其他API看到可測量的內存問題。也就是說，我相信Stephen Toub在SocketAsyncEventArgs API的async/await周圍創建了一些包裝。我會挖掘一個鏈接。 – spender 2013-02-13 15:30:43

多田！：http://blogs.msdn.com/b/pfxteam/archive/2011/12/15/10248293.aspx – spender 2013-02-13 15:32:05

順便說一句，我建議不要使用SocketAsyncEventArgs API的原因是由於圍繞SocketAsyncEventArgs池的複雜性增加MS推薦的實例。它使相當醜陋的閱讀......爲了給你一種性能衡量標準，我們使用Stream API運行具有〜10000個永久連接客戶端的服務器，而不會有任何問題。 – spender 2013-02-13 15:40:54

使用socketasynceventargs的優點是減少垃圾收集器的壓力並保持套接字的緩衝區分組以防止內存不足異常。

通過使用SocketAsyncEventArgs池，可以消除爲每次讀取和寫入調用創建和收集IAsyncResult的需求。其次，每個SocketAsyncEventArgs可以分配一個大字節[]塊的一部分。這可以防止內存碎片，這有助於減少內存佔用。儘管在技術上也可以用Begin/End調用來完成，但使用自己的緩衝區爲每個SocketAsyncEventArgs分配一個塊，而不是每次使用Begin/End方法調用讀取或寫入時都要分配一個塊更容易。

可能很重要的最後一個區別是根據MSDN庫，在套接字緩衝區已滿時，開始/結束髮送方法可能會阻塞。 SocketAsyncEventArgs不會阻塞，而是隻根據套接字緩衝區中的空間量寫入一定數量的字節，回調將指定寫入的字節量。

除非是邊緣情況，否則其優點並不明顯。除非遇到指定的任何一個問題，否則我建議您選擇最舒適和可維護的設備。

來源

2013-03-08 07:46:46

等待/異步或SocketAsyncEventArgs？

回答

相關問題