記一次WCF調優實戰
最近單位的單點登錄認證系統常常莫名其妙的宕機,這套系統使用asp.net 4.0的技術開發,部署環境爲Windows Server 2008 R2 Enterprise IIS7.5。核心功能爲使用WCF爲其餘應用提供登錄認證和業務受權,一旦該系統沒法正常運行單位其餘系統都會出現沒法登錄的狀況。web
問題描述,該系統出現問題時,WCF服務沒法訪問,同時經過IISRESET命令重啓IIS時也會失敗直接拋出以下異常服務器
經過查看服務器的配置發現該服務器硬件配置不錯的,CPU Intel Xeon(R) E5620 2.4GHz 雙處理器8核心,內存12GB,筆者分析單位的全部經過該系統進行認證和受權的其餘系統結合單位任務2000人左右,該系統的最大併發度應該在1500左右,後來經過Windows的性能監視器分析發現系統的最大併發量在1560左右,平時的併發在100上下,如此配置的服務器按理徹底夠用的。併發
WCF和IIS的可配性都很高,是否是相關的配置沒有作優化形成的呢,先看一下WCF應用的配置,發現serviceThrottling的三個參數maxConcurrentCalls、maxConcurrentInstances和maxConcurrentSessions的配置值並不高分別爲100,200,300。經過查詢微軟的網站發現,這三個參數配置決定了WCF服務的併發度,根據單位全部的系統和相關用戶筆者將這三個值都設置爲了5000。asp.net
<serviceThrottling maxConcurrentCalls="5000" maxConcurrentInstances="5000" maxConcurrentSessions="5000" />
在經過分析站點使用的IIS應用程序池發現,該認證系統和其餘應用共享了同一個應用程序池切程序池的設置採用的時默認設置。首先將單點登錄認證系統遷移至爲其專門新建的應用程序池中,同時將應用程序池的配置作以下優化:性能
-
隊列長度:有1000改成20000(最大能夠設置爲65535)優化
-
禁用重疊回收:設置爲True網站
-
回收固定時間間隔:設置爲0(不根據此項配置回收)spa
-
特定時間:設置爲凌晨4:30(這樣應用程序池回收不影響用戶操做).net
-
設置超時:設置爲0(空閒狀態不回收)code
-
關閉快速故障防禦
通過這麼一番設置,系統的併發度和穩定度都有提升,最終效果還有待觀察。