0.背景

在項目開發之中，前期可能主要以保證任務完成為主，對于性能優化主要在于開發完成之后再來進行。可能在測試的時候發現部分接口的代碼執行時間過長，但是又毫無頭緒，這個時候你就需要性能分析工具來協助你排查問題了。

常規性能分析借助于 Visual Studio 強大的性能測試工具就可以進行分析，但是這些功能只包含在企業版當中。這個時候我們就可以使用 JetBrains 的 .NET 分析全家桶來進行這個操作了，其包含內存分析(dotMemory)與性能分析(dotTrace)，其實他的 dotCover(單元測試) 也是挺好用的。

1.安裝與下載

1.1 下載

安裝步驟較為簡單，前往 Jetbrains 官網，找到 dotTrace ，點擊下載即可。

其地址為?https://www.jetbrains.com/profiler/download/?，選擇自己需要的安裝包形式，一般選擇 WebInstaller 進行安裝，當然這里推薦選擇 Standalone (獨立版)，直接下載運行就 OK 。

1.2 安裝

每個用戶可以免費評估使用 10 天，當然你要使用某些補丁或者激活工具也是可以的，這里不再詳述過程，只是注意一下（WebInstaller）在安裝的時候選擇自己需要的安裝就可以了，不需要的直接選為 Skip 跳過。

你也可以在安裝的時候選擇 "Visual Studio Integration"，這樣就會與 VS 集成，在分析代碼的時候可以快速跳轉到相應的代碼行。

2.使用與分析

dotTrace 使用比較方便，本身支持 .NET Core 分析，分析時只是會有四種不同的分析模式，這里大概講解一下各種分析模式的區別。

Profiler Options作用與描述

Sampling	通過獲取 CLR 內部一個方法開始執行和結束執行的時間差來計算的分析時間。 這是最快的方法，它用于精確測量程序運行時間，但可能會丟失一些數據。 使用此配置類型可使你快速獲取應用程序的的總體性能。
Tracing	慢于 Sampling 的方法，但是可以準確地測量特定方法被調用的準確次數。 它是通過獲取 CLR 內部一個方法開始執行和結束執行的時間差來計算的分 析時間。
Line-by-line	通過收集代碼執行的每條語句的時間來進行比較，它計算出的時間更加精確。 該方法適用于你已經知道性能問題大概在哪里出現，并要找到具體某一個出 現性能問題的時候。
Timeline	采取抽樣的方式，每隔一段時間 (10 ms)，會暫停所有線程，并抓取堆棧里的 信息，然后才計算出代碼執行時間差。使用這個方式可能會導致一些執行時間 少于 10 ms 的方法無法被抓取到。

一般來說我們使用的是?Tracing?來進行代碼的性能分析，因為一般都是需要查看每個方法具體的調用時間。下面我就將以一個接口的實例來作為示范，看如何來排查調用緩慢的問題。

2.1 獲取快照信息

首先運行 dotTrace 之后，選擇 .NET Core Application，之后右側的 Profiler Options 則選擇 Tracing。最后一步則是選擇需要進行檢測的 dll 文件，這里我選擇的是一個基于 Abp 框架開發的 ASP.NET Core 項目。

當然，你也可以勾選上 Advanced ，配置諸如啟動參數之類的東西，之后點擊 Run 則開始進行分析了。

這里右下角的?Get Snapshot and Wait?點擊之后呢，就會獲取到快照文件了，當然現在先不慌，我們先來測試一下我們要測試的接口。

比如說我這里有一個 TestMethod 方法，其代碼如下：

現在我們通過 SwaggerUI 調用這個接口，看需要多長時間。

可以看到平均時常都需要 300ms ，現在我們點擊 GetSnapshot and Wait 按鈕，會彈出分析窗口，并且我們隨時可以通過再次點擊 Start 按鈕，繼續分析。

2.2 分析代碼

2.2.1 概覽信息

Tracing 分析的界面比較簡單，一個 All Calls 頁簽與 Overview (概覽) 的頁簽，首先我們大致看一下概覽窗口。

可以看到他給我們標識了用戶代碼執行周期最長的一些地方，其次也用柱狀圖很直觀地體現了耗時最長的代碼分類。

右側則提列了一些快照的信息與運行時的環境信息，以便用戶作為參考。

2.2.2 Threads Tree (線程信息)

本窗口主要的作用是分析應用程序里面發生的所有的線程活動，主線程有一個??圖標，而終結器線程則是擁有一個??圖標，剩下的都是線程池內部的工作線程。

在這里我們以主線程為例，分析一下其具體內容所表達的意思。

• Main：代表不帶命名空間的方法簡稱。

• 99 . 99 %：代表該方法針對于整個線程運行時間所占的百分比，這里的意思就是 Main 方法占用了整個主線程運行時間的 99.99 %。

• 523,732 ms：代表該方法與子方法執行的總時間。

• 1 call：方法在堆棧上所被調用的次數。

• XXX.Web.Host.Startup.Program.Main(string[] )：被調用方法的全稱，

2.2.3 Call Tree (調用樹)

一般我們使用本頁面的時候會多一點，這個頁面會顯示在所有線程中的所有被調用的方法。其每一個根節點代表的是每一個線程所執行的一個根函數，而下面每一個節點則代表其根函數內部調用的子函數的相關性能分析信息。

那么我們如何快速定位我們剛才測試的接口呢？

按下 Ctrl+F ，會彈出搜索框，在里面輸入我們所編寫的接口方法名字，按下回車就會快速定位了。

之后我們會看到如下內容：

通過展開節點我們可以知道最耗費時間的方法，即為 GetAll 方法，當點擊節點的時候，右側也會定位到相應的代碼位置。

這里可以看到整個 GetAll 方法使用了 1015ms 的時間，這是為什么呢？你可以看到在其右側有一個 8 calls ，這個時間是 8 次調用總共所花費的時間。

右鍵節點，你可以通過 Properties 可以看到該方法的平均執行時間：

可以看到其自身只花費了 8.3 μs，說明真正執行緩慢的還在其更深層，這里就不再往里面跟了，如果需要更加詳細的性能報告，可以不使用 Tracing 模式，而使用 Line-by-line 模式來進行分析。

2.2.4 Plain List (簡單列表)

以平鋪的方式展示所有被調用過的方法列表，讓你分析具體代碼。

2.2.5 Hot Spots (熱點跟蹤)

該視圖會列舉出所有耗時最長的方法。

3.參考資料

CSDN：https://blog.csdn.net/weixin_38208401/article/details/75645021

相關文章：

• ?dump解析入門-用VS解析dump文件進行排障

• dump文件解析之探索.Net的內存

• centos7 lldb 調試netcore應用的內存泄漏和死循環示例(dump文件調試)
  

原文地址:?https://www.cnblogs.com/myzony/p/9718776.html

---

.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

總結

以上是生活随笔為你收集整理的使用 dotTrace 分析 .NET Core 代码问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。