仓酷云

 找回密码
 立即注册
搜索
热搜: 活动 交友 discuz
查看: 1181|回复: 9
打印 上一主题 下一主题

[其他Linux] 来看看:IIS的内容缓存过时机制理论 无效进步站点功能

[复制链接]
小妖女 该用户已被删除
跳转到指定楼层
楼主
发表于 2015-1-16 11:48:56 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
写学习日记,这是学习历程的见证,同时我坚持认为是增强学习信念的法宝。以上是我学习Linux的心得体会,希望对大家的学习有所帮助,由于水平有限,本文难免有所欠缺,望请指正。
我们的网站中常常包括大批的页面组件,好比图片、款式表文件、JS剧本文件和Flash动画。这些组件的变更频次十分低,特别是那些组成网站基础框架的组件,

几近不会产生变更。我们能够将这些变更率很低的组件看做静态内容,使用IIS的内容过时机制和扫瞄器的当地缓存机制将它们在会见者的电脑硬盘中保留一段工夫。

当会见者会见你的网站时,假如这些存在当地的静态内容没有过时,扫瞄器会从当地硬盘中装载,而不去处服务器收回哀求。

假如你利用Fiddler如许的工具跟踪网页会见,你会分明地看到固然只是会见一个页面,可是收回的Http哀求和应对却不止一个。网页中的每张图片,每一个

JS剧本文件,每一个CSS文件,城市激发一次哀求和应对。因而假如想让网页的会见速率快起来,削减Http的哀求数目,下降从服务器下载内容的次数是无效路子。

而利用了内容过时机制后能够就完成如许的目标,这就是利用内容过时机制的意义。

年夜多半的Web开辟者都玩过IIS6或IIS7,可是又有几人细心察看过HTTPHeaders或HTTPResponseHeaders标签中的内容呢?此处我以IIS6为例,

默许情形下此标签中的界面以下图:

此时,假如向该网站的一个网页收回哀求,该网页中包括了一张图片的链接,那末在猎取到该网页的HTML文档以后,扫瞄器会持续对这张图片收回哀求,该哀求的呼应在HttpResponseHeader中以下表达:

HTTP/1.1200ok(暗示服务器找到了此图片并准确呼应)

Date:Thu,04Feb201008:25:38GMT(呼应的工夫,格林尼治工夫)

Last-Modified:Wed,03Jan200901:55:06GMT(图片最初被修正的工夫,格林尼治工夫)

这张图片会被扫瞄器保留在当地硬盘的IE一时文件夹中。利用统一个扫瞄器窗口在统一个会话中再次会见到这个页面,
则页面中的组件都不再从头哀求。

当在这台呆板上翻开另外一个扫瞄器窗口(另外一个会话)又一次会见此页面时,因为这张图已在当地保留了,可是扫瞄器
方才的呼应中并没有划定内容的过时机制,因而扫瞄器仍会向服务器收回一次哀求:
If-Modified-Since:Wed,03Jan200901:55:06GMT(扣问服务器,我当地这张图片的最初修正工夫是这个,在此工夫以后你那有无更新的版本?)
If-None-Matched:"abdkfkdkdkdjkjkfkfd"(这是一段ETag编码,是服务器端给该组件的独一标示)

服务器收到哀求后反省被哀求的图片,发明它的比来修正工夫仍是Wed,03Jan200901:55:06GMT,因而呼应哀求:
HTTP/1.1304NotModified(哀求的图片找到了,而且没有被改动过)

Date:Thu,04Feb201008:25:38GMT(呼应的工夫)
扫瞄器收到这个呼应就晓得它能够宁神地利用当地存储的这张图片了,不用再从服务重视新下载该组件。

因而可知,IISHttpHeaders标签的默许设置是不由止扫瞄器缓存的,可是也没有告知组件保留过时的工夫,因而扫瞄器将组件保留在当地后,
每次会见城市扣问服务器此组件是不是过时,假如没过时则利用当地保留的内容,不然从服务器下载内容。能够看出它只削减了从服务器下载内容的次数,
并没有削减向服务器收回哀求的次数,哀求和呼应仍然泯灭了工夫。

在IIS中定位到网站寄存图片的文件夹,然后翻开属性窗口,在HTTPHeaders中做出以下选择,请求组件的过时工夫为本次哀求后1天,也就是在当地缓存86400秒。

翻开扫瞄器,初次会见该网站的一个网页,该网页中包括一张图片的链接,因而该图片哀求的呼应在HttpResponseHeader中以下表达:

HTTP/1.1200OK(暗示服务器找到了此图片并准确呼应)
Cache-Control:max-age=86400(从本次哀求工夫算起,同意该图片在当地缓存86400秒)

Date:Sat,14May201108:09:29GMT(呼应的工夫,格林尼治工夫)
因而,只需是在1天以内,利用本机的扫瞄器翻开这个网页,都不会再对这张图片收回哀求,而是间接利用当地缓存中的这张图片。可见,削减了不用要的HTTP哀求,

