2013-02-13 209 views
2

所以我已经写了一个带有SocketAsyncEventArgs和socket的tcp-server。***异步方法。但我喜欢使用Stream.ReadAsyncStream.WriteAsync方法编写代码的await/async方式。等待/异步或SocketAsyncEventArgs?

是否有任何不同的性能/内存明智,或者我只是在语法上有所不同?

+2

使用SocketAsyncEventArgs API的唯一好理由是用于非常高流量/低延迟的服务器,以减少GC必须执行的工作量。我通常不会考虑使用它,除非我使用其他API看到可测量的内存问题。也就是说,我相信Stephen Toub在SocketAsyncEventArgs API的async/await周围创建了一些包装。我会挖掘一个链接。 – spender 2013-02-13 15:30:43

+6

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

+1

顺便说一句,我建议不要使用SocketAsyncEventArgs API的原因是由于围绕SocketAsyncEventArgs池的复杂性增加MS推荐的实例。它使相当丑陋的阅读......为了给你一种性能衡量标准,我们使用Stream API运行具有〜10000个永久连接客户端的服务器,而不会有任何问题。 – spender 2013-02-13 15:40:54

回答

2

使用socketasynceventargs的优点是减少垃圾收集器的压力并保持套接字的缓冲区分组以防止内存不足异常。

通过使用SocketAsyncEventArgs池,可以消除为每次读取和写入调用创建和收集IAsyncResult的需求。其次,每个SocketAsyncEventArgs可以分配一个大字节[]块的一部分。这可以防止内存碎片,这有助于减少内存占用。尽管在技术上也可以用Begin/End调用来完成,但使用自己的缓冲区为每个SocketAsyncEventArgs分配一个块,而不是每次使用Begin/End方法调用读取或写入时都要分配一个块更容易。

可能很重要的最后一个区别是根据MSDN库,在套接字缓冲区已满时,开始/结束发送方法可能会阻塞。 SocketAsyncEventArgs不会阻塞,而是只根据套接字缓冲区中的空间量写入一定数量的字节,回调将指定写入的字节量。

除非是边缘情况,否则其优点并不明显。除非遇到指定的任何一个问题,否则我建议您选择最舒适和可维护的设备。