.NET 异步套接字 : any benefit of SocketAsyncEventArgs over Begin/End in this scenario?

Question

套接字有这些new async methods since .NET 3.5与 SocketAsyncEventArgs 一起使用(例如 Socket.SendAsync() )，好处在于它们使用 IO 完成端口并避免需要继续分配。

我们创建了一个名为 的类UdpStream 使用简单的界面 - 只需 StartSend 和 Completed 事件。它分配了两个 SocketAsyncEventArgs，一个用于发送，一个用于接收。 StartSend 只是使用 SendAsync 发送消息，每秒调用大约 10 次。我们在接收 SocketAsyncEventArgs 上使用 Completed 事件，每个事件处理完后我们都 ReceiveAsync 使其形成一个接收循环。同样，我们每秒接收大约 10 次。

我们的系统最多需要支持 500 这些 UdpStream 对象。换句话说，我们的服务器将与 500 个不同的 IP 端点同时通信。

我注意到在 MSDN SocketAsyncEventArgs 示例中，它们分配了 N x SocketAsyncEventArgs，一个用于您想要一次处理的每个未完成的接收操作。我不清楚这与我们的场景有什么关系——在我看来，也许我们没有得到 SocketAsyncEventArgs 的好处，因为我们只是为每个端点分配一个。如果我们最终收到 500 个接收 SocketAsyncEventArgs，我想我们不会得到任何好处。也许我们仍然可以从 IO 完成端口中获得一些好处？

这种设计是否正确使用了 SocketAsyncEventArgs 时
缩放到 500？

对于我们使用单个“UdpStream”的情况，是否存在
使用 SocketAsyncEventArgs 与使用旧的 Begin/End API 相比有什么好处？

Answer 1

it seems to me that perhaps we are not getting the benefit of SocketAsyncEventArgs because we are simply allocating one per endpoint. If we end up with 500 receive SocketAsyncEventArgs I am presuming we will get no benefit.

仍然有很大的好处。

如果您使用 APM 模式(开始/结束方法)，每个 BeginSend和每个 BeginReceive分配 IAsyncResult实例。这意味着每秒大约发生 10,000 次完整的类/对象分配(500*10 [发送] + 500*10 [接收])。这会给系统带来大量额外开销，因为它会增加大量 GC 压力。

切换到高性能网络应用程序的新建议方法，您将预先分配 SocketAsyncEventArgs实例 (500) 并将它们重用于每个方法调用，从而消除在这些操作期间产生的 GC 压力。