我即将部署一个基于 Rails 3.1.x 构建的应用程序，并开始运行一些性能测试。摆弄之后ab有一段时间，我在 Heroku 上看到了一些非常令人沮丧的结果，每秒产生大约 15 个请求。
在本地测试时，我看到类似的结果，这确实表明这是一个应用程序问题。
我正在运行 Unicorn，它比 Celadon Cedar 上的 Thin 快大约 40%。此外，我正在使用 PGSQL 共享数据库。
我希望有人可以分享一个详细清单或本质上是一个启动清单，当我准备应用程序进行生产并进入速度调整的需要时，我应该完成这些清单。到目前为止我已经not找到了一个真正简洁的可操作项目列表，考虑到我的情况，这似乎是有意义的。
或者，如果您有解决此类问题的丰富实践经验，我们将不胜感激！
我花了一些时间在 heroku 上调整我的应用程序，并花了一些时间在各种设置下对 Rails 应用程序进行性能调整。
当我运行 ab -n 300 -c 75 ...myapp.com.... # 这是我的主站点的备份，并且位于 unicorn 的免费 cedar 计划中
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 性能调优 101 清单：
首先测量浏览器/页面加载时间（浏览器发出大量请求，ab仅告诉您其中一个，通常您的主页请求不是问题），从诸如此类的工具获取页面加载基线数字www.webpagetest.org http://www.webpagetest.org or www.gtmetrix.com http://www.gtmetrix.com对于面向公众的页面，或者浏览器工具 Yslow、google page speed 或 dynatrace 对于私人页面。如果您查看页面加载瀑布图（chrome/firefox 中的“Net”面板），它通常会显示您的 html 加载速度很快（不到一秒），但其他所有内容都需要 1-3 秒才能加载。遵循 Yslow/page speed 关于如何改进的建议（确保您充分使用 Rails 3.1 资产管道内容）
通读您的日志文件/新遗物，找到“最慢/最频繁命中”请求的最佳点，并分析该请求发生的情况（是缓慢的 ruby/大量内存使用，还是大量查询？）您需要有一种可靠的方法来检测和监控性能问题，而不是随意改变。确定一些目标区域后，创建测试脚本以帮助进行测试前/测试后并证明您的更改有帮助，并检测是否出现回归。
数据库列缺乏索引是最常见的问题之一，也是最容易解决的问题。对目标查询运行解释，或者查看慢速查询日志，以了解查询规划器正在做什么。根据需要添加外键、搜索列或主数据（覆盖索引）的索引。用实际生产数据重新测试，以证明它有所作为。 （您可以在heroku中运行解释，以及对丢失或未使用的索引运行查询）
大多数性能不佳的 Rails 应用程序都会遭受 N+1 查询的困扰，因为编写 order.owner.address.city 非常容易，而不会考虑在循环中会发生什么。 N+1 查询不一定是慢查询，因此它们不会出现在慢查询日志中，只是数量较多，一次性完成效率更高。使用 :include 或 .includes() 来立即加载该数据，或者考虑以其他方式进行查询。
分析应用程序的流程并寻找缓存机会。如果用户在索引页面和详细信息页面之间来回跳动，然后再次返回，也许在不离开索引页面的情况下使用 ajax 详细信息视图会以更快的方式为他们提供所需的数据。我写了一些关于我的博客的更多想法 http://www.railsperformance.com/2011/10/improving-application-performance-by.html
我在今年芝加哥的 WindyCityRails 会议上介绍了这些技术和其他想法。你可以请观看我的 www.RailsPerformance.com 博客上的视频 http://www.railsperformance.com/2011/11/performance-tuning-tutorial-video-2011.html我喜欢 Heroku 的一点是，你必须从一开始就具有可扩展性。当您查看邮件列表上的讨论时，您会发现大多数人都了解性能最佳实践以及如何充分利用服务器。我也喜欢你，如果你想保持便宜，你可以学习性能调整技巧，让你获得最大的收益。
祝你好运！
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
