我很难理解我必须做的数学运算，才能根据我的基础架构找出正确的 RAILS_MAX_THREADS 数量。
我正在使用多个容器来托管我的一份接受 HTTP 请求的 API 副本和一份运行 sidekiq（作业处理）的 API 副本。我正在使用的数据库的 max_connections 为 45。话虽如此，RAILS_MAX_THREADS 的数量应该是多少？我将 9 用于 RAILS_MAX_THREADS 和 WEB_CONCURRENCY。我读了几篇关于它的文章，但我无法完全理解它。
【问题讨论】：
标签： mysql ruby-on-rails connection-pooling puma
即使您没有使用 Heroku，Heroku 关于 puma 大小的文档也是最好的。
https://devcenter.heroku.com/articles/deploying-rails-applications-with-the-puma-web-server
在他们说“dyno”的地方，对于非 Heroku 部署，您可以只阅读“主机”、“虚拟机”或“容器”。
如果您将 9 用于 RAILS_MAX_THREADS 和 WEB_CONCURRENCY，并且您的 heroku 配置设置为以正常方式使用这些设置 - 那么每台主机将有 9 个 puma worker 运行（ WEB_CONCURRENCY)，每个工作线程将运行 9 个线程 (RAILS_MAX_THREADS)，总共 9*9=81 个线程。
您确实需要为每个线程提供足够的数据库连接，因此您的 45 个数据库连接已经增加了近 2 倍。这只是在一个容器上——如果你正在运行多个容器，每个容器都有这些设置，而不是用 81 乘以容器的数量——所以这对于你的数据库连接来说太多了！
因此，如果您无法更改最大数据库连接数，这是一个硬限制，您需要减少数量。
否则，主要限制因素是每个容器中有多少可用 RAM，以及有多少 vCPU。理想情况下，您在容器 (WEB_CONCURRENCY) 上运行的工作人员至少与拥有 vCPU 的数量一样多——如果您有足够的 RAM 来执行此操作。工人占用大量内存。通常没有理由运行比 vCPU 更多的工作程序，因此 9 是否有意义或大于所需取决于您的基础架构。
每个工作线程有多少线程 (RAILS_MAX_THREADS) 是最佳的，这取决于您的应用正在做什么，但作为一个好的经验法则，您可以从 5 开始。一般来说，9 可能比有用的多。
所以我会尝试 3-5 的 RAILS_MAX_THREADS。然后尽可能多的 WEB_CONCURRENCY 而不用完 RAM（要查看应用程序在负载下运行一段时间后将占用多少 RAM，您可能需要让它在负载下运行一段时间）。只要容器 * RAILS_MAX_THREADS * WEB_CONCURRENCY 小于您的数据库最大连接数 - 如果不是，请减少您的值，或者增加您的数据库最大连接数。
【讨论】：