缓存策略

一、前言

缓存思想是计算机领域最伟大的思想之一,缓存对web应用有多重要,大家可以百度一下雅虎前端性能优化军规,看看启用缓存的排序有多靠前。对服务端而言缓存也异常重要,memcache已经变成互联网产品的标配,缓存服务器一旦停止工作,大量获取数据的请求涌入数据库导致数据库运行缓慢,进而导致整个系统响应缓慢甚至崩溃,这就是“雪崩现象”。当然,今天我们要聊的主要是前端静态资源服务器应该采用的缓存策略。

 

二、常见的缓存策略

(1)Expires 设置失效时间,精确到时分秒

(2)Cache-Control: max-age,最大存活时间,单位为秒

(3)Last-Modified,文件修改时间

(4)E-Tag,针对文件内容生产的hash字符串用于唯一标识文件

三、根据用户请求资源的方式,浏览器与web服务器将启用不同的策略

  1. 正常请求。web前端根据版本号组装完整的URL,浏览器判断该URL是否有缓存,如果有缓存且缓存未失效,则直接返回缓存副本;缓存失效,则发送新的HTTP请求,服务器获取最新的文件,并设置缓存策略:Expires、Cache-Control: max-age、Last-Modified,最后以状态码200响应浏览器,浏览器缓存该文件后展现文件。具体流程如下:

  1. 用户刷新页面。如果用户刷新页面,则不管浏览器的缓存是否有效,总是会发送新的HTTP请求,服务器将根据请求头部If-Modified-Since决定是否获取最新的文件,如果If-Modified-Since的时间与文件的修改时间一致,则响应304,响应体为空,浏览器将采用缓存副本展现;如果If-Modified-Since的时间与文件的修改时间不一致,则服务器获取最新的文件,并设置该文件的缓存头部,响应200。具体流程如下:

通常有用户投诉某个功能无法使用时,我们提示用户请刷新一下页面,如果你的web服务器设置了Last-Modified 或者 E-Tag,仅刷新是没用的,必须清空浏览器缓存,如何清缓存,不同浏览器用不同的途径,对于前端工程师而言无需多讲。

四、同时设置Expires与 Cache-Control: max-age

为了解决服务端与客户端时钟不一致的问题我们需要设置Cache-Control: max-age 。需要注意的是HTTP1.0不支持Cache-Control: max-age,所以我们还需要设置Expires。对于同时支持Expires与 Cache-Control: max-age的浏览器,Cache-Control: max-age将覆盖Expires

五、慎用E-Tag

Etag的格式与web容器是耦合的,站点在服务器集群(多种web容器)下导致Etag值不一致,命中率很低。两种解决方案:

1、禁用Etag

2、自定义Etag

六、参考资料

《高性能JavaScript》

《高性能网站建设指南》

《HTTP权威指南》

时间: 2024-10-25 05:47:33

缓存策略的相关文章

【腾讯Bugly干货分享】彻底弄懂 Http 缓存机制 - 基于缓存策略三要素分解法

本文来自于腾讯Bugly公众号(weixinBugly),未经作者同意,请勿转载,原文地址:https://mp.weixin.qq.com/s/qOMO0LIdA47j3RjhbCWUEQ 作者:李志刚 导语 Http 缓存机制作为 web 性能优化的重要手段,对从事 Web 开发的小伙伴们来说是必须要掌握的知识,但最近我遇到了几个缓存头设置相关的题目,发现有好几道题答错了,有的甚至在知道了正确答案后依然不明白其原因,可谓相当的郁闷呢!!为了确认下是否只是自己理解不深,我特意请教了其他几位小伙

Web缓存基础:术语、HTTP报头和缓存策略

