同步VS. .NET中的异步套接字性能

Question

我在.NET中读到的关于套接字的一切都说异步模式提供了更好的性能（特别是使用新的SocketAsyncEventArgs可以节省分配）。

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

但在我的应用程序中，我是客户端，我只需要通过一个tcp连接收听一个服务器发送市场价格数据。 现在，我创建一个单独的线程，将优先级设置为Highest，并使用它调用Socket.Receive（）。 我的线程阻止此调用，并在新数据到达后唤醒。

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

1. 线程池线程将具有默认优先级，因此看起来它们将严格地比具有最高优先级的我自己的线程更糟糕。

2. 我仍然需要在某个时刻通过单个线程发送所有内容。 假设我几乎同时在N个不同的线程池线程上得到N个回调，通知我有新数据。 它们提供的N字节数组无法在线程池线程上处理，因为无法保证它们代表N个唯一的市场数据消息，因为TCP是基于流的。 我将不得不锁定并将字节放入数组中，并发出一些其他线程的信号，这些线程可以处理数组中的内容。 所以我不确定N线程池线程是什么让我买。

我在想这个错吗？ 是否有理由在我的特定情况下使用Async模式连接到一个服务器的一个客户端？

更新：

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

但问题仍然是一样的。 是否有任何理由在我特定的情况下回调会更好，我是客户端并且只连接到一台服务器。

Answer 1

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

假设我几乎同时在N个不同的线程池线程上得到N个回调，通知我有新数据。

为什么会发生这种情况？ 如果你有一个套接字，你可以在它上面Begin操作来接收数据，完成后你只需要一个回调。 然后，您决定是否进行其他操作。 这听起来像是你过于复杂，尽管我可能会过度简化你想要做的事情。

总而言之，我会说：选择最简单的编程模型，让你得到你想要的东西; 考虑到您的场景中可用的选择，无论您选择哪一个，他们都不太可能对性能产生任何明显的差异。 使用阻塞模型，你“浪费”一个可以做一些真正工作的线程，但是嘿......也许你没有任何真正的工作要做。

Answer 2

性能的第一条规则只是在必要时尝试改进它。

我看到你提到标准，但从未提及问题，如果你没有，那么你不必担心标准所说的。

Answer 3

“该课程专为需要高性能的网络服务器应用而设计。 ”

据我所知，您是客户在这里，只有一个单一的连接。
此连接上的数据按顺序到达，由单个线程使用。

如果您在不同的线程上接收少量数据，那么您可能会失去性能，这样您以后就可以以序列化的方式组装它们 - 从而像单线程一样 。
关于什么都没有。

---

你真的不需要加快速度，你可能不会。

但是，您可以做的是在收到工作单后将其分配给其他线程。 你不需要SocketAsyncEventArgs。 这可能会加快速度。

一如既往，衡量和衡量。
而且，仅仅因为你可以，它并不意味着你应该。
如果在可预见的未来表现足够，那么为何复杂化呢？