尽可能的缓存

转载 2012年03月27日 11:07:16

                                          尽可能的缓存

2012-03-27 08:54 | 212次阅读 | 来源:译言网  

关键词:缓存 | 作者:heavenhuang |

           转载自:http://sd.csdn.net/a/20120327/313562.html

Cache是如此的重要,但长期以来我们对它的认识存在着一些误区。作者Stevesouders通过HTTP Archive 收集的数据,发现在全球前5万的网站中,有46%的网站出现了cache配置不正确的问题,每天有多少流量就这样被白白浪费了?请阅读此文,并共同携手解决这个问题。

“最快的HTTP请求就是不要发起请求。”

我不记得是谁最早提出这个观点,在过去几年里我在无数次聚会和性能优化会议上反复听到这句话,没错! Cache是网站访问速度优化中重要的一环。我写了一些与此相关的内容:

在过去一年里,互联网对Cache的使用情况有所改善,但仍然不够快。以下的数据来自HTTP Archive 。我们可以看到,页面可缓存内容较去年增加不足10%,而与此同时,页面请求数增加了12%,页面的总传输体积增加了24%。

也许我们很难迅速的解决这个问题,因为这不仅仅是单方面的,而是涉及了网站开发、第三方提供商和浏览器开发者,但可以肯定的是我们必须做得更好,让更多的内容可以被缓存下来。

在过去的几周里,我收集了一些可靠的数据去证明合理使用Cache的重要性并指引下一步的优化工作:

  1. 55%的请求缺少 max-age 声明
  2. 46%的请求缺少 max-age 并且在2周内内容没有发生变化
  3. 一些在互联网上最流行的资源仅仅只缓存1-2小时
  4. 40%-60%的用户每天访问你的网站,但缓存无效。
  5. 30%的用户能够享受缓存带来的便利
  6. 对用户来说,合理的缓存更新时间应该是 4小时

最重要的一条规则:必须指定 max-age

我以前写过不少Cache优化相关的文章,但前提是你已经在Http头中对cache的使用进行声明。例如以下例子,请求将被缓存1年。

“Cache-Control: max-age=31536000”

因为你在阅读本文,所以你可能已经使用了max-age,但来自HTTP Archive 的数据表明 55%的资源并没有指定一个max-age。这表示重复访问一个网站,在81个资源中依然有45个资源需要发起新的http请求。

缺少 max-age != 动态

为什么有55%的资源没有指定 Cache信息?看着这来自世界各地数以千计的数据时,我第一个猜测是开发者缺乏对缓存的认识,另外一个猜测是他们认为那些资源是动态的不需要缓存(JSON,广告,标记等)。究竟是哪个原因导致的呢?幸好我们可以量化这些数据,并从中找出这些没有被Cache的内容有多少是真正动态的。

HTTP Archive 分析了全球前5万名的网站页面,在每月1号和15号记录下页面中每个请求的信息。使用这些历史记录对比,我们就能找到本月15号和上一个月15号之间,那些内容没有发生改变,或者再向前推1一个月。HTTP Archive的分析是基于相同的URL,Last-Modified,ETag和Content-Length。

46%缺少max-age的请求在过去至少2周的时间里内容没有发生改变,这表示在上文提到45个缺少max-age的请求中有21个资源是应该从缓存访问但实际上没有。超过一个月内容没有发生变化的有38%,也就是有17个资源出现了上述的问题。

这是严重的失职,以下是一些主流网站中出现缺少max-age声明的资源数量:

回顾上面提到的:“最快的HTTP请求就是不要发起请求”,这是很多不必要的流量。鉴于可缓存与非缓存内容之比,在过去一年里没有什么变化,我相信缺少max-age和资源的内容相关性不大,而是因为人们对Cache缺乏认识。

第三方内容

如果一个网站所有者不让他的资源能够被缓存,那是在伤害他自己和用户。对于第三方内容提供商来说,这有正反两面,如果他们没有做cache,受影响的是所有使用他们服务的网站,如果他们做好了则会放大效应。

