不管访问多少次,X-Cache 始终是 MISS,X-Swift-CacheTime 也一直为 0。
X-Cache 为 MISS,X-Swift-CacheTime 为 0,CDN不缓存。
X-Cache 为 MISS,X-Swift-CacheTime 为 0,CDN不缓存。
X-Cache 为 MISS,X-Swift-CacheTime 为 0,CDN不缓存。
试下能否正常被CDN缓存。
X-Cache 变成了 HIT,X-Swift-CacheTime 变成了 300,也就是CDN缓存5分钟。
缓存规则权重不同,有两条缓存规则,其中 /static/ 目录类型的权重最大,意味着优先级最高。
请求 /static/ 目录下 html 后缀的文件,看下匹配到哪条规则?
X-Swift-CacheTime: 120,这是匹配到了 /static/ 目录类型的规则。
缓存规则权重相同, html 文件后缀名的规则创建时间最早,正常情况应该是匹配到该条规则。
X-Swift-CacheTime: 300,确实匹配到了 html 文件后缀名规则。
CDN不要设置缓存规则,然后nginx配置内容如下,Cache-Control设置为60秒,Expires设置为120秒。
源站响应头部有 Cache-Control 、 Expires 、 Last-Modified 、 ETag ,测试看看哪个优先级最高。
X-Swift-CacheTime: 60,Cache-Control 的优先级高一些。
在nginx配置中将 add_header Cache-Control "max-age=60" 去掉再试试。
X-Swift-CacheTime: 120,缓存规则是用 Expires 的时间了。
去掉nginx配置中的 expires 120s。
X-Swift-CacheTime 会随着时间变化,这是因为缓存过期了,CDN重新去源站拉取,然后重新计算缓存过期时间。
ok,最后一步,将 Last-Modified 响应头部给干掉。
只有 Etag 响应头部,不管访问几次,依旧是 X-Swift-CacheTime: 10。
将4个响应头部都干掉,看下CDN是否会缓存。
多次测试始终是 X-Cache: MISS 和 X-Swift-CacheTime: 0,这说明如果这4个响应头部都没了,CDN是不缓存的。
网上查了下资料,回源大致是指浏览器在发送请求报文时,响应该请求报文的是源站点的服务器,而不是各节点上的缓存服务器,那么这个过程相对于通过各节点上的缓存服务器来响应的话就称作为回源。回源的请求或流量太多的话,有可能会让源站点的服务器承载着过大的访问压力,进而影响服务的正常访问。
其实回源比和缓存的命中率正好相反,回源比高,说明缓存系统的缓存命中率低。回源比分为回源请求数比例和回源流量比例两种。
回源请求数比例 :收集所有边缘节点上的请求记录,没有缓存或缓存过期的请求以及不可缓存的请求均被作为回源请求,发往源站点服务器响应。其他的请求则由缓存系统直接使用缓存响应。其计算公式为: 回源请求数/(回源请求数+用户发送的请求数) 。
回源流量比 :即用户所产生的流量当中,有多少流量是直接有源站点服务器响应的,其计算公式为: 回源流量/(回源流量+用户请求访问的流量)
CDN,即Content Delivery Network,内容分发网络,其搭建的思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节,尽量使内容传输的更快更稳定。CDN通过在网络边缘部署边缘服务器,依靠CDN中心平台的负载均衡、内容分发及调度等功能,使用户就近获取所需的内容,降低网络拥堵,提高用户访问响应速度和命中率。所以基本上CDN就是广泛采用各种缓存服务器,使得用户的请求直接由这些缓存服务器响应,加快了响应速度;只有在用户请求的资源在缓存服务器上没有找到或者请求访问的资源在源站点服务器上已经修改过的情况下,缓存服务器才会去访问源站点服务器以获取最新的资源。
下图为常见的CDN架构:
在CDN环境下,web访问数据通常会经历客户端本地缓存和CDN边缘节点缓存两个阶段。如果这两个阶段均无法响应客户的请求的话,那么最后会由CDN节点向源站点发起回源请求,进而从源站点获取最新的数据,更新CDN节点的本地缓存,最后将最新的数据返回给客户端。
CDN节点的缓存机制也是遵循http协议,因此也会受到Cache-Control等字段的影响。与此同时,CDN上的缓存时间的长短会对回源率产生直接的影响。若CDN缓存时间较短,CDN边缘节点上的数据会经常失效,导致频繁回源,增加了源站的负载,同时也增大的访问延时;若CDN缓存时间太长,会带来数据更新时间慢的问题。因此开发者需要增对特定的业务,来做特定的数据缓存时间管理。
欢迎分享,转载请注明来源:夏雨云
评论列表(0条)