为生产调整 Rails 性能？
我即将部署一个基于 Rails 3.1.x 构建的应用程序，并开始运行一些性能测试。在摆弄了 ab 一段时间后，我看到一些非常令人沮丧的结果，在 Heroku 上每秒产生大约 15 个请求。
在本地测试时，我看到类似的结果，这确实表明这是一个应用程序问题。
我正在运行 Unicorn，它比 Celadon Cedar 上的 Thin 快大约 40%。此外，我正在使用 PGSQL 共享数据库。
我希望有人可以分享一个详细清单或本质上是一个启动清单，当我准备应用程序进行生产并进入速度调整的需要时，我应该完成这些清单。到目前为止，我还没有找到一个真正简洁的可操作项目列表，考虑到我的情况，这似乎是有意义的。
或者，如果您有解决此类问题的丰富实践经验，我们将不胜感激！
I'm getting close to deploying an application built on Rails 3.1.x and started running some performance tests. After fiddling with ab for a bit, I'm seeing some very discouraging results yielding around 15 requests / second on Heroku.
When testing locally I see similar results that really demonstrates that it's an app issue more than anything.
I'm running Unicorn, which is about 40% faster than Thin on Celadon Cedar. Further, I'm using the PGSQL shared db.
I'm hopeful that someone could share a laundry list or essentially a launch checklist that I should move through when prepping an app for production and moving into the need for speed tuning. So far I've not found a real concise list of actionable items to move through that seems to make sense given my situation.
Or if you have solid practical experience moving through issues like this, any input would be appreciated!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我花了一些时间在 heroku 上调整我的应用程序，并花了一些时间在各种设置下对 Rails 应用程序进行性能调整。
当我运行 ab -n 300 -c 75 ...myapp.com.... # 这是我的主站点的备份，并且位于带有 unicorn 的免费 cedar 计划中
（这是针对不支持的主页）做任何激烈的事情，所以我只提供“heroku 在一个非常简单的页面上的免费计划上能有多快？”的例子，而不是“你的应用程序应该这么快”）
这是我的 Rails 性能调优 101清单：
首先测量浏览器/页面加载时间（浏览器发出大量请求，ab仅告诉您其中一个，通常您的主页请求不是问题），从诸如<的工具获取页面加载基线数字a href="http://www.webpagetest.org">www.webpagetest.org 或 www.gtmetrix.com对于面向公众的页面，或浏览器工具 Yslow、Google 页面速度，或dynatrace 用于私人页面。如果您查看页面加载瀑布图（chrome/firefox 中的“Net”面板），它通常会显示您的 html 加载速度很快（不到一秒），但其他所有内容都需要 1-3 秒才能加载。遵循有关如何改进的 Yslow/页面速度建议（确保您充分使用 Rails 3.1 资产管道内容）
通读您的日志文件/新遗迹，找到“最慢/最慢的最佳点”经常点击'请求，并分析该请求发生的情况（红宝石速度慢/内存使用量大，还是查询多？）您需要有一种可靠的方法来检测和监控性能问题，而不仅仅是在随机的。一旦您确定了一些目标区域，请创建测试脚本以帮助进行前后测试，并证明您的更改有帮助，并检测是否出现回归。
数据库列上缺乏索引是最常见的问题之一，并且最容易解决。对目标查询运行解释，或者查看慢速查询日志，以了解查询规划器正在做什么。根据需要添加外键、搜索列或主数据（覆盖索引）的索引。用实际生产数据重新测试，以证明它有所作为。 （您可以在heroku中运行解释，以及对丢失或未使用的索引运行查询）
大多数性能不佳的Rails应用程序都会遭受N+1查询，因为它很容易编写order.owner.address.city而不考虑当它处于循环中时会发生什么。 N+1 查询不一定是慢查询，因此它们不会出现在慢查询日志中，只是数量较多，一次性完成效率更高。使用 :include 或 .includes() 来立即加载该数据，或者考虑以其他方式进行查询。
分析应用程序的流程并寻找缓存机会。如果用户在索引页面和详细信息页面之间来回跳动，然后再次返回，也许在不离开索引页面的情况下使用 ajax 详细信息视图会以更快的方式为他们提供所需的数据。 了一些对此的更多想法
我对这些进行了演示今年在芝加哥举行的 WindyCityRails 会议上介绍了技术和其他想法。您可以在我的 www.RailsPerformance.com 博客上观看视频
我喜欢 Heroku 的一点是，你必须从一开始就具有可扩展性。当您查看邮件列表上的讨论时，您会发现大多数人都了解性能最佳实践以及如何充分利用服务器。我也喜欢你，如果你想保持便宜，你可以学习性能调整技巧，让你获得最大的收益。
祝你好运！
I've spent some time tuning my app on heroku, and have spent some time working on performance tuning of Rails apps in a variety of settings.
When I run ab -n 300 -c 75 ...myapp.com.... # which is a backup to my main site, and is on the free cedar plan with unicorn
(this is against a home page that doesn't do anything intense, so I'm providing it only as a "how fast could heroku be on the free plan with a very simple page?" example, not a "your apps should be this fast")
Here is my Rails Performance Tuning 101 checklist:
Measure the browser/page load time first (the browser makes lots of requests, ab is only telling you about one of them, and usually your main page request is not the issue), get page load baseline numbers from tools like www.webpagetest.org or www.gtmetrix.com for the public facing pages, or browser tools Yslow, google page speed, or dynatrace for the private pages. If you look at the page load waterfall diagram (the 'Net' panel in chrome/firefox), it usually shows that your html loads quickly (under a sec), but then everything else takes 1-3 sec to load. Follow the Yslow/page speed recommendations on how to improve (make sure you are using the Rails 3.1 assets pipeline stuff to its full extent)
Read through your log files/new relic to find the sweet spot of the 'slowest/most frequently hit' request, and profile what happens for that request (is it slow ruby/lots of mem usage, or lots of queries?) You need to have a reliable way to detect and monitor performance issues, and not just go changing things at random. Once you have identified some target areas, create test scripts to help with before/after testing and prove that your change helps, and detect if a regression creeps in.
Lack of Indexes on db columns is one of the most common issues, and easiest to address. Run explain on the target queries, or look through your slow query log, to see what the query planner is doing. Add indexes for foreign keys, search columns, or primary data (covering index) as appropriate. Retest with actual production data to prove that it makes a difference. (you can run explain in heroku, as well as run queries for missing or unused indexes)
Most poor performing Rails apps suffer from N+1 queries because its so easy to write order.owner.address.city and not think about what happens when that's in a loop. N+1 queries aren't necessarily slow queries, so they don't show up in the slow query log, its just that there are lots of them, and its more efficient to do it all at once. Use :include or .includes() for eager loading of that data, or look at doing your query another way.
Analyze the flow of your app and look for caching opportunities. If the user bounces back and forth between the index page and a details page, and back again, perhaps an ajax view of the details, without leaving the index page would give them the data they need in a faster way. I wrote some more thoughts about that on my blog
I gave a presentation on these techniques and other ideas in Chicago at this year's WindyCityRails conference. You can see the video here on my www.RailsPerformance.com blog
What I love about heroku is that you have to be scalable from the start. When you look at the discussions on the mailing list, you see that most people are aware of the performance best practices, and how to get the most out of the server. I also like how you if you want to stay cheap, you learn how the performance tuning tricks that will get you the most bang.
Good luck!
有一些相当容易实现的目标，几乎总能带来相当值得的性能提升：
include和join，并确保使用empty?而不是any?当您只需要COUNT时，尽可能避免SELECT。您需要小心，不要花费太多时间来优化 Ruby 例程。除非您正在执行大量数据或处理（例如调整图像大小）的操作，否则您可能不会从优化循环或最小化内存使用中看到非常显着的收益。如果您发现某些页面有问题，请深入查看日志并查看这些请求期间发生的情况。
如果您还没有这样做，像 HireFireApp 这样的自动扩展应用程序非常适合让您通过水平扩展来处理大量请求，而无需在缓慢时期运行额外的测功机。
PS：有一个名为 Blitz 的新 Heroku 附加组件，可让您测试高达 5,000 的并发负载用户。
There are some pretty low-hanging fruit that almost always yield pretty worthy performance gains:
includeandjoinwhere appropriate, and make sure you're usingempty?overany?where possible to avoidSELECTs when you just need aCOUNT.You need to be careful not to spend too much time optimizing Ruby routines. Unless you're doing something with a huge amount of data or processing (e.g. image resizing) you probably won't see very significant gains from optimizing loops or minimizing memory usage. And if you find certain pages are problematic, dig into your logs and see what is happening during those requests.
And if you're not already, autoscaling applications like HireFireApp are great for letting you handle loads of requests by scaling horizontally without the cost of running extraneous dynos during slow periods.
PS: There is a new Heroku Add-On called Blitz that lets you test a concurrent load of up to 5,000 users.
最全面的单一答案是使用 NewRelic 之类的工具来检测您的应用程序并找到慢点。然后，您可以对代码应用优化或缓存以消除这些慢点。作为 Heroku 客户，您可以免费安装 NewRelic - 这是一个可以从 Heroku 控制台添加到部署中的插件。
一旦你了解了是什么让你慢下来，你就可以开始解决它。 Heroku 处理性能调优的大部分开发运营端，因此您无需在那里执行任何操作。但是，您仍然可以通过优化数据库查询并在适当的情况下执行片段级和操作级缓存来获得巨大收益。
The most comprehensive single answer is to use something like NewRelic to instrument your application and find the slow spots. Then, you can apply optimizations or caching to your code to smooth out those slow spots. As a Heroku customer, you get a NewRelic install for free - it's an add-in you can add to your deployment from the Heroku console.
Once you have an understanding of what's slowing you down, then you can start to approach it. Heroku handles most all of the dev-ops end of performance tuning, so you don't need to do anything there. However, you'll still be able to make large gains by optimizing database queries and performing fragment- and action-level caching where appropriate.
由于还没有任何进展，我将为 PostgreSQL 部分提供答案。我无法帮助 Ruby。
您可以在 PostgreSQL wiki 中找到优化性能的绝佳起点。
As nothing has come up yet, I'll provide an answer for the PostgreSQL part. I can't assist with Ruby.
You can find excellent starting points for optimizing performance at the PostgreSQL wiki.