Blazor - rendering metrics #61516

pavelsavara · 2025-04-16T12:50:39Z

Blazor - rendering metrics

new Microsoft.AspNetCore.Components.Rendering meter

has component.type which is GetType().FullName of the component being rendered
aspnetcore.components.rendering.count
- this is total count, always growing. The viewer could calculate "component render/minute"
aspnetcore.components.rendering.duration
- per component

new Microsoft.AspNetCore.Components.Server.Circuits meter

aspnetcore.components.circuits.count
- this is total count, always growing. The viewer could calculate "new circuits/minute"
aspnetcore.components.circuits.active_circuits
- in server memory
aspnetcore.components.circuits.connected_circuits
- with connected signalR
aspnetcore.components.circuits.duration
- from creation until GC

How to enable with OpenTelemetry/Aspire

builder.Services.ConfigureOpenTelemetryMeterProvider(meterProvider =>
{
    meterProvider.AddMeter("Microsoft.AspNetCore.Components.Rendering");
    meterProvider.AddMeter("Microsoft.AspNetCore.Components.Server.Circuits");
});

Fixes #53613

pavelsavara · 2025-04-16T21:35:34Z

src/Components/Components/src/RenderTree/Renderer.cs

@@ -90,6 +92,10 @@ public Renderer(IServiceProvider serviceProvider, ILoggerFactory loggerFactory,
        _logger = loggerFactory.CreateLogger("Microsoft.AspNetCore.Components.RenderTree.Renderer");
        _componentFactory = new ComponentFactory(componentActivator, this);

+        // TODO register RenderingMetrics as singleton in DI


It would be good to register RenderingMetrics as singleton. But I think it should be done in one of the "Extensions" helpers and I'm not sure which. This could be done in next PR when @javiercn is back.

There is one place for server https://github.com/dotnet/aspnetcore/blob/main/src/Components/Endpoints/src/DependencyInjection/RazorComponentsServiceCollectionExtensions.cs#L36 and one for WebAssembly https://github.com/dotnet/aspnetcore/blob/main/src/Components/WebAssembly/WebAssembly/src/Hosting/WebAssemblyHostBuilder.cs#L299

This is going to be "painful" because it lives in the Microsoft.AspNetCore.Components. Typically, what we do in these cases is expose a helper method that is then called by the different hosts to register it on DI.

There's no way around not introducing a bit of public API for this. If I were to do something, I would go with creating an additional extension method here (look at AddValueProvider for a sample pattern) and have that called in the places that @maraf pointed out.

Later on, we can decide if we prefer to introduce a single extension method that we can pile up things in the future. The pattern MVC follows has AddMvcCore for this reason, we could have something like AddComponentsCore that is meant to be called out by the individual hosts, but for now let's just stick with what we've been doing so far (that would be my recommendation).

maraf · 2025-04-17T09:38:17Z

src/Components/Components/src/RenderTree/Renderer.cs

@@ -90,6 +92,10 @@ public Renderer(IServiceProvider serviceProvider, ILoggerFactory loggerFactory,
        _logger = loggerFactory.CreateLogger("Microsoft.AspNetCore.Components.RenderTree.Renderer");
        _componentFactory = new ComponentFactory(componentActivator, this);

+        // TODO register RenderingMetrics as singleton in DI


There is one place for server https://github.com/dotnet/aspnetcore/blob/main/src/Components/Endpoints/src/DependencyInjection/RazorComponentsServiceCollectionExtensions.cs#L36 and one for WebAssembly https://github.com/dotnet/aspnetcore/blob/main/src/Components/WebAssembly/WebAssembly/src/Hosting/WebAssemblyHostBuilder.cs#L299

pavelsavara · 2025-04-17T12:38:58Z

/ba-g CI timeout is #60989

javiercn · 2025-04-21T08:45:10Z

src/Components/Components/src/RenderTree/Renderer.cs

+        var meterFactory = serviceProvider.GetService<IMeterFactory>();
+        _renderingMetrics = meterFactory != null ? new RenderingMetrics(meterFactory) : null;


Is there a case where IMeterFactory is not ever on DI?

In unit tests I think. Also I can imagine that somebody would like to disable it in non-cloud environments.

For the unit tests we would simply update them. For production workloads our hosts should just call AddMetrics and rely on it being there. I don't think this dependency should be optional.

What about WASM, do you think it should always have metrics in DI ? That would make impossible to disable/trim metrics for Blazor

I think that's fine, if we are concerned, we can look at the size before and after the change to understand the delta. In any case we could put it behind and app compat switch so that it gets trimmed by default if not enabled?

There is a fair bit of code involved with metrics. I think you'll want a way to toggle it on and off in WASM.

I'm thinking [FeatureSwitchDefinition("System.Diagnostics.Metrics.Meter.IsSupported")]

javiercn · 2025-04-21T09:14:13Z

src/Components/Components/src/RenderTree/Renderer.cs

+        var startTime = (_renderingMetrics != null && _renderingMetrics.IsDurationEnabled()) ? Stopwatch.GetTimestamp() : 0;
+        _renderingMetrics?.RenderStart(componentState.Component.GetType().FullName);
        componentState.RenderIntoBatch(_batchBuilder, renderQueueEntry.RenderFragment, out var renderFragmentException);
        if (renderFragmentException != null)
        {
            // If this returns, the error was handled by an error boundary. Otherwise it throws.
            HandleExceptionViaErrorBoundary(renderFragmentException, componentState);
        }
+        _renderingMetrics?.RenderEnd(componentState.Component.GetType().FullName, renderFragmentException, startTime, Stopwatch.GetTimestamp());


Several questions on this block:

Do we understand what this is measuring?

This is measuring the Render method on the component, which just updates the RenderTree, which might not be very interesting.

It might make more sense to measure when a render batch starts and ends, as that more clearly represents the time it took the app to create a single "snapshot" update.

A more representative thing to measure is SetComponentParametersAsync which is where most of the application logic for an app lives.

Do we know the perf cost of this? (Since it happens per render)

Does it make sense to cache the component FullName inside ComponentState

* It might make more sense to measure when a render batch starts and ends

I agree that duration of whole batch could be separate metric.

* A more representative thing to measure is `SetComponentParametersAsync` which is where most of the application logic for an app lives.

OK. I will need some help to understand what are all the places in which this is called.
You mean ComponentBase.SetParametersAsync(), right ?

* Do we know the perf cost of this? (Since it happens per render)

It depends on if there is listener attached or not. When it's not it's negligible.

* Does it make sense to cache the component `FullName` inside ComponentState

Reflection already does some caching.

src/Components/Components/src/Rendering/RenderingMetrics.cs

src/Components/Server/src/Circuits/CircuitMetrics.cs

src/Components/Server/src/DependencyInjection/ComponentServiceCollectionExtensions.cs

src/Shared/Metrics/MetricsConstants.cs

src/Components/Server/test/Circuits/CircuitMetricsTest.cs

javiercn

Overall changes look great. That said, there are a few things that I think we need to revisit:

Measuring renders:
- We want to track from the start of a render batch to the completion of such render batch.
- We want to track SetParametersAsync on component instances as this is where most of the user code lives, the execution time of RenderFragment is "generally" not relevant as all that code does is fill in an array of RenderTreeFrames and for the most part is compiler generated code.
  - It's valuable though to measure/track the size of the render tree of a given component, as that is a good indicator of components that are rendering a lot of data.
  - If we want to track the "impact" of a render, it's best to do so in RenderTreeDiffBuilder.ComputeDiff this is the bit of logic that actually does work like instantiate and set parameters on child components and so on.
Circuit metrics:
- I think we might want to track the reason why a circuit is terminated (gracefully (session ended), timeout (circuit got disconnected and timed out), capacity (there were too many disconnected circuits)).
Performance considerations:
- In general, we need to be very careful on the things that we do on a per-component basis, as a general principle, minimize allocations and avoid doing work unless needed. This is the "hotest" path for Blazor, so we need to ensure we don't regress perf.

src/Components/Components/src/Rendering/RenderingMetrics.cs

JamesNK · 2025-04-21T12:45:59Z

src/Components/Server/src/Circuits/CircuitMetrics.cs

+            "aspnetcore.components.circuits.duration",
+            unit: "s",
+            description: "Duration of circuit.",
+            advice: new InstrumentAdvice<double> { HistogramBucketBoundaries = MetricsConstants.VeryLongSecondsBucketBoundaries });


What is wrong with the existing LongSecondsBucketBoundaries? That's already used for Kestrel connection duration and signalr connection duration.

I don't like having 3 different durations.

I think this is used to bucketize the circuit duration, which I think naturally spans longer than the SignalR/Http one. If we were to use those, doesn't that mean that most data will end up in a single bucket? Ideally the buckets should be representative of the "durations" that we expect to track, isn't it?

The biggest value in th existing buckets is 5 minutes. Do you think most circuits last longer than 5 minutes?

I think so. Circuits are associated with the "session" (a browser tab), so it's very feasible that they remain open while the user is looking at the tab. As for how long they can last, it's very app specific, but I think we want to have enough granularity to track whether sessions are very short (1-10 minutes) or last significantly longer (10 minutes, hours if the users leave the browser tab open and don't have energy saving settings)

Is there a specific problem with having a different set of numbers? Is there a recommended number of values that we should strive for?

No there isn't a specific problem. Just there is an extra choice for people to choose from, and good values for the buckets need to be decided.

When you mean people, do you mean us, or do you mean developers consuming the metrics. I assume you mean us?

I mean us.

The comment on the new buckets doesn't seem right. SignalR connection duration goes up to 300 seconds.

I thought that Blazor circuit could be alive for days. And since circuit keeps the state of the blazor session it could be memory hungry. So understanding the histogram of how long your users keep the tab open matters for sizing your cluster.

I thought that it could happen that 80% of your circuits live over 5 minutes but with the previous buckets you don't know if that's 6 minutes or 6 days.

The comment on the new buckets doesn't seem right. SignalR connection duration goes up to 300 seconds.

Could you please be more specific? I will fix it on next PR. Thanks.

JamesNK · 2025-04-21T14:18:04Z

These metrics need to be documented at https://learn.microsoft.com/en-us/aspnet/core/log-mon/metrics/built-in

pavelsavara · 2025-04-22T09:02:32Z

Thank you. I will open another PR to address the feedback.

#61609

initial

9b75d60

pavelsavara added feature-diagnostics Diagnostic middleware and pages (except EF diagnostics) area-blazor Includes: Blazor, Razor Components labels Apr 16, 2025

pavelsavara added this to the 10.0-preview5 milestone Apr 16, 2025

pavelsavara self-assigned this Apr 16, 2025

build-analysis bot mentioned this pull request Apr 16, 2025

System.TimeoutException : The operation has timed out. dotnet/dnceng#5279

Open

3 tasks

more

51c936d

pavelsavara force-pushed the blazor_rendering_metrics branch from 6f6a498 to 51c936d Compare April 16, 2025 21:31

pavelsavara commented Apr 16, 2025

View reviewed changes

argh

bab2daf

This was referenced Apr 17, 2025

slow macOS - "##[error]The job running on agent Azure Pipelines 9 ran longer than the maximum time of 60 minutes." dotnet/dnceng#1883

Open

The Operation will be canceled. The next steps may not contain expected logs. dotnet/dnceng#3008

Open

tests

8ac9034

pavelsavara marked this pull request as ready for review April 17, 2025 09:27

pavelsavara requested a review from a team as a code owner April 17, 2025 09:27

maraf approved these changes Apr 17, 2025

View reviewed changes

pavelsavara enabled auto-merge (squash) April 17, 2025 11:11

pavelsavara disabled auto-merge April 17, 2025 12:43

pavelsavara enabled auto-merge (squash) April 17, 2025 12:44

akoeplinger disabled auto-merge April 17, 2025 12:46

pavelsavara enabled auto-merge (squash) April 17, 2025 12:47

pavelsavara merged commit 183c128 into dotnet:main Apr 17, 2025
26 of 27 checks passed

dotnet-policy-service bot modified the milestones: 10.0-preview5, 10.0-preview4 Apr 17, 2025