进步了网页的呼应速率。

良多网站框架性的组件都是临时稳定的,因而我们能够设置更长的过时工夫,以下所示:

翻开扫瞄器,初次会见该网站的一个网页,该网页中包括一张图片的链接,因而该图片哀求的呼应在HttpResponseHeader中以下表达:
HTTP/1.1200OK(暗示服务器找到了此图片并准确呼应)
Date:Sat,14May201108:50:12GMT(呼应的工夫,格林尼治工夫)
Expires:Mon,23May201116:00:00GMT(该图片的当地缓存到2011年5月23日16点为止,格林尼治工夫)
那末这意味着只需在5月23日16点之前,在本机上会见该网页,都不会再对此图片收回哀求。

有人忧虑假如如许设置过时机制,一旦对这些组件做了更新,会见者将不克不及收到变更,那岂不是也很遗憾。实在这有两方面的办理体例:
一方面是网站的开辟方,应当对图片,款式表文件和JS文件的定名体例举行改善,好比在文件名上到场版本号,如许你一旦修正了组件内容,
就应当使组件具有新的称号,因而扫瞄器会发明当地没有对这个组件缓存过,天然就会倡议哀求。
另外一方面,会见者能够经由过程扫瞄器的革新功效强迫对网页中的组件从头倡议哀求。即便设置了过时机制,扫瞄器的革新功效仍旧会对一切页面组件
收回哀求的。

总结,本文的目标就是阐释扫瞄器当地缓存与Web服务器缓存过时机制之间的交互干系,和怎样经由过程这类体例到达对功能的提拔。
依据《高功能网站建立指南》一书中的统计,从扫瞄器向一个网页收回哀求算起,取得网页的HTML文档的工夫只占全部页面应对完成工夫的
5%,而残剩的95%工夫全体是在哀求和下载页面中的各个组件。因而削减对页面中组件的哀求和下载,无效天时用扫瞄器缓存机制是非常成心义的。
要明白学好linux不是一件一蹴而就的事,一定要能坚持使用它,特别是在使用初期。
金色的骷髅 该用户已被删除
沙发
发表于 2015-1-17 20:13:16 | 只看该作者
linux鸟哥的私房菜,第三版,基础篇,网上有pdf下的,看它的目录和每章的介绍就行了,这个绝对原创!
兰色精灵 该用户已被删除
板凳
发表于 2015-1-21 10:40:11 | 只看该作者
对于英语不是很好的读者红旗 Linux、中标Linux这些中文版本比较适合。现在一些Linux网站有一些Linux版本的免费下载,这里要说的是并不适合Linux初学者。
变相怪杰 该用户已被删除
地板
发表于 2015-1-30 15:33:08 | 只看该作者
笔者五分钟后就给出了解决方法: “首先备份原文件到其他目录,然后删掉/usr/local/unispim/unispimsp.ksc,编辑 /usr/local/unispim/unispimsp.ini,最后重启动计算机
第二个灵魂 该用户已被删除
5#
发表于 2015-2-6 13:50:22 | 只看该作者
众所周知,目前windows操作系统是主流,在以后相当长的时间内不会有太大的改变,其方便友好的图形界面吸引了众多的用户。
小妖女 该用户已被删除
6#
 楼主| 发表于 2015-2-16 09:34:14 | 只看该作者
查阅经典工具书和Howto,特别是Howto是全球数以万计的Linux、Unix的经验总结非常有参考价值通常40%的问题同样可以解决。
若相依 该用户已被删除
7#
发表于 2015-3-5 04:18:13 | 只看该作者
下面笔者在论坛看到的一个好问题: “安装红旗4.0后,系统紫光输入法自带的双拼方案和我的习惯不一样,如何自定义双拼方案解决?谢谢?”这个问题很简练。
再见西城 该用户已被删除
8#
发表于 2015-3-11 23:38:26 | 只看该作者
掌握硬件配置,如显卡,声卡,网卡等,硬件只要不是太老或太新一般都能被支持,作为一名Linux系统管理员建议多阅读有关硬件配置文章,对各种不支持或支持不太好的硬件有深刻的了解。
海妖 该用户已被删除
9#
发表于 2015-3-19 16:23:16 | 只看该作者
学习Linux应具备的。[书籍+网络资源]
愤怒的大鸟 该用户已被删除
10#
发表于 2015-3-29 16:56:24 | 只看该作者
笔者五分钟后就给出了解决方法: “首先备份原文件到其他目录,然后删掉/usr/local/unispim/unispimsp.ksc,编辑 /usr/local/unispim/unispimsp.ini,最后重启动计算机
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|Archiver|手机版|仓酷云 鄂ICP备14007578号-2

GMT+8, 2024-12-23 10:34

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表