ruby-on-rails – 没有nginx使用独角兽是不是很糟糕？为什么？

我读到unicorn快速提供静态内容,减慢用户速度,重定向.为什么更好的nginx独角兽只运行独角兽,并在需要时扩展独角兽工人的数量？你有没有数字显示nginx在这些事情上的速度有多快(重定向,代理,提供静态内容)？解决方法...

我读到unicorn快速提供静态内容,减慢用户速度,重定向.

为什么更好的nginx独角兽只运行独角兽,并在需要时扩展独角兽工人的数量？

你有没有数字显示nginx在这些事情上的速度有多快(重定向,代理,提供静态内容)？

解决方法:

As Heroku DevCenter claims,独角兽工人容易受到慢客户的影响.

每个工作人员只能处理单个请求,如果客户端尚未准备好接受整个答案(也称为“慢速客户端”),则Unicorn工作人员在发送响应时被阻止,无法处理下一个响应.由于每个Unicorn工作人员占用了大量的RAM(again, see Heroku,它声称可以处理512 MiB RAM的2-4个进程),所以你不能依赖于工作人员的数量,因为它是关于可以使你的应用程序无法运行的客户端数量.假装连接速度慢.

当nginx落后时,Unicorn能够将整个答案转储到nginx的缓冲区并立即切换到处理下一个请求.

也就是说,拥有一名Unicorn工作人员的nginx比直接暴露的一群Unicorn工作人员更可靠.

注意：对于那些使用古代Rubies的人：如果你将使用一组Unicorn工作者,考虑通过在分叉进程之间共享公共数据来迁移到至少Ruby 2.0以减少RAM消耗(ref).