程序在發(fā)布前就應(yīng)該發(fā)現(xiàn)的一些錯(cuò)誤
不過，如果能夠在程序發(fā)布前（自測或者測試階段）將這些問題找出來，我想大家都是可接受的。
今天就來介紹一種方法，用來發(fā)現(xiàn)在網(wǎng)站開發(fā)過程中，容易被我們忽略的一些問題，而這些問題其實(shí)是容易被發(fā)現(xiàn)的。
將要介紹的方法需要使用Fiddler這樣一款工具，我將演示如何使用Fiddler來發(fā)現(xiàn)404錯(cuò)誤，以及較大的響應(yīng)輸出問題。
我認(rèn)為這二個(gè)問題實(shí)在太低級(jí)了，所以我設(shè)計(jì)了這個(gè)方法，并寫了這篇博客，希望大家能喜歡。
我發(fā)現(xiàn)，許多人對(duì)于這二類問題（404錯(cuò)誤和較大的響應(yīng)輸出）都很不在意，好像它們根本不會(huì)對(duì)一個(gè)網(wǎng)站有任何影響似的。
難道真是這樣嗎？
我認(rèn)為：如果你做的網(wǎng)站程序，用戶訪問量很小，或許的確可以忽略它們。
否則，我還是建議你應(yīng)該糾正它們，下面我來解釋它們的危害。
404錯(cuò)誤
我一直認(rèn)為404不僅僅只是一個(gè)數(shù)字，過多的404也會(huì)影響程序的性能。
通過對(duì)404錯(cuò)誤的分析，我發(fā)現(xiàn)多數(shù)的404錯(cuò)誤都與一些資源文件的引用有關(guān)，比如代碼中引用了不存在CSS或者JS文件，這些404錯(cuò)誤發(fā)生時(shí)，可能并不會(huì)影響頁面的正常顯示，因此，這類錯(cuò)誤根本就不會(huì)引起一些開發(fā)人員的注意。再加上，許多人又喜歡復(fù)制粘貼，導(dǎo)致這類錯(cuò)誤越來越多。
為什么我會(huì)說【過多的404錯(cuò)誤也會(huì)影響性能】呢？
因?yàn)楫?dāng)404錯(cuò)誤產(chǎn)生時(shí)，IIS其實(shí)并不只是返回這樣一個(gè)數(shù)字，而是一個(gè)完整的HTTP響應(yīng)，響應(yīng)的內(nèi)容是一個(gè)正常的網(wǎng)頁。
不同的IIS版本的這個(gè)404的錯(cuò)誤頁面長度并不相同，IIS6默認(rèn)的404錯(cuò)誤頁面長度超過2K，而IIS7.5的默認(rèn)錯(cuò)誤頁面會(huì)超過8K 。
雖然這個(gè)響應(yīng)看起來并不大，但是由于請(qǐng)求不成功，每當(dāng)打開這些頁面時(shí)，請(qǐng)求會(huì)重新發(fā)起，數(shù)量會(huì)越來越多。
反過來，我們可以想一下：如果要引用的資源文件存在，這些文件僅僅需要請(qǐng)求一次，瀏覽器就會(huì)緩存它們，根本不需要每次都重新發(fā)起請(qǐng)求。
這樣一來，客戶端減少了請(qǐng)求數(shù)量，服務(wù)器減輕了連接壓力，那些無意義的404響應(yīng)所浪費(fèi)的網(wǎng)絡(luò)流量也能消失。
因此，過多的404請(qǐng)求簡直是一個(gè)惡性循環(huán)，它延長了頁面的顯示時(shí)間（前端），給服務(wù)端帶來了連接壓力，也浪費(fèi)了網(wǎng)絡(luò)資源。
較大的響應(yīng)輸出
較大的響應(yīng)輸出，應(yīng)該是容易理解的，那就是：服務(wù)端返回的結(jié)果太大了。
我們可以想像一下【較大的響應(yīng)輸出】意味著什么。
- 瀏覽器顯示一個(gè)【很大的網(wǎng)頁】，是不是會(huì)比較慢？
- 【很大的網(wǎng)頁】是不是會(huì)花費(fèi)較長的網(wǎng)絡(luò)傳輸時(shí)間？
- 服務(wù)端生成【很大的網(wǎng)頁】，是不是也要花較長的生成時(shí)間？
- 如果這個(gè)【很大的網(wǎng)頁】的結(jié)果來自于數(shù)據(jù)庫的查詢結(jié)果，會(huì)不會(huì)給數(shù)據(jù)庫也帶來較大的壓力？
產(chǎn)生這種情況就典型的場景可能由于一條SQL查詢引起的: select * from XXX where name=@name
或許在早期階段，XXX表的記錄很少，或許當(dāng)初在設(shè)計(jì)時(shí)根本沒想到name會(huì)存在一大堆的復(fù)制數(shù)據(jù)時(shí)，再或者，當(dāng)在本地環(huán)境測試時(shí)，網(wǎng)速根本不是問題，而瀏覽器的渲染速度的延遲又沒有被發(fā)覺時(shí)。
我們可以想像一下：這樣的程序如果部署在互聯(lián)網(wǎng)上運(yùn)行，結(jié)果會(huì)如何？
關(guān)于【較大的響應(yīng)輸出】，還有二個(gè)可能發(fā)生的場景：
- 往ViewState中放入一個(gè)很大的對(duì)象。
- 展示一個(gè)樹形結(jié)構(gòu)，或者是一個(gè)沒有where條件的查詢（都屬于不分頁情況）
當(dāng)以上這三類情況發(fā)生時(shí)，你認(rèn)為性能還能接受嗎？用戶還會(huì)滿意嗎？
用Fiddler發(fā)現(xiàn)這些問題
前面我詳細(xì)說明了二類低級(jí)錯(cuò)誤的危害，下面再來說說如何盡早地發(fā)現(xiàn)它們。
我想許多人都應(yīng)該用過Fiddler，它能夠方便地讓我們知道瀏覽器發(fā)起的每個(gè)請(qǐng)求的Request/Response，通常用于調(diào)試程序。
在Fiddler中，404錯(cuò)誤的請(qǐng)求會(huì)用紅字醒目地顯示，每個(gè)請(qǐng)求的響應(yīng)長度也會(huì)單獨(dú)地顯示出來，貌似直接用Fiddler也能容易發(fā)現(xiàn)404錯(cuò)誤以及較大的響應(yīng)輸出問題。
然而，當(dāng)訪問過多的頁面后，F(xiàn)iddler會(huì)顯示非常多的請(qǐng)求記錄，
因此，那些低級(jí)問題會(huì)被淹沒，我們要想發(fā)現(xiàn)它們，可能需要花費(fèi)一點(diǎn)時(shí)間。
針對(duì)這個(gè)問題，我為Fiddler定義了二個(gè)規(guī)則：
只要打開它們，前面所說的二類低級(jí)問題很容易就能發(fā)現(xiàn)：
注意：這里只顯示符合規(guī)則的請(qǐng)求（存在低級(jí)問題的請(qǐng)求）。
該怎么合理地使用這個(gè)方法呢？
- 如果你是開發(fā)人員，請(qǐng)?jiān)谧詼y時(shí)，打開Fiddler，并選擇我定義那二個(gè)規(guī)則，
- 如果你是測試人員，請(qǐng)?jiān)跍y試時(shí)，打開Fiddler，并選擇我定義那二個(gè)規(guī)則，
- 然后，你們平時(shí)該做什么就做什么吧，。。。。。。
- 測試結(jié)束后，再看一下Fiddler窗口，有沒有記錄顯示出來，如果有，那就是發(fā)現(xiàn)低級(jí)問題了。
所以，我認(rèn)為這個(gè)方法不會(huì)給開發(fā)人員以及測試人員帶來過多的負(fù)擔(dān)，畢竟，這個(gè)方法不會(huì)給他（她）們測試時(shí)增加任何負(fù)擔(dān)，唯獨(dú)要求打開一下Fiddler，最后在測試完成后，再來看一眼，僅此而已。
或許有些人認(rèn)為：分析服務(wù)器的IIS日志，也能發(fā)現(xiàn)這二類問題。
是的，我知道分析IIS日志也能發(fā)現(xiàn)這些問題，
但是，分析IIS日志，是不是晚了？
你想過沒有：這樣的問題是不是已經(jīng)影響了用戶？
反之，不讓用戶【體驗(yàn)】這些問題，是不是更好？
換句話說：你是否希望發(fā)布一個(gè)有缺陷的程序？
如何自定義Fiddler過濾規(guī)則
如果希望自定義Fiddler規(guī)則，建議安裝：Syntax-Highlighting 這個(gè)Fiddler插件。
然后，打開自定義規(guī)則窗口：
此時(shí)，會(huì)顯示Fiddler的規(guī)則代碼，供你修改：
在這個(gè)窗口中，右邊顯示了能在自定義規(guī)則中使用的一些對(duì)象類型，以及它們的字段（綠字），屬性（藍(lán)字）與方法（黑字）。
我們可以在寫規(guī)則時(shí)參考這些信息。
說明：此規(guī)則文件保存在：x:\My Documents\Fiddler2\Scripts\CustomRules.js
還記得我前面的截圖中：我在Fiddler的Rules菜單下面增加了二個(gè)自定義規(guī)則 嗎？
定義規(guī)則菜單的代碼在前面的截圖中（找漢字就能發(fā)現(xiàn)，最后4行代碼）。
菜單定義后，還需要在OnBeforeResponse方法中添加一些處理代碼：
最后，我還要再說一句：
如果你不希望發(fā)布有缺陷的程序，并且不希望后期返工，那么可以嘗試一下本文介紹的方法。
點(diǎn)擊此處下載我的CustomRules.js （Fiddler版本 2.4.1.1）
原文鏈接：http://www.cnblogs.com/fish-li/archive/2012/11/05/2754516.html
