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

前端之家收集整理的这篇文章主要介绍了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.

猜你在找的Ruby相关文章