简介 对于您的站点的访问者来说,智能化的内容缓存是提高用户体验最有效的方式之一.缓存,或者对之前的请求的临时存储,是HTTP协议实现中最核心的内容分发策略之一.分发路径中的组件均可以缓存内容来加速后续的请求,这受控于对该内容所声明的缓存策略. 在这份指南中,我们将讨论一些Web内容缓存的基本概念.这主要包括如何选择缓存策略以保证互联网范围内的缓存能够正确的处理您的内容.我们将谈一谈缓存带来的好处.副作用以及不同的策略能带来的性能和灵活性的最大结合. 什么是缓存(caching)? 缓存(cach

网络图片的获取以及二级缓存策略(Volley框架+内存LruCache+磁盘DiskLruCache)

在开发安卓应用中避免不了要使用到网络图片,获取网络图片很简单,但是需要付出一定的代价——流量.对于少数的图片而言问题不大,但如果手机应用中包含大量的图片,这势必会耗费用户的一定流量,如果我们不加以处理,每次打开应用都去网络获取图片,那么用户可就不乐意了,这里的处理就是指今天要讲的缓存策略(缓存层分为三层:内存层,磁盘层,网络层). 关于缓存层的工作,当我们第一次打开应用获取图片时,先到网络去下载图片,然后依次存入内存缓存,磁盘缓存,当我们再一次需要用到刚才下载的这张图片时,就不需要再重复的到网络

Hibernate(四)——缓存策略+lazy

Hibernate作为和数据库数据打交道的框架,自然会设计到操作数据的效率问题,而对于一些频繁操作的数据,缓存策略就是提高其性能一种重要手段,而Hibernate框架是支持缓存的,而且支持一级和二级两种缓存,合理的使用缓存策略可以大大提高我们的操作数据效率,但是利用不能,可能会造成不必要的麻烦.  一,一级缓存(Session缓存):  Session缓存表示将查询结果放置到Session的临时存储空间(一级缓存中).Hibernate框架默认支持一级缓存的.一级缓存的范围较小,一旦Sessio

HTTP1.1缓存策略

以下是一幅虽然信息包含量有限.但足够以最简洁的方式说明了“什么是HTTP1.1缓存策略”的图  缓存和缓存策略 web缓存(web cache)或代理缓存(proxy cache)是一种特殊的HTTP代理服务器.缓存减少了冗余数据的传输.缓解带宽瓶颈. 降低距离时延. 缓存策略就是在采用缓存的情况,client.proxy cache.server三者是如何协同工作,实现正确且快速的数据传递. 在介绍缓存策略前,我们需要先明确的概念 (a)缓存命中 (b)缓存未命中 (c)缓存再验证命中 出现以

浏览器缓存策略

浏览器一般缓存图片.CSS.JS等静态文件,因为这些文件的更新频率相对来说比较低,合理利用浏览器的缓存对网站的性能提升有很大帮助.HTTP缓存分为两部分,分别是本地缓存和缓存协商,当本地缓存不生效时会启用缓存协商.HTTP缓存主要由HTTP协议的头(Header)信息来制定. 本地缓存 本地缓存是指当浏览器请求资源时,如果命中了浏览器本地的缓存资源,那么浏览器就不会发送真正请求给服务器.它的执行过程是:1. 第一次浏览器发送请求给服务器时,此时浏览器还没有本地缓存副本,服务器返回资源给浏览器,响

NSURLRequestCachePolicy 缓存策略

1> NSURLRequestUseProtocolCachePolicy = 0, 默认的缓存策略, 如果缓存不存在,直接从服务端获取.如果缓存存在,会根据response中的Cache-Control字段判断下一步操作,如: Cache-Control字段为must-revalidata, 则询问服务端该数据是否有更新,无更新的话直接返回给用户缓存数据,若已更新,则请求服务端. 2> NSURLRequestReloadIgnoringLocalCacheData = 1, 忽略本地缓存数

对Hibernate缓存策略的理解和应用

引自:http://www.blogjava.net/frostwood/archive/2010/01/06/308465.html Hibernate提供了三个级别的缓存策略:Session缓存(基本的事务级缓存),Query Cache(查询缓存),Seond-Level Cache(二级缓存) Session缓存(First-Level Cache):Session是Hibernate用于管理持久化对象的核心机制,它是针对持久性数据的事务级缓存.PersistenceContext中包括

图片缓存策略

图片缓存策略 1.图片缓存策略分析 从网络上加载一张图,然后把它显示到UI上是个很简单的事情.当图片变多时,处理起来就有些麻烦了,很典型的应用场景,如ListView,GridView或者ViePager等.我们既需要保证用户看到更多的图片,以免屏幕出现大面积的空白,又要保证内存能Hold住. GC会自动释放一个没有强引用的图片或者View,这本来是个好事情,但为了让用户来回滚动时还能快速加载老图片,通常会使用图片缓存. 下面分别讨论下,通过使用Memory Cache和Disk Cache来增

Android 开源框架Universal-Image-Loader完全解析(二)--- 图片缓存策略详解

本篇文章继续为大家介绍Universal-Image-Loader这个开源的图片加载框架,介绍的是图片缓存策略方面的,如果大家对这个开源框架的使用还不了解,大家可以看看我之前写的一篇文章Android 开源框架Universal-Image-Loader完全解析(一)--- 基本介绍及使用,我们一般去加载大量的图片的时候,都会做缓存策略,缓存又分为内存缓存和硬盘缓存,我之前也写了几篇异步加载大量图片的文章,使用的内存缓存是LruCache这个类,LRU是Least Recently Used 近