一個不起眼的問題導致性能的嚴重的下降

      從昨天下午到今天一直在查找一個很重要的問題,原因是從objectDataSource控件的數據緩存失效查起,導致了站點的性能下降,沒想到花了一天的工夫最後查出的原因讓人跌破眼鏡。
     有經驗的美工喜歡用<img src="" width="1" height="3">這種方式來精確的控制換行的高度,因爲這樣可以通過控制<img>的height來實現像素級的換行高度控制,然而這樣做對服務器來說卻是一個不折不扣的考驗和折磨。
     當用戶請求訪問某個頁面時,瀏覽器將首先獲取該頁面的源代碼,然後執行,在執行的過程中,將會在內存中創建該頁面對象實例,加載各種資源,激發各種相應的客戶端事件,執行對應的javaScript腳本,直到最後展現給我們一個精美的頁面。
     如果將圖片的src設爲空,瀏覽器會將該圖片的鏈接地址設定爲站點的地址,如:http://localhost/myWebsites,這一點我們可以通過右鍵單擊圖片屬性查看url地址得到證實,這時候,瀏覽器將會按照此地址向服務器請求該圖片的實際內容字節流,以便顯示該圖片,可是按照此地址向服務器請求時,將會執行站點的默認主頁面,就像我們請求訪問了該主頁面一樣,服務器將會執行主頁面的所有生命週期內的相關代碼,然後返回客戶端該主頁面的生成字節流,由於該圖片字節流實際上是一個頁面的源代碼,所以瀏覽器將不能正確的顯示該圖片。
     到這裏我們也看得很清楚了,當用戶請求訪問含有<img src="">頁面時,將會導致了服務器額外的執行站點主頁面,相當於我們同時訪問了當前頁面和站點主頁面兩個頁面。服務器會將這兩個頁面內容字節流返回客戶端,不但浪費了服務器的資源,還白白消耗了寶貴的網絡帶寬。如果您的系統是多層架構的話,同樣將會影響到每一層服務器的性能。
爲了驗證這裏的結論,我們不妨做兩個頁面:
Page1.htm
<html>
<body>
this is the default page.
</body>
</html>

Page2.htm
<html>
<body>
<img src="" width=500 height=100><br>
this is the user requested  page.
</body>
</html>
在IIS中將page1.htm設爲主頁面,分兩次訪問page2.htm:
第一次:訪問page2.htm頁面,並將該頁面保存。
第二次:刪除page2.htm頁面代碼中的<img src="" width=500 height=100>,保存該頁面代碼,然後再訪問此頁面,並保存該頁面;
結論驗證:
服務器端驗證:
     這一點我們可以通過查看IIS服務日誌來確認,默認的IIS日誌地址爲:C:/WINDOWS/system32/LogFiles/w3svc1,打開該文件夾,可以看到以日期命名的文本文件,格式如:ex050825.log,打開該文件可以看到我們剛纔的訪問請求記錄,如下: #Date: 2005-08-25 01:47:14
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status
2005-08-25 01:47:14 127.0.0.1 GET /MasterPageAndDefaultRelationStudy/page2.htm - 80 - 127.0.0.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.2;+Maxthon;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50215;+.NET+CLR+1.0.3705) 200 0 0
2005-08-25 01:47:14 127.0.0.1 GET /MasterPageAndDefaultRelationStudy/page1.htm - 80 - 127.0.0.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.2;+Maxthon;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50215;+.NET+CLR+1.0.3705) 200 0 0
2005-08-25 01:47:22 127.0.0.1 GET /MasterPageAndDefaultRelationStudy/page2.htm - 80 - 127.0.0.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.2;+Maxthon;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50215;+.NET+CLR+1.0.3705) 304 0 0
     很明顯,我們在第一次訪問page2.htm頁面時,IIS同時向客戶端還返回了站點的默認主頁面,page1.htm,然而在我們第二次訪問page2.htm頁面時,服務器並沒有返回page1.htm頁面。
客戶端驗證:
     瀏覽到我們剛纔分別兩次保存頁面的地方看看,對於第一次保存的頁面,同時還生成了一個同名的文件夾,裏面存放的就是以站點名稱命名的*.htm頁面,其實就是剛纔的page1.htm頁面;而對於我們第二次保存的頁面,並沒有生成同名的文件夾。

     上面的只是一個示例性質的驗證,我們可以寫一個更復雜的含有執行代碼的驗證實例,同時可以啓動斷點調試功能,這樣就能看得更清楚了。
     所以最後的結論是:在我們的頁面中千萬不能含有<img src="">這樣的代碼,這同樣也包括客戶端的javascript腳本的動作行爲,如創建一個img元素,而將其src設爲空等。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章