ruby-on-rails - Ruby on Rails网站速度变慢

Question

我正在接管Ruby on Rails网站，发现该网站存在巨大的性能问题。有时，该网站甚至没有加载。这对于该网站来说并不新鲜。

它位于具有2GB Ram的Rackspace服务器（第一代）上。

它使用Apache2和MySQL在Ubuntu Hardy上运行。 RoR站点正在运行Ruby（1.8.7）和Rails（3.2.1）的旧版本。

根据top（移位m），Apache（res列）每个进程使用大约6mb至10mb。

它使用具有以下规格的prefork mpm：
启动服务器2
MinSpareServers 2
MaxSpareServers 2
MaxClients 50
MaxRequestsPerChild 100

乘客将设置为：
乘客最大水池尺寸10

乘客内存统计数据显示，Rails平均使用大约40mb。

free -ml始终显示100mb至1500mb的可用内存。

旅客状态有时在等待全局队列中显示高达250，但通常在0到100之间变化。

我曾尝试过使用MaxClients和PoolSize，但最终该网站会变慢或在某个时候根本无法访问，但我假设当流量减少时，稍后会再次加载正常。

加载实际的Rails站点有时可能会花费很长时间，但是加载静态文件（图像，txt文件）的效果很好。尽管有时会达到甚至无法加载静态文件的地步。

是否有任何尝试使它起作用的指示？对于获得的流量（每月约25万次展示），服务器似乎适合该站点。

编辑：
尽管我还是把它放在这里，但我还是回应了评论。

数据库大小约为1gb。垃圾邮件问题很多（新帐户明显是垃圾邮件，平均每天大约1000千，垃圾邮件发布/评论等）。到目前为止，Mysql-slow.log没有显示任何内容。

感谢所有的评论。我曾希望这仅仅是让我成为Apache或Passenger服务器设置的白痴。我的下一步是开始调查代码和查询。

Answer 1

不知道太多，我只能给出更一般的建议。为了提高站点性能，请记住the Perfomance Golden Rule：

最终用户响应时间的80-90％花在了前端上。从那里开始。

以下是在Rails应用中提高性能的非穷举列表区域：

诊断慢速Rails应用程序：

慢速

用于识别性能问题的有用对角线工具是Yslow。这是一个浏览器扩展程序，可以诊断和识别导致应用程序运行缓慢的常见问题（尤其是在前端）。

后端工具

对于您的Rails后端，我建议直接将Bullet和NewRelic之类的工具集成到您的开发过程中，以便在开发过程中可以立即发现不良查询，而这些不良查询仍然易于修复。

检查服务器控制台日志

检查服务器日志是诊断Rails应用程序中使用时间最长的组件的有效方法。例如。以下是在我的本地开发环境中运行的两个不相关的生产Rails应用程序的示例日志（不包括巨大的数据库I / O部分）：

# app1: slowish
  Rendered shared/_header.html.erb (125.9ms)
  Rendered clients/details.html.erb within layouts/application (804.6ms)
  Completed 200 OK in 3655ms (Views: 566.9ms | ActiveRecord: 1236.9ms)

# app2: debilitatingly slow
  Rendered search/_livesearch_division_content.js.erb (5390.0ms)
  Rendered search/livesearch.js.haml (34156.6ms)
  Completed 200 OK in 34173ms (Views: 31229.5ms | ActiveRecord: 2933.4ms)

App1和App2都遇到性能问题，但是App2的性能问题显然令人沮丧。但是有了这些服务器日志，我知道对于App1，我应该研究 clients/details.html.erb，对于App2，我绝对需要研究 search/livesearch.js.haml。 （我发现App2拥有未缓存的大量数据的大型N + 1查询-我将在稍后进行介绍）

改善前端性能

严格预算您的页面大小

为了保持快速的加载时间，您需要减少页面资产（JS / CSS /图像）的数量/大小。因此，请像预算一样考虑您的页面大小。例如，Hootesuite最近宣布其主页现在的页面大小预算严格为1 mb。没有例外。 Now check out their page. Pretty fast isn't it?

减少页面大小的简单方法包括剥离未使用的JS或CSS文件（仅在需要时包含它们），以及将静态图像更改为更小的矢量。

根据屏幕宽度提供较小的图像分辨率

