ruby-on-rails – 是否有必要将Unicorn放在Nginx(或Apache)

我对这个架构有些困惑.在我正在开展的项目之一中,Unicorn被选为Rails服务器.而且它放在Nginx Web服务器的后面.据了解,Unicorn是功能齐全的Web服务器,我们不打算在同一服务器实例上托管任何其他Rails应用程序.

所以我的问题是:链中附加层有什么好处?

client -> Nginx -> unicorn -> unicorn worker

解决方法

独角兽不是处理“慢客户”的设计.您可以在 PHILOSOPHY帮助文件中阅读更多信息:

Most benchmarks we’ve seen don’t tell you this,and unicorn doesn’t care about slow clients… but you should.

A “slow client” can be any client outside of your datacenter. Network traffic within a local network is always faster than traffic that crosses outside of it. The laws of physics do not allow otherwise.

Persistent connections were introduced in HTTP/1.1 reduce latency from connection establishment and TCP slow start. They also waste server resources when clients are idle.

Persistent connections mean one of the unicorn worker processes (depending on your application,it can be very memory hungry) would spend a significant amount of its time idle keeping the connection alive and not doing anything else. Being single-threaded and using blocking I/O,a worker cannot serve other clients while keeping a connection alive. Thus unicorn does not implement persistent connections.

If your application responses are larger than the socket buffer or if you’re handling large requests (uploads),worker processes will also be bottlenecked by the speed of the client connection. You should not allow unicorn to serve clients outside of your local network.

相关文章

validates:conclusion,:presence=>true,:inclusion=>{...
一、redis集群搭建redis3.0以前,提供了Sentinel工具来监控各...
分享一下我老师大神的人工智能教程。零基础!通俗易懂!风趣...
上一篇博文 ruby传参之引用类型 里边定义了一个方法名 mo...
一编程与编程语言 什么是编程语言? 能够被计算机所识别的表...
Ruby类和对象Ruby是一种完美的面向对象编程语言。面向对象编...