前幾天，在程序使用Respoonse.Redirect("a.ASPx?f=9#12")的時候，發(fā)現(xiàn)在IE里面，跳轉(zhuǎn)之后的頁面忽略了#之后的內(nèi)容，奇怪的是在同一頁面向自己Redirect的時候，這個問題就不會存在，百思不得其解，有病亂投醫(yī)吧，上網(wǎng)狂搜了一把，有人說設(shè)置頁面Buffer為false可能解決這個問題，于是將a頁面的buffer設(shè)置了false，經(jīng)過驗(yàn)證，這個與上述問題不相干，但是一時疏忽，忘記了沒有將buffer修改過來，昨天項(xiàng)目發(fā)布，放到服務(wù)器上發(fā)祥a頁面的執(zhí)行時間大的驚人，頁面內(nèi)容稍微大一點(diǎn)，頁面往往會超時，而實(shí)現(xiàn)同一功能的b頁面執(zhí)行時間基本為0－16，而a頁面數(shù)據(jù)庫查詢次數(shù)為3,b頁面為7，這就更讓人納悶了，在本地試了下，b頁面基本上和服務(wù)器沒什么區(qū)別，a頁面在90-300ms之間，而明顯的b頁面要表現(xiàn)的數(shù)據(jù)和查詢的次數(shù)都要比a多，兩者從頁面結(jié)構(gòu)上來說，基本一樣，因?yàn)槎吖餐褂昧讼嗤腢serControl，只有中間部分表現(xiàn)形式稍微不同而已，同在一個屋檐下的人，差距怎么這么大呢？納悶之余，一個個刪除頁面元素，發(fā)現(xiàn)根本不起本質(zhì)作用，b頁面就是出奇的快，a頁面跟中風(fēng)一樣，慢的可以，于是找亞找，基本說是將a改了個遍，就差說鬧鬼了得時候，突然發(fā)現(xiàn)a頁面的buffer設(shè)置了false，而b赫然是true, 豁然開朗，鐵釘就是這里問題，馬上更正過來，good!a頁面馬上快了起來。

    一次不小心，造成如此的麻煩，不過總結(jié)了一下規(guī)律，在buffer設(shè)置為false得時候，與設(shè)置true，頁面在處理時間上基本相差10－20倍的關(guān)系，如果以后發(fā)現(xiàn)同樣功能的頁面，速度相差不少，排除了數(shù)據(jù)處理等因素，應(yīng)該考慮一下是否存在上述問題。

AspNet技術(shù)：ASP.NET：設(shè)置頁面buffer引出來的問題，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。