c++ - UDP/TCP 服务器中监听器线程与工作线程的比率？

Question

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

1. 监听器线程将花费更多未安排的时间，因此将丢弃比可接受的更多的数据包

2. 由于只有 1 个线程在监听，大多数工作线程将没有任务可执行，因此大部分时间都在休眠

听众和 worker 之间的比例是多少？我如何确定这个比率？

Answer 1

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

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