Rails性能调优的生产？

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

当我在本地进行测试时，我看到类似的结果，确实表明它是一个应用程序问题。

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

我希望有人能够分享一份清单或基本上是一张启动清单，我应该在准备生产应用程序时进行检查，并转向对速度进行调整。到目前为止，我已经而不是找到了一个真正简洁的可操作项目列表，在我看来，这似乎是有道理的。

或者，如果您在解决这类问题方面拥有扎实的实践经验，任何意见都将不胜感激！

来源

2011-11-05 ylluminate

我花了一些时间在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性能调优101清单：

首先测量浏览器/页面加载时间（浏览器提出大量请求，ab只告诉你其中一个请求，通常你的主页面请求不是问题），从www.webpagetest.org或www.gtmetrix.com面向公众的页面，或浏览器工具Yslow，谷歌页面速度或dynatrace专用页面。如果你看一下页面加载的瀑布图（chrome/firefox中的'Net'面板），它通常会显示你的html快速加载（不到一秒），但其他一切都需要1-3秒才能加载。按照Yslow /页面速度的建议来改进（确保您完全使用Rails 3.1资产管道内容）
通读您的日志文件/新文物以找到'最慢/最频繁点击'的请求，并描述该请求发生了什么（它是缓慢的ruby /大量的内存使用，或大量的查询？）您需要有一个可靠的方法来检测和监控性能问题，而不仅仅是改变随机的东西。一旦你确定了一些目标区域，创建测试脚本以帮助测试之前/之后，并证明你的变化有帮助，并检测是否有回归。
缺乏db列索引是最常见的问题，并且最容易解决。在目标查询上运行解释，或查看慢查询日志，查看查询规划器正在执行的操作。根据需要为外键，搜索列或主数据（覆盖索引）添加索引。用实际生产数据重新测试以证明它有所作为。（你可以在heroku中运行解释，以及运行缺少或未使用索引的查询）
大多数性能不佳的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的喜爱是你必须从一开始就可以扩展。当您查看邮件列表上的讨论时，您会发现大多数人都知道性能最佳实践，以及如何充分利用服务器。如果你想保持便宜，我也很喜欢你，你会了解到性能调整技巧如何让你获得最大的回报。

祝你好运！

来源

2011-12-07 18:41:39

你好，你能看看我有关类似情况的问题吗？ http://stackoverflow.com/questions/22580297/how-to-tune-a-production-level-heroku-postgres-with-a-ruby-on-rails-application – scaryguy

因为还没有出现，我会提供一个答案，PostgreSQL部分。我无法协助Ruby。

您可以在PostgreSQL wiki上找到优化性能的极好起点。

调整的server settings（不知道有多少是可能的Heroku）
要特别注意slow queries
检查hardware（不适用与Heroku的）

来源

2011-11-07 00:40:41

由于您通常不会在Rails应用程序中编写SQL查询，并且（如前所述）服务器设置和硬件在Heroku上不相关，因此您的答案不是很有针对性。 – coreyward

@coreyward：够公平的。然而，我的答案似乎引起了一些关注，它在目标上产生了更多的答案。 –

感谢提高头@ErwinBrandstetter！事实上，关于调整Heroku的基于AWS的共享PGSQL数据块的功能并不多，但是根据其他说明，查询可能是轮胎问题。 – ylluminate

最综合的单一答案是使用NewRelic之类的工具来测试你的应用程序并找到慢点。然后，您可以将优化或缓存应用于您的代码，以消除这些慢点。作为Heroku客户，您可以免费获得NewRelic安装 - 这是一个可以从Heroku控制台添加到部署中的插件。

一旦你理解了什么让你放慢速度，那么你可以开始接近它。 Heroku可以处理性能调优的大部分开发工作，所以你不需要在那里做任何事情。但是，您仍然可以通过优化数据库查询并在适当的地方执行片段级和动作级缓存来获得巨大收益。

来源

2011-11-07 00:49:08

谢谢。我稍微使用了NewRelic作为免费服务，但听起来好像我现在确实应该考虑其他选项，以便查看吱吱声的位置在哪里。谢谢！结果将在这里回到你身边。 – ylluminate

有一些相当低挂果树，几乎总能取得相当值得的性能提升：

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

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

如果您还不是，像HireFireApp这样的自动缩放应用程序非常适合让您通过水平扩展来处理大量请求，而无需在慢速时段运行无关的dynos。

PS：有一个新的名为Blitz的Heroku插件，可以测试多达5,000个用户的并发负载。

来源

2011-11-07 00:54:15 coreyward

好东西，谢谢你的评论。是的，HireFire是伟大的，迈克尔是一个伟大的人，并认为他是一个朋友。深入挖掘你的评论，并让你知道我的结果。其中一些目前不适用，但我对“不优化Ruby例程”表示赞赏，因为这是我首先考虑的问题之一，但似乎产生了不太好的结果。 – ylluminate

@coreyward，嗨核心，你可以为简单的铁路咨询？在您的网站上找不到您的联系信息。如果是这样，请发送电子邮件至panabee dot com。谢谢！ – Crashalot

Rails性能调优的生产？

回答

相关问题