系統優化之旅

通過了半年緊張而蛋疼的開發歷程，項目終於走上正軌；測試組也招了，UI也招了，而項目需求也暫時沒有大的改動了。

在此風平浪靜的階段，項目也啓動了壓力測試。作了幾年的.Net開發，倒還真沒有應對太高併發的場景，現在這也算是機會與挑戰同時到來吧。

 

---

 

①測試第一回合

　　簡直是讓我無地自容的結果：200個併發登陸操做，成功率不足50%！真是日了狗。

程序的優化我是作了的，自認爲這一塊已經沒有效率低下的代碼了，但是這。。

　　解決：首先想的是IIS中的最大併發鏈接數，看了一下，默認的數值就已經至關的大了。（固然 IIS的最大併發鏈接數是能夠經過配置來實現更大的併發鏈接數的）

既然不是IIS的鏈接數限制，那數據庫的又如何呢？

查看了一下數據庫鏈接字符串，沒有發現關於最大鏈接池數的設定，默認是100，那這就確定是問題之一了！

②測試第二回合

添加了Max Pool Size後，又進行了一遍併發測試，結果當然是比第一次有提高，但僅是將將達到50%成功率而已。

既然不是受到併發數量的限制，那應該就是效率的問題了。一瞬間突然想到前期光顧着開發，根本沒有想過優化，也沒有想太高併發的狀況，數據庫裏索引之類的都沒有加。

找到登陸用到的幾個表，根據查詢條件添加了非彙集索引。再次開啓測試

查閱的關於索引的文章  

③測試第三回合

此次用了5000的併發（單純的執行登陸相關方法）成功率100%！

終於鬆了一口氣。無心中看到了記錄日誌的方法（登陸之類的行爲，以及錯誤都會有日誌保存到數據庫），想到這個地方也許也能夠優化吧，畢竟日誌用到的地方仍是蠻多的

記錄日誌內執行的內容卻是不多，只有一個入庫操做，可是由於記錄日誌跟業務代碼的執行無關，因此若是異步執行的話，應該也能提升很多效率。

稍做了下修改，再用VS的【性能和診斷】試了1000的併發。跟預想的同樣

後臺的優化自此就告一段落

④測試第四回合

這回讓測試組再用500併發測一下整個操做

每五秒3個併發，就這頻率，失敗率仍是居高不下，差很少30%，進行到一半後，CPU佔用率急劇增加，很快達到100%，而後就是服務器崩掉。

查看了一下線程的CPU佔用狀況，看到是網站應用的CPU使用率達到了99%。

初步判斷的是併發訪問頁面致使大量的靜態文件加載從而形成這個問題。好，那就作靜態資源服務器。

把系統使用的靜態資源放到一個新站點下，把登錄頁和首頁用到的js、css、img的URL都手動改爲絕對路徑（即靜態資源服務器中對應的URL）。修改路徑這個操做是能夠簡化的，接下來的一段時間我使用FIS3來完成這些事情。

注意：

把文件放到單獨的靜態資源服務器上也產生了點小問題，經過控制檯發現 有些文件沒有獲取到，如.woff的字體文件。這須要在IIS中添加對應的MIME類型，同時還要針對跨域添加HTTP響應標頭 

Access-Control-Allow-Origin：*

 一切就緒，從新發布。

 

⑤測試第五回合

這回併發成功率的提高並無太大，不過CPU使用率恢復了正常，徹底沒有因併發而產生太大的起伏。

----------------------------------------------------------------------------------------------------------

事情到此就暫告一段落了。接下來的時間就是優化前端了

由於我發現就算是使用了靜態文件服務器，有些事情完成的還不是很理想，

一是文件的本地緩存作的很差，致使刷新頁面的話，仍然要從服務器下載或者發請求

二是加載文件的整個過程耗時過長（相對）

 

接下來的時間就一直追蹤這兩個問題點處理方式。

開始的時候發如今全部的請求中 Response Header裏的Cache-Control都是no-cache。

這致使任什麼時候候都要去服務器去資源。試了各類方法各類百度也沒找到。最後發現dudu的一篇文章解決了這個問題

http://www.cnblogs.com/dudu/p/iis_user-mode_caching_cache-control_public.html。

此外 仍是用了大百度的FIS3前端解決方案來作腳本和樣式表的合併、壓縮，雪碧圖的合併，靜態文件名的變動等等操做。

 

⑥反向代理

經過使用反向代理緩衝服務器減輕資源服務器的壓力。 

 

至此係統優化就暫告一段落了。