Host and deploy server-side Blazor apps

This article explains how to host and deploy server-side Blazor apps (Blazor Web Apps and Blazor Server apps) using ASP.NET Core.

Host configuration values

Server-side Blazor apps can accept Generic Host configuration values.

Deployment

Using a server-side hosting model, Blazor is executed on the server from within an ASP.NET Core app. UI updates, event handling, and JavaScript calls are handled over a SignalR connection.

A web server capable of hosting an ASP.NET Core app is required. Visual Studio includes a server-side app project template. For more information on Blazor project templates, see ASP.NET Core Blazor project structure.

Publish an app in Release configuration and deploy the contents of the bin/Release/{TARGET FRAMEWORK}/publish folder, where the {TARGET FRAMEWORK} placeholder is the target framework.

Scalability

When considering the scalability of a single server (scale up), the memory available to an app is likely the first resource that the app exhausts as user demands increase. The available memory on the server affects the:

• Number of active circuits that a server can support.
• UI latency on the client.

For guidance on building secure and scalable server-side Blazor apps, see the following resources:

• Threat mitigation guidance for ASP.NET Core Blazor static server-side rendering
• Threat mitigation guidance for ASP.NET Core Blazor interactive server-side rendering

Each circuit uses approximately 250 KB of memory for a minimal Hello World-style app. The size of a circuit depends on the app's code and the state maintenance requirements associated with each component. We recommend that you measure resource demands during development for your app and infrastructure, but the following baseline can be a starting point in planning your deployment target: If you expect your app to support 5,000 concurrent users, consider budgeting at least 1.3 GB of server memory to the app (or ~273 KB per user).

SignalR configuration

SignalR's hosting and scaling conditions apply to Blazor apps that use SignalR.

For more information on SignalR in Blazor apps, including configuration guidance, see ASP.NET Core Blazor SignalR guidance.

Azure App Service

Hosting on Azure App Service requires configuration for WebSockets and session affinity, also called Application Request Routing (ARR) affinity.

Enable the following for the app's registration in Azure App Service:

• WebSockets to allow the WebSockets transport to function. The default setting is Off.
• Session affinity to route requests from a user back to the same App Service instance. The default setting is On.

1. In the Azure portal, navigate to the web app in App Services.
2. Open Settings > Configuration.
3. Set Web sockets to On.
4. Verify that Session affinity is set to On.

Azure SignalR Service

The optional Azure SignalR Service works in conjunction with the app's SignalR hub for scaling up a server-side app to a large number of concurrent connections. In addition, the service's global reach and high-performance data centers significantly aid in reducing latency due to geography.

The service isn't required for Blazor apps hosted in Azure App Service or Azure Container Apps but can be helpful in other hosting environments:

• To facilitate connection scale out.
• Handle global distribution.

In the event that the app uses Long Polling or falls back to Long Polling instead of WebSockets, you may need to configure the maximum poll interval (MaxPollIntervalInSeconds, default: 5 seconds, limit: 1-300 seconds), which defines the maximum poll interval allowed for Long Polling connections in the Azure SignalR Service. If the next poll request doesn't arrive within the maximum poll interval, the service closes the client connection.

For guidance on how to add the service as a dependency to a production deployment, see Publish an ASP.NET Core SignalR app to Azure App Service.

For more information, see:

• Azure SignalR Service
• What is Azure SignalR Service?
• ASP.NET Core SignalR production hosting and scaling
• Publish an ASP.NET Core SignalR app to Azure App Service

IIS

When using IIS, enable:

• WebSockets on IIS.
• Session affinity with Application Request Routing.

For more information, see the guidance and external IIS resource cross-links in Publish an ASP.NET Core app to IIS.

Kubernetes

Create an ingress definition with the following Kubernetes annotations for session affinity:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: <ingress-name>
  annotations:
    nginx.ingress.kubernetes.io/affinity: "cookie"
    nginx.ingress.kubernetes.io/session-cookie-name: "affinity"
    nginx.ingress.kubernetes.io/session-cookie-expires: "14400"
    nginx.ingress.kubernetes.io/session-cookie-max-age: "14400"

Linux with Nginx

Follow the guidance for an ASP.NET Core SignalR app with the following changes:

• Change the location path from /hubroute (location /hubroute { ... }) to the root path / (location / { ... }).
• Remove the configuration for proxy buffering (proxy_buffering off;) because the setting only applies to Server-Sent Events (SSE), which aren't relevant to Blazor app client-server interactions.

For more information and configuration guidance, consult the following resources:

• ASP.NET Core SignalR production hosting and scaling
• Host ASP.NET Core on Linux with Nginx
• Configure ASP.NET Core to work with proxy servers and load balancers
• NGINX as a WebSocket Proxy
• WebSocket proxying
• Consult developers on non-Microsoft support forums:
  • Stack Overflow (tag: blazor)
  • ASP.NET Core Slack Team
  • Blazor Gitter

