dotTrace
1. 問題描述
IIS發布的接口運行一段時間后變的很慢，重啟IIS連接池后問題得到解決，但是運行一段時間后再次出現變慢的問題
2. 問題原因
程序中有讀取xml文件的邏輯，現網請求多的時候 ，讀取xml消耗時間很多，造成連接超時，IIS的連接得不到及時釋放
3. 定位方法
優化內部邏輯解決該問題。在測試環境下進行壓力測試，並使用dotTrace進行跟蹤，具體步驟。
第一步。接口進行壓力測試，運行dotTrace，選擇profile---IIS Application（因為是IIS應用）
第二步。選擇需要的profiler options（此處選擇的是Tracing），點擊Run
第三步。先在命令行中通過iisapp查看需要定位的IIS應用的PID，再選擇對應的PID參數，點擊Get Snapshot獲取快照就可以了。
第四步。對快照進行分析。
4. dotTrace
Dottrace是由JetBrainshttp://www.jetbrains.com/ 公司開發的一款產品，它分dottrace Performance和dottrace Memory 兩個工具，dottrace Performance用來分析代碼性能，比如函數執行時間，調用次數，消耗時間比率等，dottrace Memory一般用來分析內存占用情況。dottrace可以跟蹤.net編寫的：應用程序，IIS掛接的程序，windows服務，silverlight，WCF服務程序等。還可以把跟蹤的文件，以快照的方式保存下來，保存為dtp后綴的文件。跟蹤后的結果，如果能找到對應用戶的代碼信息，還可以直接查看對應的源代碼，並選擇在VS里直接編輯該方法對應的文件。
profiling type 有三種類型：
- Tracing：它是通過獲取CLR內部一個方法開始執行和結束執行的時間差來計算的分析時間。
- Line-by-line：它是通過收集代碼執行的每條語句的時間來，它計算出的時間更精確。
- Sampling：它是抽樣的方式，每隔一段時間（windows下大概是10ms），會暫停所有線程，並抓取堆棧里的信息，然后計算出代碼執行時間差，這個選項可能會導致一些執行很短的方法抓取不到的問題。
- Wall time(performance counter)： 它是通過Performance Counter API來收集的信息，一般操作系統和各個硬件設備都提供性能計數的API供程序調用。
- Thread time：它只支持Sampling的分析方式，它通過一個固定的線程來抓取堆棧信息計算時間，並且它只計算自己內部程序執行的時間，不管等待其他IO的時間。
- Wall time(CPU instruction)：它是通過讀取TSC processor register里記錄的方法進入和退出時間差的方式來計算的。
Measure的三種類型：
根據上面的選項方式，一般我們要想完整分析自己程序的執行時間，建議可以采用Line-byline(或Tracing)和Wall time(CPU instruction)或Wall time(performance counter)的方式，因為如果用抽樣和Thread time的搭配方式，會只計算自己內部時間，不能計算自己程序和外部程序交互的時間，會讓自己分析性能時產生誤導。
View介紹：
- Overview：這個可以看到該性能分析文件的抓取方式，比如上面例子為Tracing，Wall Time(CPU instruction)的方式，抓取的URL地址等，還會有該視圖下的系統配置情況以及當前的模塊以及方法個數等信息。
- Threads Tree：記錄當前每個線程執行的方法，以及方法的性能情況。
- Call Tree：不管線程，按所有請求的入口為一條數據展現，但里面展現的排序是按照執行時間高低排序的，不是按照代碼順序展現的。
- Plain List：展現所有非內核代碼的方法列表，並展現每個方法執行時間和被調用次數。
- Hot Spots：它會把所有代碼包括內核代碼的方法，按照執行時間排序順序展現到列表，並記錄每個方法的執行時間比率和時間等信息。
通過監控的圖我們可以較為快速的定位代碼中的性能瓶頸
5. 參考資料
http://www.cnblogs.com/xienb/p/3313153.html