ruby-on-rails - 乘客托管的 Rails 应用程序*痛苦* 慢，但服务器是个野兽

Question

我一直在努力部署一个相对较大的 Rails 应用程序(Rails 2.3.5)，最近做了一些负载测试，我们发现该站点的吞吐量远低于预期的流量水平。

我们在标准的 32 位服务器上运行，使用 Centos 有 3GB 内存，我们运行 Ruby 企业版(最新版本)、Passenger(最新版本)和 Nginx(最新版本)——当站点只有一两个用户时很好(如您所料)但是当我们尝试将负载增加到大约 50 个并发请求时，它完全消失了。 (Apache Bench 报告 ~2.3 req/sec，这很糟糕)

我们正在运行 RPM 并试图确定负载问题在哪里，但它在 Rails、SQL 和 Memcached 之间分布相当均匀，因此我们或多或少地检查和优化代码库。

出于绝望，我们启动了一个大型 EC2 实例(Ubuntu 9.10，7.5GB RAM，2 个计算单元/核心)并设置与原始服务器相同的配置，虽然有更多资源，但我们仍然看到可悲的结果。

因此，在花了太多时间尝试优化、使用缓存配置等之后，我决定测试一些杂种和 ta-da 的吞吐量，它们的性能比乘客好得多。

目前的配置是通过 Nginx 代理 15x Mongrels，我们似乎满足了我们的负载要求 只是 但这还不足以让我对上线感到满意......我想知道是否有人知道一些可能的原因......？

我的乘客/nginx 配置是:

Nginx worker :尝试了 1 到 10 个，但通常是三个。

乘客最大池大小:10 - 30(是的，这些数字相当高)

乘客全局排队:试过开和关。

NGinx GZip 开启:是

值得注意的是，我们已将 nginx 最大客户端主体大小增加到 200m，以允许上传大文件。

无论如何，建议将非常受欢迎，虽然杂种工作正常，但它改变了我们做事的方式，我真的更喜欢使用乘客 - 此外，难道它不应该使这更容易并表现得更好吗？

Answer 1

也许您的 sql 池大小太小？这从本质上限制了应用程序中数据库工作负载的并行性，一旦您将工作放在应用程序堆栈上，这反过来会增加大量增加的负载......