【发布时间】：2011-01-13 02:56:36
【问题描述】：
我一直在努力部署一个相对较大的 Rails 应用程序（Rails 2.3.5），最近进行了一些负载测试，我们发现该站点的吞吐量远低于预期的流量水平。
我们在标准的 32 位服务器、3GB 内存和 Centos 上运行，我们运行 Ruby Enterprise Edition（最新版本）、Passenger（最新版本）和 Nginx（最新版本）——当只有一两个用户时该站点运行良好（如您所料），但是当我们尝试将负载增加到约 50 个并发请求时，它会完全死机。 （Apache Bench 报告 ~2.3 req/sec，这是可怕的）
我们正在运行 RPM 并试图确定负载问题出在哪里，但它在 Rails、SQL 和 Memcached 中分布得相当均匀，因此我们或多或少地在优化代码库。
出于绝望，我们启动了一个大型 EC2 实例（Ubuntu 9.10、7.5GB RAM、2 个计算单元/核心）并设置了与原始服务器相同的配置，尽管资源更多，但我们仍然看到可悲的结果.
因此，在花了太多时间尝试优化、使用缓存配置等之后，我决定测试一些 mongrels 的吞吐量，并且 ta-da，它们的性能比乘客好得多。
目前的配置是通过 Nginx 代理 15 个 Mongrel，我们似乎满足了我们的负载要求只是，但这还不足以让我对上线感到满意......我在想什么是否有人知道导致这种情况的一些可能原因...？
我对乘客/nginx 的配置是：
- Nginx 工作人员：尝试了 1 到 10 个，但通常是三个。
- 乘客最大池大小：10 - 30（是的，这些数字相当高）
- 乘客全局排队：尝试开启和关闭。
- NGinx GZip 开启：是
值得注意的是，我们已将 nginx 最大客户端主体大小增加到 200m 以允许上传大文件。
无论如何建议都会真的感谢，虽然杂种工作正常，但它改变了我们做事的方式很多，我真的更喜欢使用Passenger - 此外，它不应该这样做吗更简单，性能更好？
【问题讨论】：
-
仅供参考，解释如下：不同之处在于，杂种生成应用程序的分离实例，因此每个应用程序都有自己的 sql 池，而乘客从单个预初始化的应用程序生成器（即快得多）所以它共享你的 sql 池。
-
感谢您的解释 - 一旦我们测试了对池的更改（好吧，一旦我阅读了建议），我就变得非常非常清楚 - 正如明智的人经常说的那样，有时你只需要另一个一双眼睛；）
-
您可能需要修改您的标题，因为这已解决为与 nginx 无关。如果您将 sql 池大小设置得太小，每次部署乘客都会发生这种情况。
-
@hurikhan77: Phusion 团队的成员claims pools are not shared amongst apps。
-
@twelve17 现在在 Passenger4 中可能会有所不同。但通常它是这样的（这意味着不在应用程序之间共享，而是在每个应用程序的实例之间共享）：池连接被打开，进程分叉（打开的 FD 成为共享），因此池与每个实例共享
标签： ruby-on-rails nginx passenger