網站優化實戰--解決網站動態壓縮過程
本來想寫一個網站優化的系列（前端到后端的數據庫,垂直優化到分布式,后面會補上），但沒有時間（借口），今天就總結一下前幾天優化網站的過程。
網站優化重點在于找出出現性能問題的地方，往往是解決方案很簡單，過程很艱辛。
先介紹一下 場景 ：公司某網站產品的一個頁面加載速度非常慢，完全加載完成大約8秒左右，要盡可能的提高網站加載速度。
線上環境：IIS6.0 +ASP.NET MVC4
解決思路：
對于網站優化我曾經總結過一套方法論：順著HTTP請求方向追一排查，例如：瀏覽器->IIS服務器->ASP.NET-> 數據庫。根據二八原則，其中幾個階段的20%的代碼造成了80%的性能問題，所以我要重點尋找那20%的代碼。但方法論始終是方法論，根據我對業務判斷， 我的排查流程就變成了這樣 : 數據庫->ASP.NET->IIS服務器->瀏覽器。(后來結果證明，我應該按照方法論走)
優化過程：
一、用SQL Profiler監控慢SQL
用SQL Profiler把Duration在3000毫秒以上的慢SQL賽選出來，結果一條也沒有，縮小Duration到2000毫秒。結果沒有。繼續觀察有沒有N+1的問題，也沒有。
二、查看是否是ASP.NET應用程序的問題：
用HttpModule監控每個URL的請求時間：
結果當前請求的URL非常快。進行下一步
三、查看IIS的相關配置。
結果：動態壓縮，靜態壓縮都已經啟用。
開始分析IIS日志，IIS日志中記錄了每個請求的執行時間，這個時間和HttpModule的時間相減就是網絡傳輸時間，由此可以判斷是否是網絡引起的問題。
理想總是好的，結果IIS日志已經十幾G了，要挨個分析不知道啥時候，放棄，進行下一步。
以后會上LogStash，然后升級IIS（IIS6用起來真蛋疼）。
四、觀察瀏覽器響應時間
由上圖接收時間可以看出：網站響應時間大部分都浪費到了網絡下載。而且頁面大小為1.7M。難道是網絡延時太大？ping一下
以上說明網絡沒有太大延時。這時候突然想起來了公司的網絡限速了，下載速度平均200kb/s , 那么1.7M網頁下載時間也就大約8s左右了。
再查看1.7M網頁內容全是html，而且響應報文頭里沒有Contend-Ecoding ,說明沒進行壓縮。但明明服務器開啟了動態壓縮。
這時想起了博客園寫的一篇文章： 遷入阿里云后：解決了一個IIS動態內容壓縮的問題 但IIS6下沒有這個節點，需要修改metabase.xml，修改metabase.xml會影響所有網站，網站出現問題，風險太大，我們需要做的只是壓縮當前網站的動態內容,想其他方案。
五、自己寫HttpModule解決壓縮問題
開始想造輪子 : 在EndRequest用Gizp壓縮然后輸出，結果EndRequest始終拿不到響應內容。
在萬能的Stackoverflow找到這兩篇文章 Can I detect if content has been compressed in my HttpModule?
Use .Net 2.0 compression library and HttpModule to compress your webpages
那個代碼不適合，然后改造 ，最后修改后的代碼：
上線以后經過測試，該頁面響應速度2s以內了，而且響應報文頭里面也有了Content-Encoding：gzip
總結，其實一開始我應查看瀏覽器的響應時間這些信息，但根據以往的優化經驗和現在的業務，我把關注點放在了后端，不過以后我會按照我的方法論走，那樣解決問題的成本更低。