以下是30个最常用第三方资源列表:

  1. http://www.google-analytics.com/ga.js(2小时)
  2. http://ssl.gstatic.com/s2/oz/images/stars/po/Publisher/sprite2.png(8760小时)
  3. http://pagead2.googlesyndication.com/pagead/js/r20120208/r20110914/show_ads_impl.js(336小时)
  4. http://pagead2.googlesyndication.com/pagead/render_ads.js(336小时)
  5. http://pagead2.googlesyndication.com/pagead/show_ads.js(1小时)
  6. https://apis.google.com/_/apps-static/_/js/gapi/gcm_ppb,googleapis_client,plusone / [...](720小时)
  7. http://pagead2.googlesyndication.com/pagead/osd.js(24小时)
  8. http://pagead2.googlesyndication.com/pagead/expansion_embed.js(24小时)
  9. https://apis.google.com/js/plusone.js(1小时)
  10. http://googleads.g.doubleclick.net/pagead/drt/s?safe=on(1小时)
  11. http://static.ak.fbcdn.net/rsrc.php/v1/y7/r/ql9vukDCc4R.png(3825小时)
  12. http://connect.facebook.net/rsrc.php/v1/yQ/r/f3KaqM7xIBg.swf(164小时)
  13. https://ssl.gstatic.com/s2/oz/images/stars/po/Publisher/sprite2.png(8760小时)
  14. https://apis.google.com/_/apps-static/_/js/gapi/googleapis_client,iframes_styles [...](720小时)
  15. http://static.ak.fbcdn.net/rsrc.php/v1/yv/r/ZSM9MGjuEiO.js(8742小时)
  16. http://static.ak.fbcdn.net/rsrc.php/v1/yx/r/qP7Pvs6bhpP.js(8699小时)
  17. https://plusone.google.com/_/apps-static/_/ss/plusone/ [...](720小时)
  18. http://b.scorecardresearch.com/beacon.js(336小时)
  19. http://static.ak.fbcdn.net/rsrc.php/v1/yx/r/lP_Rtwh3P-S.css(8710小时)
  20. http://static.ak.fbcdn.net/rsrc.php/v1/yA/r/TSn6F7aukNQ.js(8760小时)
  21. http://static.ak.fbcdn.net/rsrc.php/v1/yk/r/Wm4bpxemaRU.js(8702小时)
  22. http://static.ak.fbcdn.net/rsrc.php/v1/yZ/r/TtnIy6IhDUq.js(8699小时)
  23. http://static.ak.fbcdn.net/rsrc.php/v1/yy/r/0wf7ewMoKC2.css(8699小时)
  24. http://static.ak.fbcdn.net/rsrc.php/v1/yO/r/H0ip1JFN_jB.js(8760小时)
  25. http://platform.twitter.com/widgets/hub.1329256447.html(87659小时)
  26. http://static.ak.fbcdn.net/rsrc.php/v1/yv/r/T9SYP2crSuG.png(8699小时)
  27. http://platform.twitter.com/widgets.js(1小时)
  28. https://plusone.google.com/_/apps-static/_/js/plusone/ [...](720小时)
  29. http://pagead2.googlesyndication.com/pagead/js/graphics.js(24小时)
  30. http://s0.2mdn.net/879366/flashwrite_1_2.js(720小时)

一些有趣的特征:

  • 越简单的url缓存时间越短。
  • 越长的url缓存时间越长。
  • 短缓存的脚本往往是异步的。

这些受欢迎的第三方资源在缓存方面都表现得不错,但是我们如果把第三方widget考虑在内的话整体评价需要降级,另外第三方供应商需要更好的支持异步脚本,避免对页面造成阻塞。

Cache的容量太小

在2007年,我和Tenni Theurer在Yahoo!做了一个实验,通过在页面底部插入一个1x1的透明图片并且把过期时间设在了过去的时间,这样当用户从缓存访问了这个文件,我们将收到一个 304的请求,而如果用户没有缓存这个文件,我们则会收到一个200请求。我们惊讶的发现,有40%-60%的活跃用户访问我们的网站而没有cache,20%的pv访问同样不带cache。

