Héberger et déployer des applications Blazor côté serveur

Cet article explique comment héberger et déployer des applications Blazor côté serveur (applications Blazor Web App et Blazor Server) avec ASP.NET Core.

Valeurs de configuration de l’hôte

Les applications Blazor côté serveur peuvent accepter les valeurs de configuration d’hôte générique.

Déploiement

En utilisant un modèle d’hébergement côté serveur, Blazor est exécutée sur le serveur à partir d’une application ASP.NET Core. Les mises à jour de l’interface utilisateur, la gestion des événements et les appels JavaScript sont gérés par le biais d’une connexion SignalR.

Un serveur web capable d’héberger une application ASP.NET Core est nécessaire. Visual Studio inclut un modèle de projet d’application côté serveur. Pour plus d’informations sur les modèles de projet Blazor, consultez ASP.NET structure de projet principale Blazor.

Publiez une application dans la configuration Release et déployez le contenu du dossier bin/Release/{TARGET FRAMEWORK}/publish, où l’espace réservé {TARGET FRAMEWORK} est le framework cible.

Évolutivité

Lorsque vous envisagez la scalabilité d’un serveur unique (scale-up), la mémoire disponible pour une application est probablement la première ressource que l’application épuise à mesure que les demandes des utilisateurs augmentent. La mémoire disponible sur le serveur affecte :

• Le nombre de circuits actifs qu’un serveur peut prendre en charge.
• La latence de l’interface utilisateur sur le client.

Pour obtenir des conseils sur la génération d’applications côté Blazor serveur sécurisées et évolutives, consultez les ressources suivantes :

• Conseils d’atténuation des menaces pour le rendu statique côté serveur de Blazor ASP.NET Core
• Conseils d’atténuation des menaces pour le rendu interactif côté serveur de Blazor ASP.NET Core

Chaque circuit utilise environ 250 Ko de mémoire pour une application de style Hello World minimale. La taille d’un circuit dépend du code de l’application et des exigences de maintenance d’état associées à chaque composant. Nous vous recommandons de mesurer les demandes de ressources pendant le développement de votre application et de votre infrastructure, mais la base de référence suivante peut être un point de départ dans la planification de votre cible de déploiement : si vous prévoyez que votre application prenne en charge 5 000 utilisateurs simultanés, envisagez de budgéter au moins 1,3 Go de mémoire serveur pour l’application (ou environ 273 Ko par utilisateur).

Configuration SignalR

Les conditions d’hébergement et de mise à l’échelle de SignalR s’appliquent aux applications Blazor qui utilisent SignalR.

Pour plus d’informations sur les applications SignalR intégrées sur Blazor, y compris des conseils de configuration, consultez les conseils BlazorSignalR ASP.NET Core.

Azure App Service

L’hébergement sur Azure App Service nécessite une configuration pour WebSockets et l’affinité de session, également appelée Application Request Routing.

Activez les éléments suivants pour l’inscription de l’application dans Azure App Service :

• WebSockets pour permettre au transport WebSockets de fonctionner. La valeur par défaut est Off.
• Affinité de session pour acheminer les requêtes d’un utilisateur vers la même instance App Service. Le paramètre par défaut est On.

1. Dans le portail Azure, accéder à l’application web dans App Services.
2. Ouvrez Paramètres>Configuration.
3. Définissez Web sockets sur On.
4. Vérifiez que l’affinité de session est définie sur On.

Service Azure SignalR

Le Azure SignalR Service fonctionne conjointement avec le hub SignalR de l’application pour effectuer le scale-out d’une application côté serveur vers un grand nombre de connexions simultanées. De plus, la portée générale du service et les centres de données hautes performances contribuent de manière significative à réduire la latence due aux emplacements géographiques.

Le service n’est pas nécessaire pour les applications Blazor hébergées dans Azure App Service ou Azure Container Apps, mais peut être utile dans d’autres environnements d’hébergement :

• Pour faciliter le scale-out de la connexion.
• Gérer la distribution globale

