ASP.NET:设置页面buffer引出来的问题

(编辑:jimmy 日期: 2025/7/8 浏览:2)

  前几天,在程序使用Respoonse.Redirect("a.aspx?f=9#12")的时候,发现在IE里面,跳转之后的页面忽略了#之后的内容,奇怪的是在同一页面向自己Redirect的时候,这个问题就不会存在,百思不得其解,有病乱投医吧,上网狂搜了一把,有人说设置页面Buffer为false可能解决这个问题,于是将a页面的buffer设置了false,经过验证,这个与上述问题不相干,但是一时疏忽,忘记了没有将buffer修改过来,昨天项目发布,放到服务器上发祥a页面的执行时间大的惊人,页面内容稍微大一点,页面往往会超时,而实现同一功能的b页面执行时间基本为0-16,而a页面数据库查询次数为3,b页面为7,这就更让人纳闷了,在本地试了下,b页面基本上和服务器没什么区别,a页面在90-300ms之间,而明显的b页面要表现的数据和查询的次数都要比a多,两者从页面结构上来说,基本一样,因为二者共同使用了相同的UserControl,只有中间部分表现形式稍微不同而已,同在一个屋檐下的人,差距怎么这么大呢?纳闷之余,一个个删除页面元素,发现根本不起本质作用,b页面就是出奇的快,a页面跟中风一样,慢的可以,于是找亚找,基本说是将a改了个遍,就差说闹鬼了得时候,突然发现a页面的buffer设置了false,而b赫然是true, 豁然开朗,铁钉就是这里问题,马上更正过来,good!a页面马上快了起来。

    一次不小心,造成如此的麻烦,不过总结了一下规律,在buffer设置为false得时候,与设置true,页面在处理时间上基本相差10-20倍的关系,如果以后发现同样功能的页面,速度相差不少,排除了数据处理等因素,应该考虑一下是否存在上述问题。

一句话新闻

一文看懂荣耀MagicBook Pro 16
荣耀猎人回归!七大亮点看懂不只是轻薄本,更是游戏本的MagicBook Pro 16.
人们对于笔记本电脑有一个固有印象:要么轻薄但性能一般,要么性能强劲但笨重臃肿。然而,今年荣耀新推出的MagicBook Pro 16刷新了人们的认知——发布会上,荣耀宣布猎人游戏本正式回归,称其继承了荣耀 HUNTER 基因,并自信地为其打出“轻薄本,更是游戏本”的口号。
众所周知,寻求轻薄本的用户普遍更看重便携性、外观造型、静谧性和打字办公等用机体验,而寻求游戏本的用户则普遍更看重硬件配置、性能释放等硬核指标。把两个看似难以相干的产品融合到一起,我们不禁对它产生了强烈的好奇:作为代表荣耀猎人游戏本的跨界新物种,它究竟做了哪些平衡以兼顾不同人群的各类需求呢?