ruby-on-rails-3 - Rails的性能问题:如何发送gzip Assets

Question

我在生产环境中使用了Rails Asset Pipeline功能。我已经在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格式？

另外，请提出其他有助于改善站点性能的选项。

Answer 1

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

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

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

诊断问题：

YSlow / Google Page Speed

用于识别性能问题的有用的对角线工具是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，我应该调查clients/details.html.erb，对于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，并且仍然具有足够高的质量，与高分辨率的原始图像几乎没有区别。页面加载时间的差异会很大。

您也应该对用户上传的图片进行这些相同的改进。例如。如果您网站的用户头像尺寸为50px x 50px，但用户上传了5mb的头像，则必须以较小的文件大小和分辨率提供该图片，以使其完全适合您在网站上的显示方式。

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

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

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

指纹静态资产

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

将Javascript文件移到页面底部

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

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

改善后端性能

缓存，缓存，缓存！

在所有后端性能优化中，缓存是最有效的性能提升方法。良好实施的缓存机制可以在可伸缩性高的时期将后端内部效率低下的查询所造成的损害降到最低。经常访问但相对不频繁更改的内容从缓存中受益最大。

缓存功能如此强大，以至于在生产中将上述App2的页面加载时间从34秒减少到不到一秒。后端根本没有其他性能增强可以与我们从缓存中获得的性能接近。

总体而言，使用缓存进行性能优化时，请先从高位开始，然后再降低。您所获得的收益将以更少的努力获得更大的收益。

从高到低，您可以使用以下几种缓存类型：


HTTP caching（不缓存服务器，但涉及用户的浏览器通过读取HTTP标头在本地缓存内容）
Page caching（内存缓存）
Action Caching（内存缓存）
Fragment caching（内存缓存）或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查询在开发过程中很容易遗漏，但是随着数据库的增长，它会迅速削弱您的应用程序（我曾经处理过具有十二个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）。

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



我在这里缺少许多改进，但是这些是我可以推荐的一些性能改进。有空的时候我会增加更多。