Rails 的性能问题：如何发送 gzip 资产答案

【问题标题】：Performance issue for Rails: How to send gzip assetsRails 的性能问题：如何发送 gzip 资产
【发布时间】：2017-06-09 07:39:45
【问题描述】：

我在生产环境中使用 Rails 资产管道功能。我在 nginx 中编写了一些设置以发送 gzip 格式的文件，并且文件以 gzip 格式正确发送。我猜浏览器会自动解码它，所以我不是能够查明 js 文件是否以 gizp 格式传入。

我已经输入了以下命令，并且在响应中得到了“content-encoding: zip”。

curl -v -H 'Accept-Encoding: gzip' -o /dev/null http://www.example.com/assets/style.css 2>&1 | grep -i Content-Encoding

我在 nginx 中编写了以下设置以发送 gzip 格式的文件，并且文件以 gzip 格式正确发送。

location ~ ^/(assets)/  {
        root /home/webuser/app/woa/public;
        gzip_static on;
        expires max;
        add_header Cache-Control public;
        # access_log /dev/null;
        }

我如何知道文件是否以 gzip 格式提供？？

还请提出任何其他有助于提高网站性能的选项。

【问题讨论】：

标签： ruby-on-rails-3 performance angularjs nginx gzip

【解决方案1】：

不是你第一个问题的直接答案（如果你解决了，请解释一下），但为了提高网站性能，请记住the Perfomance Golden Rule：

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

下面是非详尽的列表，可以提高 Rails 应用程序的性能：

诊断问题：

YSlow / Google 页面速度

Yslow 或 Google Page Speed 是一种用于识别性能问题的有用诊断工具，它们是浏览器扩展程序，可以诊断和识别降低应用程序速度的常见问题（尤其是在前端）。

后端工具

对于您的 Rails 后端，我建议将Bullet 和NewRelic 等工具直接集成到您的开发过程中，这样您在开发时可以立即发现错误查询，同时它们仍然很容易修复。

检查服务器控制台日志

检查服务器日志是诊断 Rails 应用程序的哪些组件占用时间最长的有效方法。例如。以下是在我的本地开发环境中运行的两个不相关的生产 Rails 应用程序的示例日志：

# 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 的性能问题显然非常缓慢。（34 秒！）但是有了这些服务器日志，我知道对于 App1，我应该查看 @987654343 @，而对于 App2，我绝对需要调查 search/livesearch.js.haml。

提高前端性能

预算你的页面大小严格

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

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

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

图像加载是导致页面加载时间变慢的一个重要原因。在启动页面背景中使用的 5mb 大图像可以很容易地缩小到 200kb-400kb 大小，并且仍然具有足够高的质量，与更高分辨率的原始图像几乎没有区别。页面加载时间的差异将是巨大的。

您也应该对用户上传的图片进行同样的改进。例如。如果您网站的用户头像大小为 50 像素 x 50 像素，但用户为他的头像上传了 5mb 的图片，那么您提供的图片必须具有较小的文件大小和分辨率，以完全适合您网站上的显示方式。

Carrierwave、Fog 和 rmagick 是与 Amazon S3 一起使用以实现更好的图像加载的流行 gem。使用该软件包集合，您可以根据每个用户的屏幕尺寸动态地提供更小的图像分辨率。然后，您可以使用媒体查询，以便为移动设备提供比使用 Retina 屏幕的用户更小的分辨率尺寸的图像。

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

最后一点，您可以使用 Cloudfront 等内容交付网络 (CDN) 加快资产/图像加载时间。 CDN 将资产分布在许多服务器上，然后通过距离发出请求的用户最近的服务器向您的用户提供资产。

指纹静态资源

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

将 Javascript 文件移动到页面底部

页面底部的Javascript文件将在页面加载后加载。如果 javascript 资源位于页面顶部，那么当用户的浏览器尝试加载您的 javascript 文件时，页面将保持空白。幸运的是，如果您使用资产管道或使用 javascript_include_tag 指定 javascript 文件，Rails 会自动将 javascript 文件放置到页面底部。

编辑：大多数现代浏览器现在会自动优化 Javascript 加载，因此您几乎可以忽略此建议。

提高后端性能

缓存，缓存，缓存！

在所有后端性能优化中，缓存是产生显着性能提升的最有效方法之一。实施良好的缓存机制可以在高可扩展性期间极大地减少后端中低效查询的损害。经常访问但相对不经常更改的内容从缓存中获益最多。

缓存非常强大，它在生产中将上述 App2 的页面加载时间从 34 秒 降低到 不到一秒 .后端没有其他性能增强可以接近我们从缓存中获得的性能。

总体而言，在使用缓存进行性能优化时，先高后低。付出更少，收获更大。

从高到低，您可以使用的一些缓存类型是：

HTTP caching（不缓存你的服务器，但涉及到用户的浏览器通过读取HTTP头在本地缓存内容）
Page caching（内存缓存）
Action Caching（内存缓存）
Fragment caching (memcache) 或 Russian doll caching（一种受欢迎的片段缓存技术）
Model caching（内存缓存）

要了解有关缓存的更多信息，请从这里开始：http://guides.rubyonrails.org/caching_with_rails.html

索引一切

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

N+1 个查询

使用关系 (SQL) 数据库的 Rails 应用程序的主要性能杀手是N+1 queries。如果您在日志中看到您的应用程序正在为单个请求进行许多数据库读/写，那么这通常表明您有 N+1 个查询。 N+1 查询在开发过程中很容易遗漏，但会随着数据库的增长而迅速削弱您的应用程序（我曾经处理过一个有 12 个 N+1 查询的问题。在积累了大约 1000 行生产数据后，一些页面开始占用 超过一分钟加载）。

Bullet 是catching N+1 queries early as you develop your app. 的绝佳选择。在 Rails 应用程序中解决 N+1 个查询的简单方法是在必要时预先加载关联的模型。例如。如果您正在加载页面上每个帖子的所有 cmets，Post.all 将更改为 Post.includes(:comments).all。

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

新版本的 Rails 包含许多性能改进，可以加快您的应用程序（例如 Turbolinks）。

Ruby 2.1.x+ 包含比旧版本的 Ruby 更好的垃圾收集。目前已经发现有人升级的报道notable performance increases from upgrading.

我在这里遗漏了许多改进，但这些是我可以推荐的一些性能改进。有时间我会补充的。

【讨论】：