Dans le cas où l’application utilise l’interrogation longue ou renvient à l’interrogation longue au lieu de WebSockets, vous devrez peut-être configurer l’intervalle d’interrogation maximal (MaxPollIntervalInSeconds, par défaut : 5 secondes, limite : 1-300 secondes), qui définit l’intervalle d’interrogation maximal autorisé pour les connexions d’interrogation longue dans le Azure SignalR Service. Si la requête d’interrogation suivante n’arrive pas dans l’intervalle d’interrogation maximal, le service ferme la connexion cliente.

Pour obtenir des conseils sur l’ajout du service en tant que dépendance à un déploiement de production, consultez Publier une application SignalR ASP.NET Core sur Azure App Service.

Pour plus d’informations, consultez l’article suivant :

• Azure SignalR Service
• Qu’est-ce qu’Azure SignalR Service ?
• ASP.NET Core SignalR hébergement et mise à l’échelle de production
• Publier une application ASP.NET Core SignalR sur Azure App Service

IIS

Lorsque vous utilisez IIS, activez :

• WebSockets sur IIS.
• Affinité de session avec Application Request Routing.

Pour plus d’informations, consultez les conseils et les liens croisés des ressources IIS externes dans Publier une application ASP.NET Core sur IIS.

Kubernetes

Créez une définition d’entrée avec les annotations Kubernetes suivantes pour l’affinité de session :

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 avec Nginx

Suivez les instructions pour une application ASP.NET Core SignalR avec les modifications suivantes :

• Remplacez le chemin d’accès location de /hubroute (location /hubroute { ... }) par le chemin racine / (location / { ... }).
• Supprimez la configuration de la mise en mémoire tampon du proxy (proxy_buffering off;), car le paramètre s’applique uniquement aux événements envoyés par le serveur (SSE), qui ne sont pas pertinents pour les interactions client-serveur de l’applicationBlazor.

Pour plus d’informations et pour obtenir de l’aide sur la configuration, consultez les ressources suivantes :

• ASP.NET Core SignalR hébergement et mise à l’échelle de production
• Héberger ASP.NET Core sur Linux avec Nginx
• Configurer ASP.NET Core pour l’utilisation de serveurs proxy et d’équilibreurs de charge
• NGINX en tant que proxy WebSocket
• Proxy WebSocket
• Contactez des développeurs sur des forums d’assistance non-Microsoft :
  • Dépassement de capacité de la pile (étiquette : blazor)
  • Équipe ASP.NET Core Slack
  • Blazor Gitter

Linux avec Apache

Pour héberger une application Blazor derrière Apache sur Linux, configurez ProxyPass le trafic HTTP et WebSockets.

Dans l’exemple suivant :

• Kestrel le serveur s’exécute sur l’ordinateur hôte.
• L’application écoute le trafic sur le 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/

Activez les modules suivants :

a2enmod   proxy
a2enmod   proxy_wstunnel

Vérifiez les erreurs WebSockets dans la console du navigateur. Exemples d’erreurs :

• Firefox ne peut pas établir de connexion au serveur à l’adresse ws://the-domain-name.tld/_blazor?id=XXX
• Erreur : échec du démarrage du transport « WebSockets » : Erreur : une erreur s’est produite avec le transport.
• Erreur : échec du démarrage du transport « Interrogation longue » : TypeError : this.transport is undefined
• Erreur : impossible de se connecter au serveur avec l’un des transports disponibles. Échec des WebSockets
• Erreur : impossible d’envoyer des données si la connexion n’est pas dans l’état « Connecté ».

Pour plus d’informations et pour obtenir de l’aide sur la configuration, consultez les ressources suivantes :

• Configurer ASP.NET Core pour l’utilisation de serveurs proxy et d’équilibreurs de charge
• Documentation Apache
• Contactez des développeurs sur des forums d’assistance non-Microsoft :
  • Dépassement de capacité de la pile (étiquette : blazor)
  • Équipe ASP.NET Core Slack
  • Blazor Gitter

Mesurer la latence réseau

JS L’interopérabilité peut être utilisée pour mesurer la latence du réseau, comme le montre l’exemple suivant.

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();
        }
    }
}

Pour une expérience d’interface utilisateur raisonnable, nous recommandons une latence soutenue de l’interface utilisateur de 250 ms ou moins.

Gestion de la mémoire

