.NET池的IAsyncResult對象

讀通過SendAsync的Socket小號BeginAsync方法的說明，我意識到，有人建議集中SocketAsyncEventArgs實例說，這是比BeginXX更好，因爲每次調用EndXX異步的方式創建一個IAsyncResult實例。.NET池的IAsyncResult對象

我認爲這是不是一個很好的做法，可以輕鬆實例化對象（如SocketAsyncEventArgs）。對象分配速度非常快，並且GC已經過優化，可以有效處理短暫的生命體。我嘗試過實現一個池化機制來查看它是如何執行的，實際上，對於簡單對象來說，分配速度更快，而這些對象只是將某些數據封裝在ctor中。（好吧，它就像發送數十萬條數據庫來分析DBMS一樣，這就是爲什麼我在這裏。）

我不是問哪個更好，我相信分析實際應用程序會產生答案，但只是好奇關於彙集簡單的短暫生命物體的好處。更好的GC性能？低內存碎片？設計期間是否值得考慮？

從MSDN

這些增強的主要特點是重複分配和對象的同步的高容量異步套接字I/O過程中避免。當前實現的開始/結束設計模式由System.Net.Sockets.Socket類要求爲每個異步套接字操作分配一個System.IAsyncResult對象。

在新System.Net.Sockets.Socket 級增強，異步插座操作由可重複使用的描述的SocketAsyncEventArgs由應用對象分配和維護。高性能套接字應用程序知道最好的數量重疊套接字操作必須持續。應用程序可以創建與需要的 SocketAsyncEventArgs對象的許多對象。例如，如果一個服務器應用程序需要有15個插座接受所有次行動的未繳支持傳入的客戶端連接速率，它可以分配15周可重用的SocketAsyncEventArgs用於這一目的對象。

謝謝。

來源

2010-02-27 Ekin Koc

你從哪裏閱讀了這個建議？ MSDN？你能鏈接嗎？其次，你在處理什麼樣的套接字代碼？它會成爲許多客戶或一些擁有大量數據的客戶。就個人而言，我會避免增加額外的複雜性，除非明確要求，並且在許多應用程序池中不值得。 – 2010-02-27 14:51:43

@dr。邪惡添加了參考。大約100個客戶端發送3-5個小包/秒。我還爲每個數據包創建「消息」對象，所以我想知道是否應該將它們集中起來。 – 2010-02-27 14:58:28

我認爲你會比100個客戶端更好，每秒3-5個數據包。我不認爲你需要集中消息（只要確保它正確處理）。在不影響性能的情況下，.NET內存管理可以處理更多的事情。 – 2010-02-27 15:03:05

IAsyncResult接口包括類型爲WaitHandle的AsyncWaitHandle屬性。 A WaitHandle消耗操作系統資源。

實際上，WaitHandle實現了IDisposable接口，所以實現IAsyncResult的類本身應該自己實現IDisposable。

這是所有說，數百名IAsyncResult實例躺在身邊的是不是一個內存問題 - 這是一個資源問題。新的套接字調用擺脫了對數百個物體的需求。

來源

2010-02-27 16:59:55

沒有過期策略的緩存是內存泄漏。你的問題中沒有什麼表明你已經考慮過一個好的政策。如果你沒有一個，那麼不要使用緩存。如果你確實做了測試，看看你是否可以衡量實際的改進。

來源

2010-02-27 16:25:08

.NET池的IAsyncResult對象

回答

相關問題