c# - 同步比。 .NET 中的异步套接字性能

Question

我读到的有关 .NET 套接字的所有内容都表明异步模式提供了更好的性能(尤其是使用新的 SocketAsyncEventArgs 可以节省分配)。

如果我们谈论的服务器有很多客户端连接，并且不可能为每个连接分配一个线程，我认为这是有道理的。然后我可以看到使用 ThreadPool 线程并在其上获取异步回调的优势。

但在我的应用程序中，我是客户端，我只需要收听一台服务器通过一个 tcp 连接发送市场报价数据。现在，我创建了一个线程，将优先级设置为最高，并用它调用 Socket.Receive()。我的线程阻塞在这个调用上，并在新数据到达时唤醒。

如果我将其切换为异步模式以便在有新数据时获得回调，我会看到两个问题

1. 线程池线程将具有默认优先级，因此它们似乎比我自己的具有最高优先级的线程更差。

2. 在某些时候，我仍然需要通过单个线程发送所有内容。假设我几乎同时在 N 个不同的线程池线程上收到 N 个回调，通知我有新数据。它们传送的 N 字节数组不能在线程池线程上处理，因为不能保证它们表示 N 个唯一的市场数据消息，因为 TCP 是基于流的。无论如何，我都必须锁定字节并将其放入数组中，并向其他可以处理数组中内容的线程发出信号。所以我不确定拥有 N 个线程池线程对我有什么好处。

我是不是想错了？在我的一个客户端连接到一台服务器的特定情况下，是否有理由使用异步模式？

更新:

所以我认为我误解了上面 (2) 中的异步模式。当有可用数据时，我会在一个工作线程上获得回调。然后我将开始另一个异步接收并获得另一个回调，等等。我不会同时获得 N 个回调。

问题还是一样。在我作为客户端且仅连接到一台服务器的特定情况下，回调会更好吗？

Answer 1

您的应用程序中最慢的部分将是网络通信。通过这样的调整，您很有可能对一个线程、一个连接客户端的性能几乎没有影响。网络通信本身将使所有其他对处理或上下文切换时间的贡献相形见绌。

Say that I get N callbacks at almost the same time on N different threadpool threads notifying me that there's new data.

为什么会这样？如果您有一个套接字，您可以在其上开始 一项操作以接收数据，并且在完成时您将得到一个回调。然后您决定是否进行另一项操作。听起来你把它过于复杂了，尽管关于你想做的事情，我可能把它过于简单化了。

总而言之，我会说:选择最简单的编程模型来满足您的需求；考虑到您的场景中可用的选择，无论您选择哪种选择，它们都不太可能对性能产生任何明显的影响。使用阻塞模型，您正在“浪费”一个本可以做一些实际工作的线程，但是嘿......也许您没有任何实际工作要做。