在測試過程中，我們經常需要知道“系統的資源利用情況”來監測我們的測試執行情況，來查看測試環境是否有效，測試結果是否可信，或者是在無人值守時保存結果，等我們值班時再來分析。
1、在Windows環境下，“開始\運行”中輸入“perfmon”，調出性能管理窗口；
2、在控制台節點中選擇“性能日志和警報\計數器日志”；
3、在右側的空白窗口中右擊選擇“新建日志設置”，在彈出的窗口中輸入新建日志的名稱，如PerfTest，確定； 如圖：
<IIS站點，則選擇Web Servie 項 , 最后選擇左下角具體的站點項目>
//=========================================================================================
一個ASP.NET項目在運營中，當接口並發量達到200左右時，IIS出現了明顯的請求排隊現象，發送的請求都進入等待，無法及時響應，Cpu接近100% 。花了很多時間精力解決這個問題，其中百度找了一解決方案，供大家參考。
注意到只有對於.aspx或.ashx的請求才會延遲，而.htm或.jpg文件都是即時響應的，我選擇了性能監視器中的ASP.NET 4.0中的2個主要計數器：Requests Current（當前請求數）, Requests Queued（被排隊的請求數），如下圖：(在左上角的列表中選擇asp.net 4.0, 雙擊選擇左下角的二個目標，完成添加)
進行觀察。通過觀察發現，當前請求數達到200左右時，被排隊的請求數就從0開始上升，一直到50左右，如果請求數繼續上升，則被排隊數也隨之上升。當被排隊的請求數>0時，就意味着這個時候去訪問任何.aspx頁面，頁面都會處於長時間等待中，沒有任何響應，直到IIS處理完了其他請求，才會開始處理隊列中的請求。也就是說，當排隊數長期>0時，系統基本處於不可用的狀態。就是說200個並發請求下，幾乎所有的請求都被排隊了，如下圖
針對以上問題，查閱了相關資料，是否出現排隊是和應用程序池的可用線程有關，通過2個方法可以查看系統總線程數和當前可用線程數。
ThreadPool.GetAvailableThreads( out availableWorker, out availableIO);
ThreadPool.GetMaxThreads(out maxWorker, out maxIO);
在隊列請求數達到120左右時，通過此方法，得到maxWorker=1600，而availableWorker=1472
因為服務器是16核的，ASP.NET4.0默認每核可以使用100個線程，所以maxWorker是1600，1600-120=1480，大致相等。
就是說當前有120個線程被用來處理請求，還有1400多個處於空閑。關鍵問題就是為什么這些空閑線程沒有被及時啟用？
ASP.NET提供的線程配置參數中，有一個參數是非常重要，但是可能被大家忽略的，就是minWorkerThreads。
意指最小工作線程，根據我們以上的測試結果，IIS托管線程啟動非常慢，微軟也認識到了這個問題，所以提供此參數用於設置正常情況下的最小工作線程數。比如我們系統白天的並發在200-300之間，則可以設置最小線程為300，這樣系統響應速度可以大幅提高。
據此，我對配置文件（machine.config）進行了如下修改。注意都是針對單個CPU的，系統會自動乘以邏輯CPU的數量。
<system.web>
<processModel autoConfig="false" maxWorkerThreads="200" minWorkerThreads="50" />