UDP / TCP服务器中侦听器线程与工作线程的比率？答案

【问题标题】：Ratio of listener threads to worker threads in UDP/TCP server?UDP / TCP服务器中侦听器线程与工作线程的比率？
【发布时间】：2015-08-06 06:37:06
【问题描述】：

我正在编写一个同时处理 UDP 和 TCP 连接的服务器，并编写了一个作为服务器基础的基本线程池库。我有一个侦听器线程，它执行系统调用的accept/recvfrom（分别用于TCP和UDP）并将任务推送到线程池，但我认为n个工作线程的一个侦听器线程不会很好地执行，因为n增加超过50或60线程。例如，如果我有一个实例化的 UDP 服务器，它有 60 个工作线程和一个执行 recvfrom 的侦听器线程。如果处理器需要在所有这些线程之间进行上下文切换，我担心的是 -

侦听器线程将花费更多时间计划外，因此将丢弃比可接受的更多数据包
由于只有 1 个线程正在侦听，因此大多数工作线程将没有要执行的任务，因此大部分时间都在休眠

听众和工人的比例是多少？我如何确定这个比率？

【问题讨论】：

“听众和工人的比例是多少？” 抱歉，没有现成的公式。这完全取决于您的实际用例、部署和要求。
修正了我的问题。我以为没有公式。但是，我不知道如何确定这个比率。
“监听线程”到底是什么意思？一个调用accept() 来监听传入连接的线程？还是一个线程来监听来自已连接客户端的数据？
前者，在 TCP 和 UDP 的情况下，侦听器调用 recvfrom 并将结果数据推送到线程池
一个技巧就是让监听线程以比消费者更高的调度程序优先级运行，因此它总是抢占他们

标签： c++ multithreading sockets networking

【解决方案1】：

您所描述的是Thundering Herd Problem 的变体。对于更大数量的连接，N:N 模型（每个请求一个工作人员）确实会因为上下文切换而开始崩溃。许多应用程序所做的是使用 M:N 模型，其中 M 是请求数，N 是 CPU 数。大约启动 N 个工作线程来处理请求，并且根据线程所做的 CPU 与 I/O 工作量以及系统上运行的其他进程，工作线程的数量可以分别增加到 N 以上或 N 以下。

scheduler in TBB 是用于高 CPU 工作进程的一个非常好的调度程序实现。它还考虑了缓存亲和性。即使只是为了想法，也值得一看。

【讨论】：

另一个值得考虑的优秀工具集是IOCP facilities of Windows。它们需要大量的工作和理解才能正确设置，但一旦完成，它们在内核级阻塞检测和线程资源管理方面具有巨大优势。在几乎任何 IO api 上调用阻塞调用都会使当前线程处于运行但等待状态，从而推动 IOCP 池管理器针对当前待处理的工作负载释放另一个线程。如果 Windows 是目标平台，值得一看。