RubyOnRails 应用程序的 Thin + Nginx 生产就绪组合答案

【问题标题】：Thin + Nginx Production ready combination for RubyOnRails ApplicationRubyOnRails 应用程序的 Thin + Nginx 生产就绪组合
【发布时间】：2010-10-08 00:30:45
【问题描述】：

我最近在我的部署服务器上安装了 Nginx + Thin，但我不确定这在最后的请求和响应情况下会如何执行。假设每秒 1000/req。

因此，thin 的速度在 10-100 req / per sec 下是不错的

我想知道请求/响应集群上处理的数据量更大。

在这方面指导我:-)

【问题讨论】：

标签： ruby-on-rails deployment nginx thin

【解决方案1】：

多个瘦进程和 nginx 能够提供很大的速度，具体取决于您的应用程序在做什么。因此，问题将出在您的应用程序代码、应用程序服务器的速度和数据库服务器上。

最近，Scaling Rails Screencasts 深入介绍了 Scaling Rails。我建议你从那里开始。我扩展 Rails 的 5 步计划是：

第一步是使用工具来查看应用程序中的慢速问题。当您不知道问题出在哪里时，不要花时间优化应用程序中的所有内容。
每秒处理大量请求的最简单方法是使用页面缓存。
如果您做不到，请缓存所有可能的内容（片段缓存、使用 memcached 缓存数据等），以加速您的应用程序。
之后，尽可能优化您的应用程序，使 SQL 查询速度更快，为所有内容编制索引等。
如果您仍需要更高的速度，请在问题上投入更多的硬件。获取一个强大的大型数据库服务器、一堆应用服务器，并在它们之间代理您的请求。您也可以从这里开始，但这只会延迟优化过程。

【讨论】：

我同意优化，但问题在于 Rails 世界中是否有人部署了 Nginx + Thin 组合。因此，如果人们成功使用它，那么它值得遵循。我无法使用生产环境。
是的，我确信 Thin 和 nginx 已经经常部署在生产环境中。 thin 只是 Mongrel 的一个替代方案，而 mongrel + nginx 是 2007-2008 年非常常见的部署选项（mod_rails 现在开始接管）。
我相信现在从可扩展性的角度来看最好的选择是 Apache Worker MPM + Phusion Passenger。我已经尝试过了，它的工作方式类似于 EC2 实例自动创建。 worker MPM 根据需要添加 spawner。您不必担心任何集群平衡器成员。
@T.Raghavendra：虽然Passenger 确实很受欢迎并且是一个不错的选择，但Thin 仍在广泛使用。例如，Heroku 使用瘦 + nginx 设置，并托管超过 100,000 个应用程序。

【解决方案2】：

如果您只有一台服务器，我认为主要的关键是，除了已经提到的所有内容之外，不要吝啬它的规格。试图获得太多而太少只会导致灾难。

让 monit 或 God 监控你的瘦实例也是一个好主意，我一开始是用 God，但它在 Ruby 1.8.6 上泄漏内存非常糟糕，所以我停止使用它来支持 monit。 Monit 是用 C 语言编写的，我相信它的内存占用很小，所以我推荐它。

如果要让 nginx 和瘦身发挥出色，这一切似乎有点过分，您可能需要研究像Passenger 或 LiteSpeed 这样的多合一解决方案。我对这些方面的经验很少，因此无法为他们提供实质性建议。

【讨论】：