PUMA工人vs单独的ec2实例

在Puma的上下文中，工作程序和线程都用于实现并发性，因此Puma可以处理请求，而不必始终等待先前的请求完成。一个好的配置将需要在工作程序和线程的数量之间找到一个良好的平衡，并且需要考虑已部署应用程序的多个方面：

• 工作人员：

  • 由于每个分叉的进程都需要自己的内存，因此具有更大的内存开销（由于（https://en.wikipedia.org/wiki/Copy-on-write，因此在Linux上可以缓解这种情况，但这仍然是一个因素）
  • 当多个内核可用时，允许并行化。当处理请求的计算量很大时，这是一个主要问题-可以避免的事情-如果请求需要执行一些繁重的计算，最好使用（（https://github.com/ mperham / sidekiq）
  • 无法在JRuby上使用，因为它不支持分支

• 线程数

  • 将为每个辅助进程运行已配置的线程数量-这意味着如果有workers x，threads y则将获得总计x * y请求处理线程
  • 共享内存，因此它们的内存占用空间较小（即使这里也有陷阱：（https://www.speedshop.co/2017/12/04/malloc-doubles-ruby-memory.html）
  • 在MRI（这是默认的Ruby实现）上，由于GIL，线程不允许并行执行Ruby代码-这应该不是一个大问题，因为在等待大量执行的IO等待期间，GIL没有锁定将花费时间-访问数据库，与API通信等。
  • 在JRUBY上，线程可以实现并行性。
  • 如果您的应用不是线程安全的，则无法使用。Rails本身是线程安全的，但是您不能保证应用程序依赖于任何3d方代码或应用程序代码本身。如果应用程序不是线程安全的，那么答案很简单-不要使用线程（这意味着将最小和最大线程配置为1）。缺乏线程安全性是一种情况，即使在单个核心实例上，多工作者配置也是有意义的。
  • 对于任何数量的线程，您都需要确保连接池中有足够的数据库连接。这通常意味着将Rails连接池大小设置为您在工作进程中运行的线程数。

将多个工作程序与部署到多个EC2实例进行比较时，遗漏了一部分图景：将Puma与多个工作程序一起使用时，有一个主Puma进程在端口上侦听并将每个请求路由到可用的工作进程。当您有多个EC2实例时，则需要以某种方式照顾它们之间的负载平衡-对于可能是ELB或ALB的AWS而言。部署到多个实例和负载平衡是以任何方式部署任何严重的Web应用程序的正确方法，但这不应该阻止您通过辅助线程和线程更好地利用实例资源。

我建议尝试配置工作程序和线程，并开始将工作程序的核心和线程数设置为10-然后在遇到内存使用问题或资源利用率不足时进行调整。