使用 dotTrace 分析 .NET Core 代碼問題

Java編程精選

點擊右側關注,免費入門到精通!

來源:myzony

cnblogs.com/myzony/archive/2018/09/28/9718776.html

一、背景

在項目開發之中,前期可能主要以保證任務完成為主,對於性能優化主要在於開發完成之後再來進行。

可能在測試的時候發現部分介面的代碼執行時間過長,但是又毫無頭緒,這個時候你就需要性能分析工具來協助你排查問題了。

常規性能分析藉助於 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 分析,分析時只是會有四種不同的分析模式,這裡大概講解一下各種分析模式的區別。

一般來說我們使用的是 Tracing 來進行代碼的性能分析,因為一般都是需要查看每個方法具體的調用時間。

下面我就將以一個介面的實例來作為示範,看如何來排查調用緩慢的問題。

2.1 獲取快照信息

首先運行 dotTrace 之後,選擇 .NET Core Application,之後右側的 Profiler Options 則選擇 Tracing。

最後一步則是選擇需要進行檢測的 dll 文件,這裡我選擇的是一個基於 Abp 框架開發的 ASP.NET Core 項目。

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

這裡右下角的 Get Snapshot and Wait 點擊之後呢,就會獲取到快照文件了,當然現在先不慌,我們先來測試一下我們要測試的介面。

比如說我這裡有一個 TestMethod 方法,其代碼如下:

public class TestApplicationService : ApplicationService

{

    private readonly IRepository _tempRep;

    public TestApplicationService(IRepository tempRep)

    {

        _tempRep = tempRep;

    }

    public async Task TestMethod()

    {

        var systems = _tempRep.GetAll().ToList();

        foreach (var system in systems)

        {

            system.Status = 10;

            await _tempRep.UpdateAsync(system);

        }

        int i = 0;

        for (int j = 0; j < 10000; j++)

        {

            i += j;

        }

        return systems[0].SystemCode;

    }

}

現在我們通過 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

【點擊成為源碼大神】


推薦閱讀:

【原創】中國人民解放軍軍歌隱藏式代碼
心在跳情在燒+代碼
精美點線框代碼
一行代碼讓 Python 的運行速度提高100倍

TAG:代碼 | .NET | 問題 | 分析 |