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