有许多因素导致用户访问无cache的比例过高,但我相信主要的原因是因为浏览器的缓存容量限制太小了。自这个2007年以来,浏览器厂商已纷纷修改了他们的浏览器缓存容量限制,但这还不够。我们很难对浏览器cache容量限制进行统计,Blaze.io’s 的文章 Understanding Mobile Cache Sizes中提供了一些测试数据。而我在我的MacBook Air上测得了如下数据(有些浏览器的缓存容量限制是基于磁盘的可用空间,我的测试环境是250GB磁盘中有54GB可用。

  • Chrome: 320 MB
  • Internet Explorer 9: 250 MB
  • Firefox 11: 830 MB (shown in about:cache)
  • Opera 11: 20 MB (shown in Preferences | Advanced | History)
  • iPhone 4, iOS 5.1: 30-35 MB (based on testing)
  • Galaxy Nexus: 18 MB (based on testing)

我很惊讶的发现 FF 11居然有如此之大的缓存,几乎满足我所有的需要了,其他则显得太小了。在我的移动设备上仅仅只有18-35M的缓存,我有7部电影在我的iphone中,我很愿意把钢铁侠2的1.82G换取更多的缓存空间。

真实的缓存情况

我需要一些统计数据来证明,有多少用户因为缓存溢出而失去网站的缓存。在上个月的 Velocity Summit 中有来自Chrome, Internet Explorer, Firefox, Opera, Silk的代表(Safari受邀但没有来。来自Chrome SPDY小组的Will Chan分享在window chromes上收集到最翔实的cache统计数据)

  • 约30%的用户cache已满(320MB)
  • 用户主动访问约4小时将填满他们cache
  • 7%用户每周最少清空cache一次
  • 19%用户至少每周一次因为缓存内容被释放导致cache无效

最后一点比较有意思,IE9的开发团队也遇到了类似的问题, IE7&8的缓存大小限制是50MB,这是基于他们的测试验证缓存大小和缓存命中率无关。但是当他们在IE9开发过程中重新仔细审视这一测试时发现了不同的结论:

“在IE9开发过程中,我们非常重视缓存的设计。经过仔细的观察我们发现之所以IE7&8测试中发现缓存大小和命中率无关是因为 此前对可缓存内容及清理缓存的算法功能上有缺陷,修复这些问题后,我们发现缓存大小确实与缓存命中率相关,基于这结论,我们已调整了cache容量限制算法,提供比过去更大的cache空间。”

Will提到 Chrome 将重新考虑320MB的容量上限,30%用户cache已满似乎比例不高,但考虑到很多非常积极的和活跃用户主要集中访问少数网站(例如只访问 gmail, facebook, twitter)。如果有可能的话我想看到这些用户行为和cache的相关性统计。

下一步工作

以上的数据大部分来自 HTTP Archive,所以要感谢我们的赞助商:sponsors:Google, Mozilla, New Relic, O’Reilly Media, Etsy, Strangeloop, dynaTrace Software, and Torbit

这些数据集表明了问题主要集中在以下几个方面:

网站开发者:需要更多的使用Cache-Control max-age,以及设置更长的有效时间。38%的资源在1个月内无变化,却只有11%资源有指定max-age。大部分资源的更新可以通过改变url的时间戳实现。只有第三方提供的脚本引用片段适合使用短的cache时间(小时),真正需要每次动态访问的内容(JSON等)应该在请求中指定:must-revalidate。 希望一年后,我们能看到55%的资源可以被cache 一个月以上的时间,而不是55%资源没有指定max-age。

第三方开发者:需要更好的使用缓存和仿效Google,Twitter,Facebook的异步脚本片段。

浏览器开发者:需要提供更大的cache容量限制,尤其是在移动设备上。需要考虑cache清除算法和用户行为的关联(例如我经常访问的网站),也许能在用户访问他们喜欢的网站时提供更好的访问速度。

去年,HTTP请求数增长超过了10%,而cache则增长过慢。明年我们迫切的期望能看到资源的cache命中率增加一倍,试想一下,这能避免多少HTTP请求,节省多少流量?

文章出自:译言网

砝码称重 5个砝码 用天平称重时,我们希望用尽可能少的砝码组合称出尽可能多的重量。

/*砝码称重 5个砝码 用天平称重时,我们希望用尽可能少的砝码组合称出尽可能多的重量。 如果只有5个砝码,重量分别是1,3,9,27,81。则它们可以组合称出1到121之间任意整数重量(砝码允许放在左...
  • hanshileiai
  • hanshileiai
  • 2013年04月17日 13:24
  • 2609

Nginx - 代理、缓存

Nginx标签 : nginx代理代理服务可简单的分为正向代理和反向代理: 正向代理: 用于代理内部网络对Internet的连接请求(如VPN/NAT),客户端指定代理服务器,并将本来要直接发送给目标...
  • hanqing280441589
  • hanqing280441589
  • 2016年05月25日 20:24
  • 14938

简要比较线性表的顺序存储结构和链式存储结构

我们分别从存储分配方式、时间性能、空间性能三方面来做对比。 存储分配方式: 顺序存储结构用一段连续的存储单元依次存储线性表的数据元素。 单链表采用链式存储结构,用一组任意的存储单元存放线性表的元素。...
  • wxwd1
  • wxwd1
  • 2014年05月13日 14:07
  • 2076

优化网站设计(十四):使AJAX调用尽可能利用缓存特性

前言 网站设计的优化是一个很大的话题,有一些通用的原则,也有针对不同开发平台的一些建议。这方面的研究一直没有停止过,我在不同的场合也分享过这样的话题。 作为通用的原则,雅虎的工程师团队曾经...
  • feiyangbaxia
  • feiyangbaxia
  • 2015年01月05日 11:38
  • 400

如何优化VBA代码并使程序尽可能快的运行

  • 2013年11月18日 18:27
  • 341KB
  • 下载

java版简单hash表,占用内存尽可能最小

  • 2013年12月04日 09:31
  • 2KB
  • 下载

Image Optimizer ActiveX Control 允许你建立尽可能最小的JPG和P

  • 2006年02月23日 09:05
  • 435KB
  • 下载

eclipse 黑色主题安装工具包 绿色版 能够尽可能的达到类似Idea的主题样式

  • 2017年10月27日 15:21
  • 8KB
  • 下载

Lecture Halls 假设要在足够多的会场里安排一批活动,并希望使用尽可能少的会场。设计一个有效的算法进行安排。(这个问题实际上是著名的图着色问题。若将每一个活动作为图的一个顶点,不相容活动间用边相连。使相邻顶点着有不同颜色的最小着色数,相应于要找的最小会场数。)

  • 2009年05月11日 18:07
  • 2KB
  • 下载

最优装载 有一批集装箱要装上一艘载重量为c的轮船。其中集装箱i的重量为Wi。最优装载问题要求确定在装载体积不受限制的情况下,将尽可能多的集装箱装上轮船。

  • 2009年05月11日 15:57
  • 1KB
  • 下载
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:尽可能的缓存
举报原因:
原因补充:

(最多只允许输入30个字)