系统优化之旅
經過了半年緊張而蛋疼的開發歷程，項目終于走上正軌；測試組也招了，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前端解決方案來做腳本和樣式表的合并、壓縮，雪碧圖的合并，靜態文件名的變更等等操作。
?
⑥反向代理
通過使用反向代理緩沖服務器減輕資源服務器的壓力。?
?
至此系統優化就暫告一段落了。
轉載于:https://www.cnblogs.com/TiestoRay/p/4718370.html
總結
- 上一篇： 【转】Source Insight 有用
- 下一篇： 基于TerraExplorer Pro的