Sur le serveur, un nouveau circuit est créé pour chaque session utilisateur. Chaque session utilisateur correspond au rendu d’un seul document dans le navigateur. Par exemple, plusieurs onglets créent plusieurs sessions.

Blazor maintient une connexion constante au navigateur, appelé circuit, qui a lancé la session. Les connexions peuvent être perdues à tout moment pour plusieurs raisons, par exemple lorsque l’utilisateur perd la connectivité réseau ou ferme brusquement le navigateur. En cas de perte de connexion, Blazor dispose d’un mécanisme de récupération qui place un nombre limité de circuits dans un pool « déconnecté », ce qui donne aux clients un délai limité pour se reconnecter et rétablir la session (par défaut : 3 minutes).

Après ce délai, Blazor libère le circuit et ignore la session. À partir de ce moment, le circuit est éligible pour le garbage collection (GC) et est revendiqué lorsqu’une collecte pour la génération GC du circuit est déclenchée. Un aspect important à comprendre est que les circuits ont une longue durée de vie, ce qui signifie que la plupart des objets enracinés par le circuit atteignent finalement Gen 2. Par conséquent, il se peut que vous ne voyiez pas ces objets libérés tant qu’une collection Gen 2 n’a pas été effectuée.

Mesurer l’utilisation de la mémoire en général

Conditions préalables :

• L’application doit être publiée dans la configuration Release. Les mesures de configuration de débogage ne sont pas pertinentes, car le code généré n’est pas représentatif du code utilisé pour un déploiement de production.
• L’application doit s’exécuter sans débogueur attaché, car cela peut également affecter le comportement de l’application et gâcher les résultats. Dans Visual Studio, démarrez l’application sans débogage en sélectionnant>Démarrer sans débogage dans la barre de menus ou Ctrl+F5 à l’aide du clavier.
• Considérez les différents types de mémoire pour comprendre la quantité de mémoire réellement utilisée par .NET. En règle générale, les développeurs inspectent l’utilisation de la mémoire des applications dans le Gestionnaire des tâches sur le système d’exploitation Windows, qui offre généralement une limite supérieure de la mémoire réelle utilisée. Pour plus d’informations, consultez les articles suivants :
  • Analyse des performances de la mémoire .NET : en particulier, consultez la section Notions de base de la mémoire.
  • Flux de travail du diagnostic des problèmes de performances de mémoire (série en trois parties) : les liens vers les trois articles de la série sont en haut de chaque article de la série.

Utilisation de la mémoire appliquée à Blazor

Nous calculons la mémoire utilisée par blazor comme suit :

(Circuits actifs × mémoire par circuit) + (Circuits déconnectés × mémoire par circuit)

La quantité de mémoire utilisée par un circuit et le nombre maximal de circuits actifs potentiels qu’une application peut gérer dépendent en grande partie de la façon dont l’application est écrite. Le nombre maximal de circuits actifs possibles est approximativement décrit par :

Mémoire / disponible maximale Mémoire = par circuit Nombre maximal de circuits actifs potentiels

Pour qu’une fuite de mémoire se produise dans Blazor, les éléments suivants doivent être vrais :

• La mémoire doit être allouée par l’infrastructure, pas par l’application. Si vous allouez un tableau de 1 Go dans l’application, l’application doit gérer la suppression du tableau.
• La mémoire ne doit pas être utilisée activement, ce qui signifie que le circuit n’est pas actif et a été supprimé du cache des circuits déconnectés. Si le nombre maximal de circuits actifs est en cours d’exécution, le manque de mémoire est un problème de mise à l’échelle, et non une fuite de mémoire.
• Un garbage collection (GC) pour la génération GC du circuit a été exécuté, mais le garbage collector n’a pas pu revendiquer le circuit, car un autre objet de l’infrastructure contient une référence forte au circuit.

Dans d’autres cas, il n’y a pas de fuite de mémoire. Si le circuit est actif (connecté ou déconnecté), il est toujours en cours d’utilisation.

Si une collection pour la génération GC du circuit ne s’exécute pas, la mémoire n’est pas libérée, car le garbage collector n’a pas besoin de libérer la mémoire à ce moment-là.

