使用 Puma 的 Worker、线程和池大小

Posted 2023-02-16

【中文标题】使用 Puma 的 Worker、线程和池大小

【英文标题】：Worker, Threads & Pool size using Puma

【发布时间】：2015-04-01 08:52:17

【问题描述】：

如果我有一个 1 核的服务器，有多少 puma 工作线程、线程以及什么数据库池大小是合适的？

这里的一般拇指是什么？

【参考方案1】：

不是一个简单的答案。

两个主要的信息来源是：

Puma github repository（作者观点） Heroku's web page（主要大用户观点）

不幸的是，它们不一致主要是因为 heroku 具有不同的部署指标和术语。

所以我最终遵循了 puma 存储库指南，其中说：

每个核心一个工人 要根据 RAM 可用性和应用程序来确定线程和 线程 = 连接池

所以线程数大多是try and check操作。

【讨论】：

“每个核心一个工人”的指导方针被抛出了很多，但这基本上与 Heroku 所说的相反（他们将 RAM 列为工人的唯一限制因素，并建议线程应该绑定到可用的处理器）。有没有人就此给出最终决定？直觉上，Heroku 的版本对我来说更有意义。

据我了解，Puma 工作人员的真正好处是并行性，因为它们是独立的 ruby​​ 进程。如果你只有 1 个核心，那么真的没有理由使用超过 1 个 worker，因为它们不能并行运行。也就是说，即使在单核环境中，Heroku 也可能发现了使用多个 worker 的其他一些效率改进。

在单核环境中，我注意到多进程存在很大延迟。

昨天在一个 Heroku 免费测功机上测试了我的应用程序。发送的 100 个请求给出了结果：1 个线程，3 个工作人员 => 中等请求时间：1000 毫秒。 3 个线程，1 个工作人员 => 中等请求时间：3400 毫秒。所以在heroku上，我至少会在更便宜的测功机上争取更多的工人和更少的线程。当然，最好是对您的特定应用进行负载测试。

根据我的个人经验，每个核心 1 个工人是不够的：我建议每个核心 1.5 或 2 个工人。否则当 Ruby 进程在 I/O 或类似情况下被阻塞时，你会浪费一些 CPU。