仓酷云

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

[学习教程] ASP.NET网站制作之一个陪伴ASP.NET从1.0到4.0的OutputCache Bug仓酷云

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

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

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

x
net网页编程的设计机制:首先产生一个中间码,第二部编译为本地(机器)码。这个机制有很大的缺点。我们先来一睹这个Bug的风度!
在一个.aspx文件中增添OutputCache设置,代码以下:
  1. <%@OutputCacheDuration="300"VaryByParam="*"%>
复制代码
下面的设置暗示:缓存5分钟,依据分歧的查询字符串更新缓存。Location利用的是默许值Any,也就是能够在扫瞄器、代办署理服务器、Web服务器三个中央举行缓存,在ResponseHeaders中的表现就是Cache-Control:public,max-age=300。(假如你要用CDN减速,Cache-Control就要用public)。
然后,我们在Firefox扫瞄器中会见这个页面,并翻开Firebug,见下图:

第一次会见,前往形态码为"200OK",一般。这里ResponseHeaders中的Vary:Accept-Encoding是由于IIS启用“静态内容紧缩”发生的,假如不启用,就不会呈现。
这时候缓存应当被创建起来了,我们按F5革新一下扫瞄器,看一下了局,见下图:

第二次会见,前往形态码为"304NotModified",扫瞄器缓存失效,这也是我们希冀的。
可是,请注重一下上图中的Vary:*,它会让扫瞄器的缓存生效,我们再按一下F5考证一下。

公然,扫瞄器缓存生效,前往形态码变回了200OK。缓存工夫有5分钟呢,第三次就生效了,如许的了局明显不是我们希冀的。
下面的测试是在Web服务器上IIS启用静态内容紧缩(dynamiccontentcompression)的情形下举行的,假如封闭静态内容紧缩,每次哀求前往都是200OK,Vary都是星号。也就是说扫瞄器巡游缓存基本没起感化。
Bug浏览终了,我们举行第二个测试。
将OutputCache的VaryByParam属性值设置为none:
  1. <%@OutputCacheDuration="600"VaryByParam="none"%>
复制代码
测试了局显现,扫瞄器第一次哀求以后,接上去在缓存工夫内,服务器的呼应都是"304NotModified",这才是我们想要的效果。

可是,在实践使用中,我们利用VaryByParam="none"很少,用的更多的是为VaryByParam指定对应的值。
以是这个Bug影响很年夜,增添了服务器包袱,华侈了带宽。
Bug相干信息
在微软的官方文档ASP.NET4BreakingChanges中专门提到了这个bug——"OutputCachingChangestoVary*HTTPHeader":
InASP.NET1.0,abugcausedcachedpagesthatspecifiedLocation="ServerAndClient"asanoutput&ndash;cachesettingtoemitaVary:*HTTPheaderintheresponse.Thishadtheeffectoftellingclientbrowserstonevercachethepagelocally.
InASP.NET1.1,theSystem.Web.HttpCachePolicy.SetOmitVaryStarmethodwasadded,whichyoucouldcalltosuppresstheVary:*header.ThismethodwaschosenbecausechangingtheemittedHTTPheaderwasconsideredapotentiallybreakingchangeatthetime.However,developershavebeenconfusedbythebehaviorinASP.NET,andbugreportssuggestthatdevelopersareunawareoftheexistingSetOmitVaryStarbehavior.
InASP.NET4,thedecisionwasmadetofixtherootproblem.TheVary:*HTTPheaderisnolongeremittedfromresponsesthatspecifythefollowingdirective:
<%@OutputCacheLocation="ServerAndClient"%>
Asaresult,SetOmitVaryStarisnolongerneededinordertosuppresstheVary:*header.
InapplicationsthatspecifyLocation="ServerAndClient"inthe@OutputCachedirectiveonapage,youwillnowseethebehaviorimpliedbythenameoftheLocationattributesvalue&ndash;thatis,pageswillbecacheableinthebrowserwithoutrequiringthatyoucalltheSetOmitVaryStarmethod.
从下面的文档中我们能够晓得这个Bug的汗青:
在ASP.NET1.0时,假如在OutputCache中设置Location="ServerAndClient",在ASP.NET在呼应时会扫瞄器发送Vary:*HTTPheader。
在ASP.NET1.1时,微软针对这个Bug,供应一个专门的办法System.Web.HttpCachePolicy.SetOmitVaryStar(boolomit),经由过程SetOmitVaryStar(true)修正HTTPheader,往失落Vary:*。
在ASP.NET4时,微软慎重地公布从基本上办理了这个成绩。
并且,文档中提到这个bug只会呈现在Location="ServerAndClient"时。
但是,我用ASP.NET4的实测试情形是:不但Location="ServerAndClient"时的Bug没有办理,并且Location="Any"时也会呈现一样的Bug。
办理办法
办理办法很复杂,只需用ASP.NET1.1时期供应的System.Web.HttpCachePolicy.SetOmitVaryStar(boolomit)就可以办理成绩,只需在Page_Load中增加以下代码:
  1. protectedvoidPage_Load(objectsender,EventArgse){Response.Cache.SetOmitVaryStar(true);}