Si une collection pour une génération GC s’exécute et libère le circuit, vous devez valider la mémoire par rapport aux statistiques GC, et non au processus, car .NET peut décider de maintenir la mémoire virtuelle active.

Si la mémoire n’est pas libérée, vous devez trouver un circuit qui n’est ni actif ni déconnecté et qui est enraciné par un autre objet dans l’infrastructure. Dans tous les autres cas, l’impossibilité de libérer de la mémoire est un problème d’application dans le code du développeur.

Réduisez l’utilisation de la mémoire

Adoptez l’une des stratégies suivantes pour réduire l’utilisation de la mémoire d’une application :

• Limitez la quantité totale de mémoire utilisée par le processus .NET. Pour plus d’informations, consultez Options de configuration d’exécution pour le garbage collection.
• Réduisez le nombre de circuits déconnectés.
• Réduisez le temps pendant lequel un circuit est autorisé à être à l’état déconnecté.
• Déclenchez un garbage collection manuellement pour effectuer une collecte pendant les périodes d’arrêt.
• Configurez le garbage collection en mode Station de travail, qui déclenche de manière agressive le garbage collection, au lieu du mode Serveur.

Taille du tas pour certains navigateurs d’appareils mobiles

Lors de la création d’une application Blazor qui s’exécute sur le client et cible les navigateurs d’appareils mobiles, en particulier Safari sur iOS, il peut être nécessaire de diminuer la mémoire maximale pour l’application avec la propriété MSBuild EmccMaximumHeapSize. Pour plus d’informations, consultez Héberger et déployer ASP.NET Core Blazor WebAssembly.

Actions et considérations supplémentaires

• Capturez un vidage de la mémoire du processus lorsque les besoins en mémoire sont élevés et identifiez les objets qui prennent le plus de mémoire et où ces objets sont enracinés (ce qui contient une référence à eux).
• Vous pouvez examiner les statistiques sur le comportement de la mémoire dans votre application en utilisant dotnet-counters. Pour plus d’informations, consultez Examiner les compteurs de performances (dotnet-counters).
• Même quand une GC (Garbage Collection) est déclenchée, .NET conserve la mémoire au lieu de la renvoyer immédiatement au système d’exploitation, car il est probable qu’il va réutiliser la mémoire dans un avenir proche. Ceci évite de commiter et de décommiter constamment la mémoire, ce qui est coûteux en ressources. Vous verrez que cela se reflète si vous utilisez dotnet-counters, car vous allez voir que les GC se produisent et que la quantité de mémoire utilisée descend à 0 (zéro), mais vous ne verrez pas le compteur de la plage de travail diminuer, ce qui est le signe que .NET conserve la mémoire pour la réutiliser. Pour plus d’informations sur les paramètres de fichier projet (.csproj) pour contrôler ce comportement, consultez Options de configuration d’exécution pour le garbage collection.
• La GC du serveur ne déclenche pas de garbage collections tant qu’elle ne détermine pas qu’il est absolument nécessaire de le faire pour éviter de figer votre application et considère que votre application est la seule chose en cours d’exécution sur la machine : elle peut donc utiliser toute la mémoire du système. Si le système a 50 Go, le garbage collector cherche à utiliser la totalité de la mémoire disponible de 50 Go avant de déclencher une collecte Gen 2.
• Pour plus d’informations sur la configuration de la rétention de circuit déconnecté, consultez ASP.NET Core BlazorSignalR instructions.

Mesure de la mémoire

• Publiez l’application dans la configuration Release.
• Exécutez une version publiée de l’application.
• N’attachez pas un débogueur à l’application en cours d’exécution.
• Le déclenchement d’un nettoyage de compactage forcé Gen 2 (GC.Collect(2, GCCollectionMode.Aggressive | GCCollectionMode.Forced, blocking: true, compacting: true)) libère-t-il la mémoire ?
• Déterminez si votre application alloue des objets sur le tas des grands objets.
• Testez-vous la croissance de la mémoire une fois que l’application reçoit des requêtes et effectue des traitements ? En général, il existe des caches qui sont remplis quand le code s’exécute pour la première fois, ce qui ajoute une quantité constante de mémoire à l’empreinte de l’application.