從昨天下午到今天一直在查找一個很重要的問題，原因是從objectDataSource控件的數據緩存失效查起，導致了站點的性能下降，沒想到花了一天的工夫最後查出的原因讓人跌破眼鏡。
有經驗的美工喜歡用<img src="" width="1" height="3">這種方式來精確的控制換行的高度，因爲這樣可以通過控制<img>的height來實現像素級的換行高度控制，然而這樣做對服務器來說卻是一個不折不扣的考驗和折磨。
當用戶請求訪問某個頁面時，瀏覽器將首先獲取該頁面的源代碼，然後執行，在執行的過程中，將會在內存中創建該頁面對象實例，加載各種資源，激發各種相應的客戶端事件，執行對應的javaScript腳本，直到最後展現給我們一個精美的頁面。
如果將圖片的ｓｒｃ設爲空，瀏覽器會將該圖片的鏈接地址設定爲站點的地址，如：http://localhost/myWebsites，這一點我們可以通過右鍵單擊圖片屬性查看ｕｒｌ地址得到證實，這時候，瀏覽器將會按照此地址向服務器請求該圖片的實際內容字節流，以便顯示該圖片，可是按照此地址向服務器請求時，將會執行站點的默認主頁面，就像我們請求訪問了該主頁面一樣，服務器將會執行主頁面的所有生命週期內的相關代碼，然後返回客戶端該主頁面的生成字節流，由於該圖片字節流實際上是一個頁面的源代碼，所以瀏覽器將不能正確的顯示該圖片。
到這裏我們也看得很清楚了，當用戶請求訪問含有<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設爲空等。