复制代码
相干文档
ASP.NETcachingtestsfindabugwithVaryByParam
Howtocacheasp.netwebsiteforbetterperformance
MicrosoftConnect:TheServerAndClientparameterwiththeOutputCachepagedirectivedoesnotcacheontheclient,withoutcode
小结
小bug,办理办法也很复杂。可是,假如你不晓得这个bug,又会堕入微软的一个圈套(之条件到一个WCFClient的圈套),不知不觉中华侈了服务器资本与带宽。
微软那末有钱,有那末多天赋程序员,但是Bug也很难制止,可见开辟优异的软件是何等具有应战性的事情!
2003年中微软发布最新版本的ASP.netWebMatrix,对于我们喜欢用Asp.net来编程的朋友实在是个好消息,我也实实在在的将Asp.net更深入的研究了一下,以方便我以后更好的运用它,同时我也讲讲使用它的感受。
愤怒的大鸟 该用户已被删除
沙发
发表于 2015-1-18 22:31:53 | 只看该作者
目前在微软的.net战略中新推出的ASP.net借鉴了Java技术的优点,使用CSharp(C#)语言作为ASP.net的推荐语言,同时改进了以前ASP的安全性差等缺点。但是,使用ASP/ASP.net仍有一定的局限性,因为从某种角度来说它们只能在微软的WindowsNT/2000/XP+IIS的服务器平台上良好运行(虽然像ChilliSoft提供了在UNIX/Linux上运行ASP的解决方案.
精灵巫婆 该用户已被删除
板凳
发表于 2015-1-19 06:26:11 | 只看该作者
JSP/Servlet虽然在国内目前的应用并不广泛,但是其前途不可限量。
小妖女 该用户已被删除
地板
发表于 2015-1-24 09:41:39 | 只看该作者
市场决定一切,我个人从经历上觉得两者至少在很长时间内还是要共存下去,包括C和C++,至少从找工作就看得出来,总不可能大家都像所谓的时尚一样,追捧一门语言并应用它。
简单生活 该用户已被删除
5#
发表于 2015-1-31 22:46:37 | 只看该作者
代码的可重用性差:由于是面向结构的编程方式,并且混合html,所以可能页面原型修改一点,整个程序都需要修改,更别提代码重用了。
因胸联盟 该用户已被删除
6#
发表于 2015-2-5 23:19:27 | 只看该作者
提供基于组件、事件驱动的可编程网络表单,大大简化了编程。还可以用ASP.NET建立网络服务。
小魔女 该用户已被删除
7#
发表于 2015-2-5 23:47:43 | 只看该作者
最强的技术支持WebService,而且有.NET的所有library做后盾。而且ASP.NET在.NET3.5中还有微软专门为AJAX开发的功能--ASP.NETAJAX。
不帅 该用户已被删除
8#
发表于 2015-2-13 01:10:32 | 只看该作者
ASP是把代码交给VBScript解释器或Jscript解释器来解释,当然速度没有编译过的程序快了。
柔情似水 该用户已被删除
9#
发表于 2015-3-2 23:49:43 | 只看该作者
JSP/Servlet虽然在国内目前的应用并不广泛,但是其前途不可限量。
山那边是海 该用户已被删除
10#
发表于 2015-3-3 19:26:50 | 只看该作者
比如封装性、继承性、多态性等等,这就解决了刚才谈到的ASP的那些弱点。封装性使得代码逻辑清晰,易于管理,并且应用到ASP.Net上就可以使业务逻辑和Html页面分离,这样无论页面原型如何改变。
蒙在股里 该用户已被删除
11#
发表于 2015-3-11 12:30:09 | 只看该作者
ASP.net的速度是ASP不能比拟的。ASP.net是编译语言,所以,当第一次加载的时候,它会把所有的程序进行编译(其中包括worker进程,还有对语法进行编译,形成一个程序集),当程序编译后,执行速度几乎为0。
12#
发表于 2015-3-18 11:05:46 | 只看该作者
关于ASP.NET功能上,ASP.NET比微软以前的ASP(96年出现)有更强大的library,更好的稳定性。ASP.NET可以使用.NETFramework中所有组件(也就是说.NET能实现的,ASP.NET一样能实现)。
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

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

GMT+8, 2024-12-23 11:00

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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