图像加载是页面加载时间缓慢的主要原因。初始页面背景中使用的大5mb图像可以轻松缩小到200kb-400kb，并且仍然具有足够高的质量，与高分辨率的原始图像几乎没有区别。页面加载时间的差异会很大。

您也应该对上传的图片执行相同的操作。例如。如果用户为自己的横幅广告或头像上传了5mb的图片，则必须根据文件的显示大小以较低的文件大小/分辨率提供此上传的图片。 Carrierwave， Fog与 rmagick或 minimagic结合使用是一种流行的技术，可与Amazon S3一起使用，以实现更好的图像上传/调整大小。使用它们，您可以动态提供较小的图像分辨率，以适合用户的屏幕尺寸。然后，您可以使用媒体查询来确保为移动设备提供比具有Retina屏幕的台式机更小的图像分辨率和文件大小。

使用内容交付网络加快资产加载

如果您的站点处理大量图像或大文件，那么您应该考虑使用诸如Cloudfront之类的Content Delivery Network（CDN）来加快资产/图像加载时间。 CDN将您的资产文件分布在世界各地的许多服务器上，然后使用最接近用户地理区域的服务器来提供资产。除了更快的速度外，CDN的另一个好处是它减少了您自己服务器上的负载。

指纹静态资产

当静态资产被指纹识别后，当用户访问您的页面时，他们的浏览器将缓存这些资产的副本，这意味着它们不再需要为下一个请求重新加载。

将Javascript文件移到页面底部

如果还包含其他未使用Rails方式的javascript文件，请注意，如果将javascript资产放置在页面顶部，则当用户的浏览器尝试加载页面时，页面在加载时将保持空白。如果您使用资产管道或使用 javascript_include_tag指定javascript文件，Rails会自动将javascript文件放置在页面底部，以防止出现此问题，但是如果不是这种情况，请确保将外部javascript文件包含在页面底部。这一页。

改善后端性能

缓存，缓存，缓存（使用Memcache / Dalli）！

在后端性能优化中，没有任何一项性能增强可与高速缓存所带来的好处相提并论。缓存是将任何Rails应用程序推向高度可扩展性的重要组成部分。实施良好的缓存机制可最大程度地减少服务器对低效率查询的影响，并减少对现有性能不佳的代码进行痛苦的重构的需要。

例如，在上面提到的我的App2示例中，实现了简单的页面缓存后，我们的34秒页面加载时间减少到生产中的不到一秒。我们没有重构此代码的一行。

经常访问但相对不频繁更改的页面内容最容易缓存，并且从缓存中受益最大。在服务器端有多种缓存方式，包括页面缓存和片段缓存。 Russian doll caching现在是Rails中最受欢迎的片段缓存技术。 Here's a good place to start.

索引（几乎）所有

如果将SQL用于数据库层，请确保在连接表上指定索引，以便在频繁使用的大型关联上更快地查找。从 indexing is not included by default in Rails.开始，您必须在迁移期间明确添加它们

消除E + 1加载带来的N + 1查询

N+1 queries是使用关系（SQL）数据库的Rails应用程序的主要性能杀手。如果您在日志中以类似于模式的方式看到单个请求的数百个数据库读/写，则很可能您已经遇到了严重的N + 1查询问题。 N + 1查询在开发过程中很容易遗漏，但是随着数据库的增长，它会迅速削弱您的应用程序（我曾经处理过一个具有十二个N + 1查询的应用程序。在仅累积约1000行生产数据之后，一些页面开始接管了分钟加载）。

Bullet是 catching N+1 queries early as you develop your app.的绝佳选择。在Rails应用中解决N + 1查询的一种简单方法是急于在必要时加载关联的Model。例如。如果要在页面上加载每个帖子的所有评论，则 Post.all更改为 Post.includes(:comments).all。

升级到Rails 4和/或Ruby 2.1.x或更高版本

较新版本的Rails包含许多性能改进，可以提高您的应用程序的速度（例如Turbolinks）。如果您仍在运行Rails 3.2.1，则仅出于安全原因就需要至少升级到Rails 3.2.18。

与旧版本的Ruby相比，Ruby 2.1.x +包含更好的垃圾回收。到目前为止，有关人员升级的报告已发现 notable performance increases from upgrading.



这些是我可以推荐的一些性能改进。没有更多信息，我将无济于事。