为API后端选择应用程序服务器

Question

对于应用程序服务器（Passenger，Thin，Unicorn，Mongrel，Puma和Rainbows！）有这么多选择，我想知道什么适用于以下场景：

Rails纯粹用于API后端（所有资产都使用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。

• Puma比较新。彩虹略长，但作者不保证它是否运作良好。 Phusion Passenger已经成熟，已存在多年，目前已被超过15万个网站使用，包括皮克斯，纽约时报，AirBnB等大型网站。
• Puma和Rainbows的使用模式类似于Unicorn和Thin，因为你启动了一系列进程并通过反向代理配置将它们挂钩到Nginx。另一方面，Phusion Passenger旨在直接集成到Nginx中，因此需要更少的配置，流程管理和其他管理开销。
• Phusion Passenger 4 Enterprise不是严格的多线程服务器，而是混合多进程/多线程服务器。这意味着它可以运行多个进程（提高稳定性和使用多个CPU核心的能力），每个进程都有多个线程（用于高I / O并发）。
• Phusion Passenger 4 Enterprise带来many advantages比Puma和Rainbows有更多的功能：例如它有带外垃圾收集，可以根据流量动态调整进程数，完全自动化滚动重启，所以你不要不需要脚本等。

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

Answer 2

唯一可靠的方法是在真实条件下测试和测量表演。其他任何事情都是假设和猜测。

与此同时，你应该从你认识的足够好的开始（独角兽似乎是一个相当受欢迎和体面的选择），并在服务器性能成为瓶颈时处理它。

Answer 3

根据您的独立请求，我建议在nginx反向代理后面使用Puma或Unicorn服务器。使用sidekiq作为工作队列。这是假设一个Rails应用程序，如果使用Sinatra，瘦可能对你来说足够好。就像其他人说的那样，首先要考虑稳定性而不是测试性能。