Linux with Apache

To host a Blazor app behind Apache on Linux, configure ProxyPass for HTTP and WebSockets traffic.

In the following example:

• Kestrel server is running on the host machine.
• The app listens for traffic on port 5000.

ProxyPreserveHost   On
ProxyPassMatch      ^/_blazor/(.*) http://localhost:5000/_blazor/$1
ProxyPass           /_blazor ws://localhost:5000/_blazor
ProxyPass           / http://localhost:5000/
ProxyPassReverse    / http://localhost:5000/

Enable the following modules:

a2enmod   proxy
a2enmod   proxy_wstunnel

Check the browser console for WebSockets errors. Example errors:

• Firefox can't establish a connection to the server at ws://the-domain-name.tld/_blazor?id=XXX
• Error: Failed to start the transport 'WebSockets': Error: There was an error with the transport.
• Error: Failed to start the transport 'LongPolling': TypeError: this.transport is undefined
• Error: Unable to connect to the server with any of the available transports. WebSockets failed
• Error: Cannot send data if the connection is not in the 'Connected' State.

For more information and configuration guidance, consult the following resources:

• Configure ASP.NET Core to work with proxy servers and load balancers
• Apache documentation
• Consult developers on non-Microsoft support forums:
  • Stack Overflow (tag: blazor)
  • ASP.NET Core Slack Team
  • Blazor Gitter

Measure network latency

JS interop can be used to measure network latency, as the following example demonstrates.

MeasureLatency.razor:

@inject IJSRuntime JS

<h2>Measure Latency</h2>

@if (latency is null)
{
    <span>Calculating...</span>
}
else
{
    <span>@(latency.Value.TotalMilliseconds)ms</span>
}

@code {
    private DateTime startTime;
    private TimeSpan? latency;

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (firstRender)
        {
            startTime = DateTime.UtcNow;
            var _ = await JS.InvokeAsync<string>("toString");
            latency = DateTime.UtcNow - startTime;
            StateHasChanged();
        }
    }
}

@inject IJSRuntime JS

<h2>Measure Latency</h2>

@if (latency is null)
{
    <span>Calculating...</span>
}
else
{
    <span>@(latency.Value.TotalMilliseconds)ms</span>
}

@code {
    private DateTime startTime;
    private TimeSpan? latency;

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (firstRender)
        {
            startTime = DateTime.UtcNow;
            var _ = await JS.InvokeAsync<string>("toString");
            latency = DateTime.UtcNow - startTime;
            StateHasChanged();
        }
    }
}

@inject IJSRuntime JS

<h2>Measure Latency</h2>

@if (latency is null)
{
    <span>Calculating...</span>
}
else
{
    <span>@(latency.Value.TotalMilliseconds)ms</span>
}

@code {
    private DateTime startTime;
    private TimeSpan? latency;

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (firstRender)
        {
            startTime = DateTime.UtcNow;
            var _ = await JS.InvokeAsync<string>("toString");
            latency = DateTime.UtcNow - startTime;
            StateHasChanged();
        }
    }
}

@inject IJSRuntime JS

<h2>Measure Latency</h2>

@if (latency is null)
{
    <span>Calculating...</span>
}
else
{
    <span>@(latency.Value.TotalMilliseconds)ms</span>
}

@code {
    private DateTime startTime;
    private TimeSpan? latency;

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (firstRender)
        {
            startTime = DateTime.UtcNow;
            var _ = await JS.InvokeAsync<string>("toString");
            latency = DateTime.UtcNow - startTime;
            StateHasChanged();
        }
    }
}

@inject IJSRuntime JS

@if (latency is null)
{
    <span>Calculating...</span>
}
else
{
    <span>@(latency.Value.TotalMilliseconds)ms</span>
}

@code {
    private DateTime startTime;
    private TimeSpan? latency;

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (firstRender)
        {
            startTime = DateTime.UtcNow;
            var _ = await JS.InvokeAsync<string>("toString");
            latency = DateTime.UtcNow - startTime;
            StateHasChanged();
        }
    }
}

For a reasonable UI experience, we recommend a sustained UI latency of 250 ms or less.

Memory management

On the server, a new circuit is created for each user session. Each user session corresponds to rendering a single document in the browser. For example, multiple tabs create multiple sessions.

Blazor maintains a constant connection to the browser, called a circuit, that initiated the session. Connections can be lost at any time for any of several reasons, such as when the user loses network connectivity or abruptly closes the browser. When a connection is lost, Blazor has a recovery mechanism that places a limited number of circuits in a "disconnected" pool, giving clients a limited amount of time to reconnect and re-establish the session (default: 3 minutes).

After that time, Blazor releases the circuit and discards the session. From that point on, the circuit is eligible for garbage collection (GC) and is claimed when a collection for the circuit's GC generation is triggered. One important aspect to understand is that circuits have a long lifetime, which means that most of the objects rooted by the circuit eventually reach Gen 2. As a result, you might not see those objects released until a Gen 2 collection happens.

