【发布时间】：2014-02-27 02:51:22
【问题描述】：
我正在尝试扩展应用服务器以每分钟处理超过 20,000 个请求。
当我对请求进行压力测试时，大多数请求都能轻松处理 20,000 RPM 或更多。
但是，需要发出外部 HTTP 请求的请求（例如，Facebook 登录）会使服务器陷入爬行状态（3,000 RPM）。
我从概念上理解我当前环境的局限性——3 个负载平衡的服务器，每台服务器有 4 个独角兽工作者，一次只能处理 12 个请求，即使它们都在等待 HTTP 请求。
我有哪些选择可以更好地扩展它？我想一次处理更多的连接。
据我所知可能的解决方案：
蛮力：使用更多的独角兽工作者（即更多的 RAM）和更多的服务器。
将所有阻塞操作推入后台/工作进程以释放 Web 进程。客户需要定期轮询以了解他们的请求何时完成。
移到 Puma 而不是 Unicorn（可能从 MRI 移到 Rubinius），这样我就可以使用线程而不是进程——这可能（？？）提高每个连接的内存使用率，因此允许增加工人。
从根本上说，我正在寻找的是：有没有更好的方法来增加单个工作人员可以处理的阻塞/排队请求的数量，以便我可以增加每台服务器的连接数？
例如，我听说过将 Thin 与 EventMachine 结合使用的讨论。这是否开启了 Rails 工作人员可以放下当前正在处理的 Web 请求（因为该工作人员正在外部服务器上等待）然后在等待时接收另一个请求的可能性？如果是这样，与独角兽和彪马相比，这是一个值得追求的性能途径吗？ （它是否强烈依赖于应用程序的运行时活动？）
【问题讨论】：
标签： ruby-on-rails concurrency unicorn puma