PerfView: ASP.NET Core Stats View

[Guest MattHamrick]

This is something I built earlier this year and it was merged into the main PerfView source in mid-April, and released in v3.1.10. It’s a view that was built to consume Microsoft.AspNetCore.Hosting EventSource events and display a page similar to the IIS Stats view for those that are familiar with that one. If any of those events exist in a trace being opened by PerfView, the stats view will be available. If the trace doesn’t contain any of those events, then the view will not be visible.

 

 

 

Additionally, in the past couple months, the Azure App Service Product Group modified the DaaS (Diagnostics as a Service) .NET Profiler trace to automatically collect these events on both Linux and Windows App Services. This means recent App Service traces (from within the last ~1month or so) will have the events and thus the view should be available when the trace is opened in PerfView.

 

 

 

[HEADING=1]Where is it?[/HEADING]

 

When opening a trace containing the aforementioned events in PerfView v3.1.10+, the new view will be exposed in the Advanced folder:

 

[ATTACH type=full" alt="MattHamrick_1-1724426815359.png]63771[/ATTACH]

 

 

 

[HEADING=1]What does it look like?[/HEADING]

 

Fortunately, it looks the same regardless of what kind of trace you’re looking at:

 

[ATTACH type=full" alt="MattHamrick_2-1724426859687.png]63772[/ATTACH]

 

 

 

That one is from a dotnet-trace taken from one of my Linux App Services via the .NET Profiler (under-the-hood this profiler just uses a preconfigured dotnet-trace command).

 

 

 

Here is one from a Windows App Service, also captured via .NET Profiler (these come as ZIPs, extract the zip so PerfView can open the .diagsession file):

 

[ATTACH type=full" alt="MattHamrick_2-1724422028545.png]63773[/ATTACH]

 

 

 

Side note about the Windows App Service profiler traces – these are saved as ZIP files. The zip must be extracted so PerfView can get to the .diagsession file inside. When viewing the .diagsession in PerfView, there is an unresolved bug where it doesn’t refresh the screen:

 

[ATTACH type=full" alt="MattHamrick_3-1724422028546.png]63774[/ATTACH]

 

 

 

So double-clicking won’t give you the option to expand the trace (i.e. the arrow above won’t show up) – you can just refresh the window with F5 and the arrow will appear. From there you can expand the trace like the screenshot shown earlier.

 

 

 

[HEADING=1]So what about non-AppService scenarios?[/HEADING]

 

The events can be captured with PerfView by adding the “*Microsoft.AspNetCore.Hosting” provider in the GUI or the command line (note the asterisk * - that is critical for PerfView to be able to capture any .NET/Core event sources):

 

[ATTACH type=full" alt="MattHamrick_4-1724422028549.png]63775[/ATTACH]

 

 

 

Command-line:

 

PerfView.exe "/DataFile:PerfViewData.etl" /BufferSizeMB:512 /StackCompression /CircularMB:500 /Providers:"*Microsoft.AspNetCore.Hosting,Microsoft-Windows-IIS,*Microsoft-Extensions-Logging:4:5" /ContinueOnError /NoGui /NoNGenRundown collect

 

 

 

Or captured using dotnet-trace (does not need the leading asterisk):

 

dotnet-trace collect --providers Microsoft.AspNetCore.Hosting,Microsoft-Extensions-Logging:4:5 -p ###

 

 

 

[HEADING=1]What if I’m interested in a specific request?[/HEADING]

 

Clicking the ActivityId of that request will open the Events view with that ID as a text filter and the start and stop time of the events being specific to that request (all of the events are selected by-default):

 

[ATTACH type=full" alt="MattHamrick_3-1724427512708.png]63776[/ATTACH]

 

 

 

Notice the first event in that list is Microsoft.AspNetCore.Hosting/Request/Start – the last one should be the corresponding Request/Stop event, assuming the trace contains it.

 

Any other events that contain that ActivityId will also be displayed. You can then filter through these events as usual (removing different types you don’t care about, etc.) to hone-in on what you want to see.

 

 

 

I have already used this view many times as it saves many clicks when looking for specific requests and such. Hopefully it helps you too!

 

 

 

If capturing your own trace, I strongly recommend also including the Microsoft-Extensions-Logging:4:5 provider (yes those are dashes, and don’t forget the leading asterisk if using PerfView to capture, otherwise it’s the same) as that is where ASP.NET Core itself writes its logs, as well as anything else that uses ILogger. Sometimes those events aren’t available for various reasons, but when they are they’re usually helpful. The 4 in that provider is the keyword and for that provider it means capture only the FormattedMessage events, while the 5 is the verbosity (5=verbose). See: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/logging/?view=aspnetcore-8.0#dotnet-trace-tooling

 

 

 

Over time, as time is available, I plan to tweak the view and try to add more features to it.

 

 

 

Related links:

 

Original PR: https://github.com/microsoft/perfview/pull/2001

 

Added clickable ActivityIds to bring up the Events view: https://github.com/microsoft/perfview/pull/2028

 

PerfView 3.1.10 release where this was first available: https://github.com/microsoft/perfview/releases/tag/v3.1.10

 

Latest PerfView release (currently 3.1.13): https://github.com/microsoft/perfview/releases/latest

 

Continue reading...