Measure memory usage in general

Prerequisites:

• The app must be published in Release configuration. Debug configuration measurements aren't relevant, as the generated code isn't representative of the code used for a production deployment.
• The app must run without a debugger attached, as this might also affect the behavior of the app and spoil the results. In Visual Studio, start the app without debugging by selecting Debug > Start Without Debugging from the menu bar or Ctrl+F5 using the keyboard.
• Consider the different types of memory to understand how much memory is actually used by .NET. Generally, developers inspect app memory usage in Task Manager on Windows OS, which typically offers an upper bound of the actual memory in use. For more information, consult the following articles:
  • .NET Memory Performance Analysis: In particular, see the section on Memory Fundamentals.
  • Work flow of diagnosing memory performance issues (three-part series): Links to the three articles of the series are at the top of each article in the series.

Memory usage applied to Blazor

We compute the memory used by blazor as follows:

(Active Circuits × Per-circuit Memory) + (Disconnected Circuits × Per-circuit Memory)

The amount of memory a circuit uses and the maximum potential active circuits that an app can maintain is largely dependent on how the app is written. The maximum number of possible active circuits is roughly described by:

Maximum Available Memory / Per-circuit Memory = Maximum Potential Active Circuits

For a memory leak to occur in Blazor, the following must be true:

• The memory must be allocated by the framework, not the app. If you allocate a 1 GB array in the app, the app must manage the disposal of the array.
• The memory must not be actively used, which means the circuit isn't active and has been evicted from the disconnected circuits cache. If you have the maximum active circuits running, running out of memory is a scale issue, not a memory leak.
• A garbage collection (GC) for the circuit's GC generation has run, but the garbage collector hasn't been able to claim the circuit because another object in the framework is holding a strong reference to the circuit.

In other cases, there's no memory leak. If the circuit is active (connected or disconnected), the circuit is still in use.

If a collection for the circuit's GC generation doesn't run, the memory isn't released because the garbage collector doesn't need to free the memory at that time.

If a collection for a GC generation runs and frees the circuit, you must validate the memory against the GC stats, not the process, as .NET might decide to keep the virtual memory active.

If the memory isn't freed, you must find a circuit that isn't either active or disconnected and that's rooted by another object in the framework. In any other case, the inability to free memory is an app issue in developer code.

Reduce memory usage

Adopt any of the following strategies to reduce an app's memory usage:

• Limit the total amount of memory used by the .NET process. For more information, see Runtime configuration options for garbage collection.
• Reduce the number of disconnected circuits.
• Reduce the time a circuit is allowed to be in the disconnected state.
• Trigger a garbage collection manually to perform a collection during downtime periods.
• Configure the garbage collection in Workstation mode, which aggressively triggers garbage collection, instead of Server mode.

Heap size for some mobile device browsers

When building a Blazor app that runs on the client and targets mobile device browsers, especially Safari on iOS, decreasing the maximum memory for the app with the MSBuild property EmccMaximumHeapSize may be required. For more information, see Host and deploy ASP.NET Core Blazor WebAssembly.

Additional actions and considerations

• Capture a memory dump of the process when memory demands are high and identify the objects are taking the most memory and where are those objects are rooted (what holds a reference to them).
• You can examine the statistics on how memory in your app is behaving using dotnet-counters. For more information see Investigate performance counters (dotnet-counters).
• Even when a GC is triggered, .NET holds on to the memory instead of returning it to the OS immediately, as it's likely that it will reuse the memory the near future. This avoids committing and decommitting memory constantly, which is expensive. You'll see this reflected if you use dotnet-counters because you'll see the GCs happen and the amount of used memory go down to 0 (zero), but you won't see the working set counter decrease, which is the sign that .NET is holding on to the memory to reuse it. For more information on project file (.csproj) settings to control this behavior, see Runtime configuration options for garbage collection.
• Server GC doesn't trigger garbage collections until it determines it's absolutely necessary to do so to avoid freezing your app and considers that your app is the only thing running on the machine, so it can use all the memory in the system. If the system has 50 GB, the garbage collector seeks to use the full 50 GB of available memory before it triggers a Gen 2 collection.
• For information on disconnected circuit retention configuration, see ASP.NET Core Blazor SignalR guidance.

Measuring memory

• Publish the app in Release configuration.
• Run a published version of the app.
• Don't attach a debugger to the running app.
• Does triggering a Gen 2 forced, compacting collection (GC.Collect(2, GCCollectionMode.Aggressive | GCCollectionMode.Forced, blocking: true, compacting: true)) free the memory?
• Consider if your app is allocating objects on the large object heap.
• Are you testing the memory growth after the app is warmed up with requests and processing? Typically, there are caches that are populated when code executes for the first time that add a constant amount of memory to the footprint of the app.