Nginx 的 CPU 可扩展性方法（每个进程 epoll 事件队列）是最佳的吗？

Question

Nginx 的 CPU 可扩展性方法基于创建几乎独立的进程数量，每个进程拥有一个事件队列，然后使用 SO_REUSEPORT 将传入连接、IRQ、NIC 数据包相对均匀地分布在所有内核上。

与只创建一个 Linux 进程然后创建仍然等于 CPU 数量和每个线程中的每个线程事件队列的线程数组相比，它是否会带来更好的可扩展性（更少的内核数据共享 = 更少的锁）？

这是 Nginx 扩展到大约 32 个 CPU 的示例。禁用 HT 和 36 个真实内核的总数可能是造成这种情况的主要原因，以及由于过热导致相对 NIC 饱和甚至内核 GHz 下降：

Answer 1

所以看起来我们可以通过比较 Nginx 和 Envoy Proxy 来获得硬数据来回答这个问题，因为它使用了你感兴趣的架构：

Envoy 采用单进程多线程架构。单个主线程控制各种零星的协调任务，同时一定数量的工作线程执行监听、过滤和转发

虽然它们最初是为了解决不同的问题而开发的，但目前它们具有极其相似的功能，并且经常被相互比较。

通过这样的比较，Envoy 显示出更好的吞吐量和延迟。另一个比较是Ambassador（基于 Envoy）与 Nginx，Envoy 再次显示出更好的结果。

鉴于这些数据，我想说的是，单进程、事件循环和线程池模型 (Envoy) 似乎比具有共享 IPC 模型 (Nginx) 的多进程具有更好的扩展性。