提升：多线程性能，线程/套接字的重用

Question

我将首先描述我的任务，然后在下面提出我的问题。

我正在尝试为我们的分布式DAQ系统实现“单线程一连接”方案。 在Linux平台上，我将Boost用于线程（thread_group），将ASIO用于套接字。

我们有320个联网的DAQ模块。 每0.25ms大约发送一次，其中大约一半将各自生成一个数据包（大小小于标准MTU）并发送到Linux服务器。 每个模块都有其到服务器上专用端口的长寿命TCP连接。 也就是说，服务器端应用程序在1Gbe NIC和8个CPU内核上运行320个线程，320 tcp同步接收器 。

320个线程不必对传入的数据进行任何计算-只需接收数据，生成并添加时间戳并将数据存储在线程拥有的内存中即可。 套接字都是同步的，因此没有传入数据的线程将被阻塞。 套接字在运行期间保持打开状态。

我们的要求是线程应以尽可能少的时间延迟读取它们各自的套接字连接 。 在阅读了有关C10K 和这篇文章之后， 我希望每个线程每秒都可以轻松地处理至少1K的MTU大小数据包。

我的问题是 ：我首先通过在服务器上激发时间同步数据来测试系统（不同套接字上的传入数据相隔不到几微秒）。 当数据包的数量非常少（少于10个）时，我发现线程时间戳间隔了几微秒。 但是，如果多于10个，则时间戳会传播多达0.7秒。

我的问题是：

1. 我是否完全误解了C10K问题并弄乱了实现方式？ 320确实比C10K显得微不足道
2. 关于出什么问题的任何提示吗？
3. 真的可以重用线程和/或套接字吗？ （我真的不知道如何在我的情况下实现重用，因此不胜感激。）

Answer 1

320个线程在资源方面是笨拙的变化，但是调度可能会带来问题。

320 * 0.25 =每秒80个请求，这意味着至少有80个上下文切换，因为您决定必须在线程上建立每个连接。

我只是建议：不要这样做。 众所周知，每个连接线程不会扩展。 而且，几乎总是意味着在任何共享资源上进一步锁定争用（假设所有响应都不是完全无状态的）。

---

问：阅读了C10K和这篇文章后，我希望每个线程每秒都可以轻松地处理至少1K的MTU大小数据包

是。 一个线程可以轻松地维持这一点（在大多数系统上）。 但是 ，显然，如果您有数百个尝试相同的线程竞争物理内核，那就不再是事实。

因此，要获得最大的吞吐量和较低的延迟，拥有可用线程（！）的物理核几乎没有用。

---

问：这真的可以重用线程和/或套接字吗？ （我真的不知道如何在我的情况下实现重用，因此不胜感激。）

好消息是，Boost Asio使使用单个线程（或有限的线程池）非常容易地从其服务队列中服务异步任务。

也就是说，假设您已经使用了ASIO API函数的*_async版本。

我认为绝大多数（如果不是全部）异步IO的Boost Asio示例说明了如何仅在有限数量的线程上运行服务。

• http://www.boost.org/doc/libs/1_57_0/doc/html/boost_asio/examples.html