ruby-on-rails-3 - 为 API 后端选择应用服务器

Question

应用程序服务器有这么多选择(Passenger、Thin、Unicorn、Mongrel、Puma 和 Rainbows!)，我想知道什么适合以下场景:

Rails 纯粹用于 API 后端(所有 Assets 都由 Nginx 提供)。一些 API 调用依赖于其他 API 服务，因此有时它们需要一段时间才能完成。

响应式应用程序用于移动、平板电脑和桌面客户端，因此无法保证客户端的连接。

在这种情况下，您认为哪种应用服务器合适？选择时应该考虑哪些事项？

Answer 1

如果您的应用程序对其他服务进行 API 调用，那么 Unicorn 是一个糟糕的选择。 Unicorn 是一个单线程多进程应用程序服务器，专为快速、短期运行的 CPU 密集型工作负载而设计。进行 HTTP API 调用算作长时间运行的阻塞 I/O 请求。这不是限制，而是 Unicorn 的明确设计选择。 the Unicorn website 证实了这一点，“在某些情况下更糟”部分。

理论上，Thin 可以处理这种高并发工作负载，因为它使用事件 I/O。然而，这需要事件代码形式的显式框架和应用程序支持。很少有框架和应用程序这样做。 Rails 和 Sinatra 没有。

所以这只剩下支持多线程的应用程序服务器。三个竞争者是 Puma、Rainbows 和 Phusion Passenger 4 Enterprise .

彪马相对较新。 Rainbows 稍微老一点，但作者不保证它是否运作良好。 Phusion Passenger 已经成熟，已经存在多年，目前被超过 150000 个网站使用，其中包括 Pixar、New York Times、AirBnB 等大型网站。

Puma 和 Rainbows 的使用模型与 Unicorn 和 Thin 类似，您启动一​​堆进程并通过反向代理配置将它们 Hook 到 Nginx。另一方面，Phusion Passenger 被设计为直接集成到 Nginx 中，因此它需要的配置、流程管理和其他管理开销要少得多。

Phusion Passenger 4 Enterprise 不是严格意义上的多线程服务器，而是混合多进程/多线程的服务器。这意味着它可以运行多个进程(以提高稳定性和使用多个 CPU 内核的能力)，每个进程都有多个线程(用于高 I/O 并发)。

Phusion客运4企业带来many advantages over 比 Puma 和 Rainbows 有更多的功能:例如它具有带外垃圾收集，可以根据流量动态调整进程数，完全自动化滚动重启，因此您不需要脚本等。

您可能还对 this writeup 感兴趣了解更多信息。