Question

我已经接近部署基于Rails 3.1.x构建的应用程序，并开始运行一些性能测试。在稍稍摆弄ab之后，我看到一些非常令人沮丧的结果，在Heroku上产生大约15个请求/秒。

在本地测试时，我看到类似的结果，这些结果确实表明它比任何应用程序更重要。

我正在运行Unicorn，比Celadon Cedar上的Thin快约40％。此外，我正在使用PGSQL共享数据库。

我希望有人可以共享一份清单或基本上是一份发布清单，我在准备生产应用程序并进入速度调整需求时应该完成这项工作。到目前为止，我已经不找到了一个真正简明的可操作项目列表，根据我的情况，这似乎是有意义的。

或者，如果您在此类问题上有扎实的实践经验，那么任何输入都会受到赞赏！

Answer 1

我花了一些时间在heroku上调整我的应用程序，并花了一些时间在各种设置中进行Rails应用程序的性能调整。

当我运行ab -n 300 -c 75 ... myapp.com ....＃这是我主站点的备份，并且是与独角兽的免费雪松计划

Requests per second:    132.11 [#/sec] (mean)
Time per request:       567.707 [ms] (mean)
Time per request:       7.569 [ms] (mean, across all concurrent requests)

（这是针对一个没有做任何激烈事情的主页，所以我只提供它作为“heroku在一个非常简单的页面上的免费计划有多快？”例子，而不是“你的应用程序应该快速“）

这是我的Rails Performance Tuning 101核对清单：

首先测量浏览器/页面加载时间（浏览器发出大量请求，ab只告诉您其中一个请求，通常主页请求不是问题），从中获取页面加载基线数面向公众的页面使用www.webpagetest.org或www.gtmetrix.com等工具，或私有页面的浏览器工具Yslow，google页面速度或dynatrace。如果你看一下页面加载瀑布图（chrome / firefox中的'Net'面板），它通常会显示你的html加载很快（在一秒内），但是其他一切都需要1-3秒才能加载。按照Yslow /页面速度建议如何改进（确保您完全使用Rails 3.1资产管道的东西）
通读您的日志文件/新文物，找到“最慢/最常点击”请求的最佳位置，并分析该请求会发生什么（是它的缓慢红宝石/大量的内存使用情况，还是很多查询？）您需要有一种可靠的方法来检测和监控性能问题，而不仅仅是随意更改内容。一旦确定了一些目标区域，就可以创建测试脚本来帮助测试之前/之后，并证明您的更改有所帮助，并检测回归是否会逐渐消失。
数据库列上缺少索引是最常见的问题之一，也是最容易解决的问题。对目标查询运行说明，或查看慢速查询日志，以查看查询计划程序正在执行的操作。根据需要添加外键，搜索列或主数据（覆盖索引）的索引。重新测试实际生产数据，以证明它有所作为。（您可以在heroku中运行explain，以及对缺失或未使用的索引运行查询）
大多数表现不佳的Rails应用程序都受到N + 1个查询的影响，因为它很容易编写order.owner.address.city而不考虑当它在循环中时会发生什么。 N + 1查询不一定是慢查询，因此它们不会出现在慢查询日志中，只是它们有很多，而且一次性完成所有这些查询效率更高。使用：include或.includes（）用于急切加载该数据，或者以另一种方式查看您的查询。
分析您的应用流程并查找缓存机会。如果用户在索引页面和详细信息页面之间来回跳转，并且再次返回，则可能在不离开索引页面的情况下对细节进行ajax视图将以更快的方式为他们提供所需的数据。我写了一些more thoughts about that on my blog

我在今年的WindyCityRails会议上介绍了芝加哥的这些技术和其他想法。你可以see the video here on my www.RailsPerformance.com blog 我喜欢heroku的是你必须从一开始就可以扩展。当您查看邮件列表上的讨论时，您会发现大多数人都了解性能最佳实践，以及如何充分利用服务器。我也很喜欢你如果你想保持便宜，你会学习如何通过性能调整技巧来获得最大的收获。

Answer 2

有一些相当低调的成果几乎总能产生非常有价值的表现：

使用更高效的ActiveRecord语句减少数据库查询的数量。请务必在适当情况下使用include和join，并确保尽可能使用empty? any?，以便在需要时尽量避免使用SELECT COUNT。
特别是在较重的页面上，缓存视图，即使只有几分钟。您通常可以将较大或动态的部分分解为可以缓存的部分，而不会产生任何负面影响。
将任何网络上的活动移至后台作业。这包括发送电子邮件，从其他网站获取页面，以及进行API调用（甚至[特别？]到Heroku）。在Ruby中有许多非常好的后台作业处理库，DelayedJob非常受欢迎，因为它适用于任何ActiveRecord数据库，但我最喜欢的是Resque。

您需要注意不要花太多时间来优化Ruby例程。除非您正在处理大量数据或处理（例如图像大小调整），否则您可能无法从优化循环或最小化内存使用量中获得非常显着的收益。如果您发现某些页面存在问题，请深入了解日志并查看这些请求中发生的情况。

如果您还没有，那么像HireFireApp这样的自动缩放应用程序非常适合让您通过水平扩展来处理大量请求，而无需在缓慢的时间段内运行无关动态的成本。

PS：有一个名为Blitz的新Heroku加载项，可让您测试最多5,000个用户的并发加载。

Answer 3

最全面的单一答案是使用类似NewRelic的东西来检测您的应用程序并找到慢点。然后，您可以对代码应用优化或缓存以消除这些慢点。作为Heroku客户，您可以免费获得NewRelic安装 - 它是一个可以从Heroku控制台添加到您的部署中的加载项。

一旦你了解了什么让你失望，那么你就可以开始接近它了。 Heroku处理大多数dev-ops性能调优的结束，所以你不需要在那里做任何事情。但是，您仍然可以通过优化数据库查询并在适当的情况下执行片段和操作级缓存来获得巨大收益。

Answer 4

由于还没有出现，我将为 PostgreSQL 部分提供答案。我无法协助Ruby。

您可以在PostgreSQL wiki中找到优化性能的出色起点。

调整server settings（不确定使用Heroku可以达到多少）
特别注意slow queries
检查hardware（不适用于Heroku）

用于生产的Rails性能调优？

4 个答案: