对于应用程序服务器(Passenger,Thin,Unicorn,Mongrel,Puma和Rainbows！)有这么多选择,我想知道什么适合以下场景：
Rails纯粹用于API后端(所有资产都与Nginx一起提供).某些API调用依赖于其他API服务,因此有时需要一段时间才能完成.
响应式应用程序用于移动,平板电脑和桌面客户端,因此无法保证客户端的连接.
在这种情况下,您认为哪种应用服务器是合适的？选择时应该考虑哪些事项？
解决方法
如果您的应用程序对其他服务进行API调用,那么Unicorn是一个糟糕的选择. Unicorn是一个单线程多进程应用程序服务器,专为快速,短期运行的cpu绑定工作负载而设计.进行HTTP API调用会计入长时间运行的阻止I / O请求.这不是限制,而是Unicorn的明确设计选择.这已在
the Unicorn website“部分案例中更糟糕”一节中得到证实.
理论上,Thin可以处理这种高并发工作负载,因为它使用了事件I / O.但是,这需要以事件代码的形式提供明确的框架和应用程序支持.很少有框架和应用程序这样做. Rails和Sinatra没有.
因此,这只留下支持多线程的应用程序服务器.三个竞争者是Puma,Rainbows和Phusion Passenger 4 Enterprise.
>彪马相对较新.彩虹略长,但作者不保证它是否运作良好.乘客的Phusion成熟,已存在多年,目前正在使用的超过15万网站,包括路数,如皮克斯,纽约时报,发现生活怎样,等等.
>彪马的和彩虹的使用模式是相似的,以独角兽和薄启动一堆程序,并将它们挂到Nginx的通过反向代理服务器配置.另一方面,Phusion Passenger旨在直接集成到Nginx中,因此它需要更少的配置,流程管理和其他管理开销.
> Phusion Passenger 4 Enterprise不是严格的多线程服务器,而是混合多进程/多线程服务器.这意味着它可以运行多个进程(对于增加的稳定性和使用多个cpu核的能力),每一个与多个线程(用于高I / O的并发).
>的Phusion客运4企业带来many advantages在比彪马更多的功能和彩虹：比如它具有带外的垃圾收集的,可动态调整基于流量的进程数,完全自动化滚动重新启动,所以你不需要脚本,等.
您可能还对this writeup感兴趣以获取更多信息.