在軟件開發過程中，寫出影響性能或者有BUG的代碼，都是我們無法回避的現實問題。

不過，如果能夠在程序發布前（自測或者測試階段）將這些問題找出來，我想大家都是可接受的。

今天就來介紹一種方法，用來發現在網站開發過程中，容易被我們忽略的一些問題，而這些問題其實是容易被發現的。

將要介紹的方法需要使用Fiddler這樣一款工具，我將演示如何使用Fiddler來發現404錯誤，以及較大的響應輸出問題。

我認為這二個問題實在太低級了，所以我設計了這個方法，并寫了這篇博客，希望大家能喜歡。

我發現，許多人對于這二類問題（404錯誤和較大的響應輸出）都很不在意，好像它們根本不會對一個網站有任何影響似的。

難道真是這樣嗎？

我認為：如果你做的網站程序，用戶訪問量很小，或許的確可以忽略它們。否則，我還是建議你應該糾正它們，下面我來解釋它們的危害。

404錯誤

我一直認為404不僅僅只是一個數字，過多的404也會影響程序的性能。

通過對404錯誤的分析，我發現多數的404錯誤都與一些資源文件的引用有關，比如代碼中引用了不存在CSS或者JS文件，這些404錯誤發生時，可能并不會影響頁面的正常顯示，因此，這類錯誤根本就不會引起一些開發人員的注意。再加上，許多人又喜歡復制粘貼，導致這類錯誤越來越多。

為什么我會說【過多的404錯誤也會影響性能】呢？

因為當404錯誤產生時，IIS其實并不只是返回這樣一個數字，而是一個完整的HTTP響應，響應的內容是一個正常的網頁。不同的IIS版本的這個404的錯誤頁面長度并不相同，IIS6默認的404錯誤頁面長度超過2K，而IIS7.5的默認錯誤頁面會超過8K 。雖然這個響應看起來并不大，但是由于請求不成功，每當打開這些頁面時，請求會重新發起，數量會越來越多。

反過來，我們可以想一下：如果要引用的資源文件存在，這些文件僅僅需要請求一次，瀏覽器就會緩存它們，根本不需要每次都重新發起請求。這樣一來，客戶端減少了請求數量，服務器減輕了連接壓力，那些無意義的404響應所浪費的網絡流量也能消失。

因此，過多的404請求簡直是一個惡性循環，它延長了頁面的顯示時間（前端），給服務端帶來了連接壓力，也浪費了網絡資源。

較大的響應輸出

較大的響應輸出，應該是容易理解的，那就是：服務端返回的結果太大了。

我們可以想像一下【較大的響應輸出】意味著什么。

1. 瀏覽器顯示一個【很大的網頁】，是不是會比較慢？

2. 【很大的網頁】是不是會花費較長的網絡傳輸時間？

3. 服務端生成【很大的網頁】，是不是也要花較長的生成時間？

4. 如果這個【很大的網頁】的結果來自于數據庫的查詢結果，會不會給數據庫也帶來較大的壓力？

產生這種情況就典型的場景可能由于一條SQL查詢引起的: select * from XXX where name=@name或許在早期階段，XXX表的記錄很少，或許當初在設計時根本沒想到name會存在一大堆的復制數據時，再或者，當在本地環境測試時，網速根本不是問題，而瀏覽器的渲染速度的延遲又沒有被發覺時。我們可以想像一下：這樣的程序如果部署在互聯網上運行，結果會如何？

關于【較大的響應輸出】，還有二個可能發生的場景：

1. 往ViewState中放入一個很大的對象。

2. 展示一個樹形結構，或者是一個沒有where條件的查詢（都屬于不分頁情況）

當以上這三類情況發生時，你認為性能還能接受嗎？用戶還會滿意嗎？

用Fiddler發現這些問題

前面我詳細說明了二類低級錯誤的危害，下面再來說說如何盡早地發現它們。

我想許多人都應該用過Fiddler，它能夠方便地讓我們知道瀏覽器發起的每個請求的Request/Response，通常用于調試程序。

在Fiddler中，404錯誤的請求會用紅字醒目地顯示，每個請求的響應長度也會單獨地顯示出來，貌似直接用Fiddler也能容易發現404錯誤以及較大的響應輸出問題。然而，當訪問過多的頁面后，Fiddler會顯示非常多的請求記錄，因此，那些低級問題會被淹沒，我們要想發現它們，可能需要花費一點時間。

針對這個問題，我為Fiddler定義了二個規則：

只要打開它們，前面所說的二類低級問題很容易就能發現：

注意：這里只顯示符合規則的請求（存在低級問題的請求）。

該怎么合理地使用這個方法呢？

1. 如果你是開發人員，請在自測時，打開Fiddler，并選擇我定義那二個規則，

2. 如果你是測試人員，請在測試時，打開Fiddler，并選擇我定義那二個規則，

3. 然后，你們平時該做什么就做什么吧，。。。。。。

4. 測試結束后，再看一下Fiddler窗口，有沒有記錄顯示出來，如果有，那就是發現低級問題了。

所以，我認為這個方法不會給開發人員以及測試人員帶來過多的負擔，畢竟，這個方法不會給他（她）們測試時增加任何負擔，唯獨要求打開一下Fiddler，***在測試完成后，再來看一眼，僅此而已。

或許有些人認為：分析服務器的IIS日志，也能發現這二類問題。是的，我知道分析IIS日志也能發現這些問題，但是，分析IIS日志，是不是晚了？ 你想過沒有：這樣的問題是不是已經影響了用戶？反之，不讓用戶【體驗】這些問題，是不是更好？換句話說：你是否希望發布一個有缺陷的程序？

如何自定義Fiddler過濾規則

如果希望自定義Fiddler規則，建議安裝：Syntax-Highlighting 這個Fiddler插件。

然后，打開自定義規則窗口：

此時，會顯示Fiddler的規則代碼，供你修改：

在這個窗口中，右邊顯示了能在自定義規則中使用的一些對象類型，以及它們的字段（綠字），屬性（藍字）與方法（黑字）。
我們可以在寫規則時參考這些信息。

說明：此規則文件保存在：x:\My Documents\Fiddler2\Scripts\CustomRules.js

還記得我前面的截圖中：我在Fiddler的Rules菜單下面增加了二個自定義規則 嗎？

定義規則菜單的代碼在前面的截圖中（找漢字就能發現，***4行代碼）。

菜單定義后，還需要在OnBeforeResponse方法中添加一些處理代碼：

***，我還要再說一句：如果你不希望發布有缺陷的程序，并且不希望后期返工，那么可以嘗試一下本文介紹的方法。

原文鏈接：http://www.cnblogs.com/fish-li/archive/2012/11/05/2754516.html