San*_*khe 2 performance gzip nginx ruby-on-rails-3 angularjs
我在生产环境中使用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格式出现？
另外,请建议任何其他有助于提高网站性能的选项.
不能直接回答你的第一个问题(如果你解决了,请解释),但为了提高网站性能,请记住Perfomance Golden Rule:
最终用户响应时间的80-90%用于前端.从那里开始.
下面是一个非详尽的列表,可以在Rails应用程序中提高性能:
用于识别性能问题的有用的诊断工具是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/Images).因此,请考虑您的页面大小,如预算.例如,Hootesuite最近声明他们的主页现在有一个严格的页面大小预算为1 MB.没有例外.现在看看他们的页面.很快就不是吗？
减少页面大小的简单方法包括删除未使用的JS或CSS文件,仅在需要时包括它们,并将静态图像更改为更小的向量.
图像加载是页面加载时间缓慢的一个重要原因.在启动页面背景中使用的大型5mb图像可以很容易地降低到200kb-400kb的尺寸,并且仍然具有足够高的质量,几乎与高分辨率原件无法区分.页面加载时间的差异将是巨大的.
您也应该对用户上传的图像进行相同的改进.例如,如果您网站的用户头像尺寸为50像素×50像素,但用户为其头像上传了5毫安图像,那么您必须以较低的文件大小和分辨率提供图像,以准确显示其在您网站上的显示方式.
Carrierwave,Fog和rmagick是Amazon S3使用的流行宝石,可实现更好的图像加载.使用该软件包集合,您可以根据每个用户的屏幕大小动态提供较小的图像分辨率.然后,您可以使用媒体查询,以便与使用Retina屏幕的用户相比,为移动设备提供较小分辨率的图像.
再加上最后一点,您可以使用Cloudfront等内容交付网络(CDN)加快资产/图像加载时间.CDN在许多服务器上分配资产,然后通过最靠近发出请求的用户的服务器为您的用户提供资产.
当静态资产被指纹识别时,当用户访问您的页面时,他们的浏览器将缓存这些资产的副本,这意味着他们不再需要为下一个请求重新加载它们.
放置在页面底部的Javascript文件将在页面加载后加载.如果javascript资源放在页面顶部,那么当用户的浏览器尝试加载您的javascript文件时,页面将保持空白.幸运的是,如果您使用资产管道或使用指定javascript文件,Rails将自动将javascript文件放在页面底部javascript_include_tag.
编辑:大多数现代浏览器现在自动优化Javascript加载,所以你可以大多忽略这个建议.
在所有后端性能优化中,缓存是产生显着性能提升的最有效方法之一.在高可伸缩性期间,良好实施的缓存机制可以极大地减少后端内低效查询的损害.频繁访问但相对不频繁更改的内容从缓存中获益最多.
缓存非常强大,它将上面提到的App2的页面加载时间从34秒降低到不到一秒的生产时间.后端上没有其他性能增强,甚至可以接近我们从缓存中获得的内容.
总的来说,在使用缓存进行性能优化时,从高处开始然后再进入低位.您将获得的收益将更大,以减少工作量.
从高到低,您可以使用某些类型的缓存:
要了解有关缓存的更多信息,请从这里开始:http://guides.rubyonrails.org/caching_with_rails.html
如果要将SQL用于数据库层,请确保在连接表上指定索引,以便更快地查找经常使用的大型关联.您必须在迁移期间显式添加它们,因为Rails中默认不包含索引.
使用关系(SQL)数据库的Rails应用程序的主要性能杀手是N + 1个查询.如果您在日志中看到您的应用程序为单个请求进行了许多数据库读/写操作,那么通常表明您有N + 1个查询.在开发过程中很容易错过N + 1个查询,但随着数据库的增长,可能会迅速削弱您的应用程序(我曾经处理了一个有12个N + 1查询的查询.在累积了大约1000行的生产数据之后,一些页面开始接管一个分钟加载).
Bullet是您在开发应用程序时尽早捕获N + 1个查询的绝佳宝石. 在Rails应用程序中解析N + 1查询的一种简单方法是在必要时急切加载相关的模型.例如 Post.all,Post.includes(:comments).all如果要加载页面上每个帖子的所有注释,请进行更改.
较新版本的Rails包含许多性能改进,可以加快您的应用程序(例如Turbolinks).
Ruby 2.1.x +包含比旧版Ruby更好的垃圾收集.到目前为止,人们升级的报告发现,升级后性能显着提升.
我在这里遗漏了许多改进,但这些是我可以推荐的一些性能改进.我有时间的时候会增加更多.