Rails性能调优的生产？ [英] Rails Performance Tuning for Production?

问题描述

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

在本地进行测试时，我看到类似的结果，这确实表明它是一个应用程序问题。运行Unicorn，比Thin on Celadon Cedar快40％。此外，我正在使用PGSQL共享分贝。

我希望有人能分享一份洗衣清单或本质上是一张启动清单，我应该在准备应用程序的生产和移动到速度调整的需要。到目前为止，我已经 not 发现了一个真正简洁的可操作项目列表，可以根据我的情况对其进行移动。

或者if你有扎实的实践经验，通过这样的问题，任何输入将不胜感激！

解决方案

我花了一些时间调整我的在heroku上的应用程序，并花了一些时间在各种设置中调整Rails应用程序的性能。 当我运行ab -n 300 -c 75 ... myapp.com ....＃这是我的主站点的备份，并且是免费的雪松计划与独角兽

 每秒请求数：132.11 [＃/ sec]（平均）
每次请求的时间：567.707 [ms]（mean）
每个请求的时间：7.569 [ms]（平均值，跨所有并发请求）
  

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

这是我的Rails性能调优101清单：

1. 首先测量浏览器/页面加载时间（浏览器提出大量请求，ab仅告诉您其中一个请求，通常您的主页面请求不是问题），获取页面加载基线来自诸如 www.webpagetest.org 或 www.gtmetrix.com 为公共页面，或浏览器工具Yslow，谷歌页面速度或dynatrace专用页面。如果你看一下页面加载的瀑布图（chrome / firefox中的'Net'面板），它通常会显示你的html快速加载（不到一秒），但其他一切都需要1-3秒才能加载。按照Yslow /页面速度的建议来改进（确保您完全使用Rails 3.1资产管道内容）

阅读你的日志文件/新文件来找到最慢/最频繁命中请求的最佳位置，并描述该请求发生了什么（是缓慢的ruby /大量的mem使用情况还是很多查询？）您需要有一个可靠的检测和监控性能问题的方法，而不是随意更改。一旦你确定了一些目标区域，创建测试脚本来帮助测试之前/之后，并证明你的变化有帮助，并检测是否有回归陷入。 >数据库列缺乏索引是最常见的问题之一，也是最容易解决的问题之一。在目标查询上运行解释，或查看慢查询日志，查看查询规划器正在执行的操作。根据需要为外键，搜索列或主数据（覆盖索引）添加索引。用实际生产数据重新测试以证明它有所作为。 （您可以在heroku中运行解释程序，以及运行缺少或未使用索引的查询）。 大多数表现不佳的Rails应用程序都遭受N + 1个查询，因为它的所以很容易编写order.owner.address.city，而不用考虑在循环中会发生什么。 N + 1查询不一定是慢速查询，所以它们不会显示在慢速查询日志中，只是有很多这样的查询，并且一次完成所有操作都更有效。使用include或.includes（）来加载该数据，或者以另一种方式查看查询。


2. 分析应用程序的流程并查找缓存机会。如果用户在索引页面和详细信息页面之间来回跳动，并且可能返回一个详细信息的ajax视图，而不离开索引页面，则会以更快的方式为他们提供所需的数据。我在自己的博客上写了一些更多想法

在今年的WindyCityRails会议上，我介绍了芝加哥的这些技术和其他想法。您可以在我的www.RailsPerformance.com博客上查看视频
我对heroku的喜爱是你必须从一开始就可以扩展。当您查看邮件列表上的讨论时，您会发现大多数人都知道性能最佳实践，以及如何充分利用服务器。我也喜欢你如果你想保持便宜，你会学习如何调整性能的方法，这将会让你获得最大的震撼。

祝你好运！

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!

解决方案

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

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)

(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:

1. 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)

2. 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.

3. 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)

4. 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.

5. 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!

这篇关于Rails性能调优的生产？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！