WEB程式在釋出前就應該發現的一些錯誤

Fish Li發表於2012-11-09

Web

　　在軟體開發過程中，寫出影響效能或者有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定義了二個規則：