You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: aspnetcore/blazor/performance/app-download-size.md
+15-5Lines changed: 15 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -66,15 +66,21 @@ After an app is deployed, verify that the app serves compressed files. Inspect t
66
66
67
67
Blazor WebAssembly's runtime includes the following .NET features that can be disabled for a smaller payload size.
68
68
69
-
Blazor WebAssembly carries globalization resources required to display values, such as dates and currency, in the user's culture. If the app doesn't require localization, you may [configure the app to support the invariant culture](xref:blazor/globalization-localization#invariant-globalization), which is based on the `en-US` culture.
69
+
Blazor WebAssembly carries globalization resources required to display values, such as dates and currency, in the user's culture. If the app doesn't require localization, you may configure the app to [support the invariant culture](xref:blazor/globalization-localization#invariant-globalization), which is based on the `en-US` culture. Apply the `<InvariantGlobalization>` MSBuild property with a value of `true` in the app's project file (`.csproj`):
Adopting [invariant globalization](xref:blazor/globalization-localization#invariant-globalization) only results in using non-localized timezone names. To trim timezone code and data from the app, apply the `<InvariantTimezone>` MSBuild property with a value of `true` in the app's project file:
79
+
Adopting [invariant globalization](xref:blazor/globalization-localization#invariant-globalization) only results in using non-localized timezone names. To trim timezone code and data from the app, apply the `<InvariantTimezone>` MSBuild property with a value of `true` in the app's project file (`.csproj`):
74
80
75
81
```xml
76
82
<PropertyGroup>
77
-
<InvariantTimezone>true</InvariantTimezone>
83
+
<InvariantTimezone>true</InvariantTimezone>
78
84
</PropertyGroup>
79
85
```
80
86
@@ -89,7 +95,7 @@ A data file is included to make timezone information correct. If the app doesn't
* Call specification (":::no-loc text="callspec":::", sequence and timing of function calls) and instrumentation
39
38
40
-
Enable integration with the browser's developer tools profiler using the `<WasmProfilers>` property in the app's project file (`.csproj`). Include the additional properties in the following table.
39
+
The MSBuild properties in the following table enable profiler integration.
41
40
42
41
Property | Default | Set value to… | Description
43
42
--- | :---: | :---: | ---
@@ -48,8 +47,12 @@ Property | Default | Set value to… | Description
48
47
`<WasmNativeDebugSymbols>` | `true` | `true` | Controls building with native debug symbols.
49
48
`<WasmBuildNative>` | `false` | `true` | Controls building the native executable.
50
49
50
+
Enabling profilers has negative size and performance impact, so don't publish an app for production with profilers enabled. In the following example, a condition is set on a property group section that only enables profiling when the app is built with `/p:ProfilingEnabled=true` (.NET CLI) or `<ProfilingEnabled>true</ProfilingEnabled>` in a Visual Studio publish profile.
@@ -59,7 +62,15 @@ Property | Default | Set value to… | Description
59
62
</PropertyGroup>
60
63
```
61
64
62
-
Add Blazor start configuration in `wwwroot/index.html`, using the [fingerprinted location of the Blazor WebAssembly script](xref:blazor/fundamentals/static-files#fingerprint-client-side-static-assets-in-standalone-blazor-webassembly-apps). In the following example, the `sampleIntervalMs` option is set to 10 seconds, which is the default setting if `sampleIntervalMs` isn't specified:
65
+
Setting WebAssembly profilers with `<WasmProfilers>browser;</WasmProfilers>` doesn't require AOT (`<RunAOTCompilation>`/`<RunAOTCompilationAfterBuild>` set to `false` or removed from the preceding properity group).
66
+
67
+
The browser developer tools profiler can be used with AOT (`<RunAOTCompilation>`/`<RunAOTCompilationAfterBuild>` set to `true`) and without WebAssembly profilers (`<WasmProfilers>browser;</WasmProfilers>` removed from the preceding property group).
68
+
69
+
To see AOT method names in the developer tools console, install [DWARF chrome extension](https://chromewebstore.google.com/detail/cc++-devtools-support-dwa/pdcpmagijalfljmkmjngeonclgbbannb).
70
+
71
+
## Set the sample interval
72
+
73
+
To set the sample interval, add the following Blazor start configuration in `wwwroot/index.html` and add `autostart="false"` to the Blazor `<script>` tag. In the following example, the `sampleIntervalMs` option is set to 10 seconds, which is the default setting if `sampleIntervalMs` isn't specified:
@@ -105,57 +116,12 @@ Configure `callSpec` in `browserProfilerOptions`. Replace the `{APP NAMESPACE}`
105
116
</script>
106
117
```
107
118
108
-
## Log profiling for memory troubleshooting
109
-
110
-
Enable integration with the log profiler using the `<WasmProfilers>` and `<WasmBuildNative>` properties in the app's project file (`.csproj`):
111
-
112
-
```xml
113
-
<PropertyGroup>
114
-
<WasmProfilers>log</WasmProfilers>
115
-
<WasmBuildNative>true</WasmBuildNative>
116
-
</PropertyGroup>
117
-
```
118
-
119
-
To trigger a heap shot, add the following, where the `{APP NAMESPACE}` placeholder is the app's namespace:
120
-
121
-
```csharp
122
-
namespace {APP NAMESPACE};
123
-
124
-
publicclassProfiling
125
-
{
126
-
[JSExport]
127
-
[MethodImpl(MethodImplOptions.NoInlining)]
128
-
publicstaticvoidTakeHeapshot() { }
129
-
}
130
-
```
131
-
132
-
Invoke `TakeHeapshot` to create a memory heap shot and flush the contents of the profile to the file system. Download the resulting `.mpld` file to analyze the data.
133
-
134
-
## EventPipe profiler
135
-
136
-
[EventPipe](/dotnet/core/diagnostics/eventpipe) is a runtime component used to collect tracing data, similar to [ETW](/windows/win32/etw/event-tracing-portal) and [perf_events](https://wikipedia.org/wiki/Perf_%28Linux%29).
137
-
138
-
* Manual testing
139
-
* Browser developer tools: Download the `.json` output file, open the file in Visual Studio, and find the expected method calls.
140
-
*[`dotnet-trace`](/dotnet/core/diagnostics/dotnet-trace): Open the `.nettrace` output file in Visual Studio and find the expected method calls.
141
-
* Web-based testing
142
-
* Use the JavaScript API to obtain a [promise](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Promise) of NetTrace (`.nettrace`) bytes.
143
-
* Upload the file via HTTP.
144
-
* Parse and validate that the trace contains the expected method calls.
145
-
146
-
Built-in performance counters are available to track:
* Browser developer tools: Download the `.json` output file, open the file in Visual Studio, and find the expected classes.
156
123
*[`dotnet-gcdump` (`collect`/convert` options)](/dotnet/core/diagnostics/dotnet-gcdump): To view the captured GC dump files, see [View the GC dump captured from dotnet-gcdump](/dotnet/core/diagnostics/dotnet-gcdump#view-the-gc-dump-captured-from-dotnet-gcdump).
157
124
* Web-based testing
158
-
* Use the JavaScript API to obtain a [promise](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Promise) of NetTrace (`.nettrace`) bytes.
159
125
* Upload the file via HTTP.
160
126
* Parse and validate that the trace contains the expected classes.
161
127
@@ -165,7 +131,6 @@ Built-in performance counters are available to track:
165
131
* Browser developer tools: Download the `.json` output file, open the file in Visual Studio, and find the expected counters.
166
132
*[`dotnet-counters collect`](/dotnet/core/diagnostics/dotnet-counters): Open the `.csv`/`.json` output file in Visual Studio and find the expected counters.
167
133
* Web-based testing
168
-
* Use the JavaScript API to obtain a [promise](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Promise) of NetTrace (`.nettrace`) bytes.
169
134
* Upload the file via HTTP.
170
135
* Parse and validate that the trace contains the expected counters.
title: ASP.NET Core Blazor WebAssembly Event Pipe performance profiling and diagnostic counters
3
+
author: guardrex
4
+
description: Learn about Event Pipe performance profiling and diagnostic counters in ASP.NET Core Blazor WebAssembly apps.
5
+
monikerRange: '>= aspnetcore-10.0'
6
+
ms.author: riande
7
+
ms.custom: mvc
8
+
ms.date: 04/29/2025
9
+
uid: blazor/performance/event-pipe-profiling
10
+
---
11
+
# ASP.NET Core Blazor WebAssembly Event Pipe performance profiling and diagnostic counters
12
+
13
+
<!-- UPDATE 10.0 - Activate ...
14
+
15
+
[!INCLUDE[](~/includes/not-latest-version.md)]
16
+
17
+
-->
18
+
19
+
This article describes Event Pipe performance profiling tools and diagnostic counters for Blazor WebAssembly apps.
20
+
21
+
## Prerequisite
22
+
23
+
Install the [.NET WebAssembly build tools](xref:blazor/tooling/webassembly#net-webassembly-build-tools):
24
+
25
+
```dotnetcli
26
+
dotnet workload install wasm-tools
27
+
```
28
+
29
+
## EventPipe profiler
30
+
31
+
[EventPipe](/dotnet/core/diagnostics/eventpipe) is a runtime component used to collect tracing data, similar to [ETW](/windows/win32/etw/event-tracing-portal) and [perf_events](https://wikipedia.org/wiki/Perf_%28Linux%29).
32
+
33
+
* Manual testing
34
+
* Browser developer tools: Download the `.nettrace` output file, open the file in Visual Studio, and find the expected method calls.
35
+
*[`dotnet-trace`](/dotnet/core/diagnostics/dotnet-trace): Open the `.nettrace` output file in Visual Studio and find the expected method calls.
36
+
* Web-based testing
37
+
* Upload the file via HTTP.
38
+
* Parse and validate that the trace contains the expected method calls.
39
+
40
+
Built-in performance counters are available to track:
* Browser developer tools: Download the `.json` output file, open the file in Visual Studio, and find the expected classes.
49
+
*[`dotnet-gcdump` (`collect`/convert` options)](/dotnet/core/diagnostics/dotnet-gcdump): To view the captured GC dump files, see [View the GC dump captured from dotnet-gcdump](/dotnet/core/diagnostics/dotnet-gcdump#view-the-gc-dump-captured-from-dotnet-gcdump).
50
+
* Web-based testing
51
+
* Upload the file via HTTP.
52
+
* Parse and validate that the trace contains the expected classes.
53
+
54
+
## Counters trace
55
+
56
+
* Manual testing
57
+
* Browser developer tools: Download the `.json` output file, open the file in Visual Studio, and find the expected counters.
58
+
*[`dotnet-counters collect`](/dotnet/core/diagnostics/dotnet-counters): Open the `.csv`/`.json` output file in Visual Studio and find the expected counters.
59
+
* Web-based testing
60
+
* Upload the file via HTTP.
61
+
* Parse and validate that the trace contains the expected counters.
62
+
63
+
## .NET Core Diagnostics Client Library example
64
+
65
+
Parse and validate NetTrace (`.nettrace`) messages using the .NET Core Diagnostics Client Library:
For more information, see the [.NET Core diagnostics documentation](/dotnet/core/diagnostics/) and the [`IpcMessage` API (reference source)](https://github.com/dotnet/diagnostics/blob/main/src/Microsoft.Diagnostics.NETCore.Client/DiagnosticsIpc/IpcMessage.cs).
* Collects a GC (Garbage Collector) dump of the live .NET process.
77
+
* Collects performance counters for 60 seconds.
78
+
* Collects CPU counters for 60 seconds.
79
+
80
+
The MSBuild properties in the following table enable profiler integration.
81
+
82
+
Property | Default | Set value to… | Description
83
+
--- | :---: | :---: | ---
84
+
`<WasmPerfTracing>` | `false` | `true` | Controls diagnostic server tracing.
85
+
`<WasmPerfInstrumentation>` | `false` | `true` | Controls CPU sampling instrumentation for diagnostic server. Not necessary for memory dump or counters. **Makes the app execute slower. Only set this to `true` for performance profiling.
86
+
`<MetricsSupport>` | `false` | `true` | Controls `System.Diagnostics.Metrics` support. For more information, see the [`System.Diagnostics.Metrics` namespace](/dotnet/api/system.diagnostics.metrics).
87
+
`<EventSourceSupport>` | `false`| `true` | Controls `EventPipe` support. For more information, see [Diagnostics and instrumentation: Observability and telemetry](/dotnet/core/deploying/native-aot/diagnostics#observability-and-telemetry).
88
+
89
+
Enabling profilers has negative size and performance impact, so don't publish an app for production with profilers enabled. In the following example, a condition is set on a property group section that only enables profiling when the app is built with `/p:ProfilingEnabled=true` (.NET CLI) or `<ProfilingEnabled>true</ProfilingEnabled>` in a Visual Studio publish profile.
The [`Timing-Allow-Origin` HTTP header](https://developer.mozilla.org/docs/Web/HTTP/Reference/Headers/Timing-Allow-Origin) allows for more precise time measurements.
103
+
104
+
Browser developer tools console calls in the following example that trigger profiling:
105
+
106
+
*`collectGcDump`: Collect a GC (Garbage Collector) dump.
107
+
*`collectPerfCounters(durationSeconds)`: Collect general performance counters.
108
+
*`collectCpuSamples(durationSeconds)`: Collect CPU performance counters.
0 commit comments