Partager via

Performances de SignalR (SignalR 1.x)

  • Article

par Patrick Fletcher

Avertissement

Cette documentation ne concerne pas la dernière version de SignalR. Consultez ASP.NET Core SignalR.

Cette rubrique explique comment concevoir, mesurer et améliorer les performances dans une application SignalR.

Pour une présentation récente sur les performances et la mise à l’échelle de SignalR, consultez Mise à l’échelle du web en temps réel avec ASP.NET SignalR.

Cette rubrique contient les sections suivantes :

Remarques relatives à la conception

Cette section décrit les modèles qui peuvent être implémentés lors de la conception d’une application SignalR, afin de garantir que les performances ne sont pas entravées par la génération d’un trafic réseau inutile.

Limitation de la fréquence des messages

Même dans une application qui envoie des messages à une fréquence élevée (par exemple, une application de jeu en temps réel), la plupart des applications n’ont pas besoin d’envoyer plus de quelques messages par seconde. Pour réduire la quantité de trafic générée par chaque client, une boucle de message peut être implémentée qui met en file d’attente et n’envoie pas de messages plus fréquemment qu’un débit fixe (autrement dit, jusqu’à un certain nombre de messages seront envoyés toutes les secondes, s’il y a des messages à envoyer dans cet intervalle de temps). Pour obtenir un exemple d’application qui limite les messages à un certain débit (à partir du client et du serveur), consultez Haute fréquence en temps réel avec SignalR.

Réduction de la taille des messages

Vous pouvez réduire la taille d’un message SignalR en réduisant la taille de vos objets sérialisés. Dans le code du serveur, si vous envoyez un objet qui contient des propriétés qui n’ont pas besoin d’être transmises, empêchez ces propriétés d’être sérialisées à l’aide de l’attribut JsonIgnore . Les noms des propriétés sont également stockés dans le message ; les noms des propriétés peuvent être raccourcis à l’aide de l’attribut JsonProperty . L’exemple de code suivant montre comment exclure une propriété de l’envoi au client et comment raccourcir les noms de propriétés :

Code serveur .NET qui illustre l’attribut JsonIgnore pour exclure les données d’être envoyées au client, et l’attribut JsonProperty pour réduire la taille des messages

using Newtonsoft.Json; 
using System; 
public class ShapeModel
{
[JsonProperty("l")]
    public double Left { get; set; }
[JsonProperty("t")]
    public double Top { get; set; }
    // We don't want the client to get the "LastUpdatedBy" property
[JsonIgnore]
    public string LastUpdatedBy { get; set; }
}

Afin de conserver la lisibilité/la facilité de maintenance dans le code client, les noms de propriétés abrégées peuvent être réinitajustés en noms conviviaux une fois le message reçu. L’exemple de code suivant illustre une façon possible de réappliquer des noms raccourcis en noms plus longs, en définissant un contrat de message (mappage) et en utilisant la reMap fonction pour appliquer le contrat à la classe de message optimisée :

Code JavaScript côté client qui remappage des noms de propriétés raccourcis en noms lisibles par l’utilisateur

function reMap(smallObject, contract) {
    var largeObject = {};
    for (var smallProperty in contract) {
        largeObject[contract[smallProperty]] = smallObject[smallProperty];
    }
    return largeObject;
}
var shapeModelContract = {
    l: "left",
    t: "top"
};
myHub.client.setShape = function (shapeModelSmall) {
    var shapeModel = reMap(shapeModelSmall, shapeModelContract);
    // shapeModelSmall has "l" and "t" properties  but after remapping
    // shapeModel now has "left" and "top" properties
};

Les noms peuvent également être raccourcis dans les messages du client au serveur, à l’aide de la même méthode.

La réduction de l’empreinte mémoire (c’est-à-dire la quantité de mémoire utilisée pour le message) de l’objet de message peut également améliorer les performances. Par exemple, si la plage complète d’un int n’est pas nécessaire, un short ou byte peut être utilisé à la place.

Étant donné que les messages sont stockés dans la bus de messages dans la mémoire du serveur, la réduction de la taille des messages peut également résoudre les problèmes de mémoire du serveur.

Réglage de votre serveur SignalR pour les performances

Les paramètres de configuration suivants peuvent être utilisés pour optimiser les performances de votre serveur dans une application SignalR. Pour obtenir des informations générales sur l’amélioration des performances dans une application ASP.NET, consultez Amélioration des performances ASP.NET.

Paramètres de configuration de SignalR

  • DefaultMessageBufferSize : par défaut, SignalR conserve 1 000 messages en mémoire par hub et par connexion. Si des messages volumineux sont utilisés, cela peut créer des problèmes de mémoire qui peuvent être atténués en réduisant cette valeur. Ce paramètre peut être défini dans le Application_Start gestionnaire d’événements d’une application ASP.NET ou dans la Configuration méthode d’une classe de démarrage OWIN dans une application auto-hébergée. L’exemple suivant montre comment réduire cette valeur afin de réduire l’empreinte mémoire de votre application afin de réduire la quantité de mémoire du serveur utilisée :

    Code serveur .NET dans Global.asax pour réduire la taille de la mémoire tampon de message par défaut

    protected void Application_Start(object sender, EventArgs e)
{
    GlobalHost.Configuration.DefaultMessageBufferSize = 500;
}

Paramètres de configuration IIS

  • Nombre maximal de requêtes simultanées par application : l’augmentation du nombre de requêtes IIS simultanées augmente les ressources serveur disponibles pour le traitement des demandes. La valeur par défaut est 5000 ; pour augmenter ce paramètre, exécutez les commandes suivantes dans une invite de commandes avec élévation de privilèges :

    cd %windir%\System32\inetsrv\
appcmd.exe set config /section:system.webserver/serverRuntime 
        /appConcurrentRequestLimit:10000

ASP.NET paramètres de configuration

Cette section inclut les paramètres de configuration qui peuvent être définis dans le aspnet.config fichier. Ce fichier se trouve dans l’un des deux emplacements, selon la plateforme :

  • %windir%\Microsoft.NET\Framework\v4.0.30319\aspnet.config
  • %windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet.config

ASP.NET paramètres susceptibles d’améliorer les performances de SignalR sont les suivants :

  • Nombre maximal de requêtes simultanées par processeur : L’augmentation de ce paramètre peut réduire les goulots d’étranglement des performances. Pour augmenter ce paramètre, ajoutez le paramètre de configuration suivant au aspnet.config fichier :

    <?xml version="1.0" encoding="UTF-8" ?>
<configuration>
    <system.web>
        <applicationPool maxConcurrentRequestsPerCPU="20000" />
    </system.web>
</configuration>

  • Limite de file d’attente des demandes : lorsque le nombre total de connexions dépasse le maxConcurrentRequestsPerCPU paramètre, ASP.NET commence à limiter les requêtes à l’aide d’une file d’attente. Pour augmenter la taille de la file d’attente, vous pouvez augmenter le requestQueueLimit paramètre. Pour ce faire, ajoutez le paramètre de configuration suivant au processModel nœud dans config/machine.config (plutôt que aspnet.config) :

    <processModel autoConfig="false" requestQueueLimit="250000" />

Résolution des problèmes de performances

Cette section décrit les moyens de trouver les goulots d’étranglement des performances dans votre application.

Vérification de l’utilisation de WebSocket

Alors que SignalR peut utiliser divers transports pour la communication entre le client et le serveur, WebSocket offre un avantage significatif en matière de performances et doit être utilisé si le client et le serveur le prennent en charge. Pour déterminer si votre client et votre serveur répondent aux exigences de WebSocket, consultez Transports et secours. Pour déterminer le transport utilisé dans votre application, vous pouvez utiliser les outils de développement du navigateur et examiner les journaux pour voir quel transport est utilisé pour la connexion. Pour plus d’informations sur l’utilisation des outils de développement de navigateur dans Internet Explorer et Chrome, consultez Transports et secours.

Utilisation des compteurs de performances SignalR

Cette section explique comment activer et utiliser les compteurs de performances SignalR, qui se trouvent dans le Microsoft.AspNet.SignalR.Utils package.

Installation de signalr.exe

Des compteurs de performances peuvent être ajoutés au serveur à l’aide d’un utilitaire appelé SignalR.exe. Pour installer cet utilitaire, procédez comme suit :

  1. Dans Visual Studio, sélectionnez Outils> Gestionnaire >de package NuGetGérer les packages NuGet pour la solution

  2. Recherchez signalr.utils, puis sélectionnez Installer.

    Capture d’écran montrant Microsoft A S P dot NET Signal R Utilities Utilitaires de ligne de commande pour A S P dot NET Signal R mis en surbrillance.

  3. Acceptez le contrat de licence pour installer le package.

  4. SignalR.exe sera installé sur <project folder>/packages/Microsoft.AspNet.SignalR.Utils.<version>/tools.

Installation de compteurs de performances avec SignalR.exe

Pour installer des compteurs de performances SignalR, exécutez SignalR.exe dans une invite de commandes avec élévation de privilèges avec le paramètre suivant :

SignalR.exe ipc

Pour supprimer les compteurs de performances SignalR, exécutez SignalR.exe dans une invite de commandes avec élévation de privilèges avec le paramètre suivant :

SignalR.exe upc

Compteurs de performances SignalR

Le package d’utilitaires installe les compteurs de performances suivants. Les compteurs « Total » mesurent le nombre d’événements depuis le dernier redémarrage du pool d’applications ou du serveur.

Métriques de connexion

Les métriques suivantes mesurent les événements de durée de vie de connexion qui se produisent. Pour plus d’informations, consultez Compréhension et gestion des événements de durée de vie de connexion.

  • Connexions connectées
  • Connexions reconnectées
  • Connexions déconnectées
  • Connexions actuelles

Métriques de message

Les métriques suivantes mesurent le trafic de messages généré par SignalR.

  • Total des messages de connexion reçus
  • Total des messages de connexion envoyés
  • Messages de connexion reçus/s
  • Messages de connexion envoyés/s

Métriques du bus de messages

Les métriques suivantes mesurent le trafic via le bus de messages SignalR interne, la file d’attente dans laquelle tous les messages SignalR entrants et sortants sont placés. Un message est publié lorsqu’il est envoyé ou diffusé. Un Abonné dans ce contexte est un abonnement sur le bus de messages ; cela doit être égal au nombre de clients plus le serveur lui-même. Un worker alloué est un composant qui envoie des données aux connexions actives ; un travailleur occupé est celui qui envoie activement un message.

  • Nombre total de messages reçus par Message Bus
  • Messages de bus de messages reçus/s
  • Total des messages de bus de messages publiés
  • Messages de bus de messages publiés/s
  • Abonnés de Bus de messages en cours
  • Nombre total d’abonnés à Message Bus
  • Abonnés du bus de messages/s
  • Workers alloués au bus de messages
  • Travailleurs occupés de Message Bus
  • Rubriques du bus de messages en cours

Métriques d’erreur

Les métriques suivantes mesurent les erreurs générées par le trafic de messages SignalR. Les erreurs de résolution du hub se produisent lorsqu’une méthode hub ou hub ne peut pas être résolue. Les erreurs d’appel hub sont des exceptions levées lors de l’appel d’une méthode hub. Les erreurs de transport sont des erreurs de connexion levées lors d’une requête ou d’une réponse HTTP.

  • Erreurs : Total
  • Erreurs : Tout/s
  • Erreurs : Total de la résolution du hub
  • Erreurs : Résolution du hub/s
  • Erreurs : Total de l’appel hub
  • Erreurs : Appel hub/s
  • Erreurs : Total du transport
  • Erreurs : Transport/s

Métriques scaleout

Les métriques suivantes mesurent le trafic et les erreurs générées par le fournisseur de scaleout. Un flux dans ce contexte est une unité de mise à l’échelle utilisée par le fournisseur de scale-out ; il s’agit d’un tableau si SQL Server est utilisé, d’une rubrique si Service Bus est utilisé et d’un abonnement si Redis est utilisé. Par défaut, un seul flux est utilisé, mais il peut être augmenté via la configuration sur SQL Server et Service Bus. Un flux de mise en mémoire tampon est un flux qui est entré dans un état défectueux ; lorsque le flux est à l’état défectueux, tous les messages envoyés au fond de panier échouent immédiatement jusqu’à ce que le flux ne soit plus défectueux. La longueur de la file d’attente d’envoi correspond au nombre de messages qui ont été publiés mais qui n’ont pas encore été envoyés.

  • Messages de bus de messages scaleout reçus/s
  • Total des flux scaleout
  • Scaleout Streams Open
  • Mise en mémoire tampon des flux scaleout
  • Nombre total d’erreurs de scaleout
  • Erreurs de scale-out/s
  • Longueur de la file d’attente d’envoi scaleout

Pour plus d’informations sur la mesure de ces compteurs, consultez Scaleout SignalR avec Azure Service Bus.

Utilisation d’autres compteurs de performances

Les compteurs de performances suivants peuvent également être utiles pour superviser les performances de votre application.

Mémoire

  • Octets de mémoire CLR .NET dans tous les tas (pour w3wp)

ASP.NET

  • ASP.NET\Requêtes actuelles
  • ASP.NET\Mis en file d’attente
  • ASP.NET\Rejeté

UC

  • Informations du processeur\Temps processeur

TCP/IP

  • TCPv6/Connexions établies
  • TCPv4/Connexions établies

Service Web

  • Service web\Connexions actuelles
  • Service web\Nombre maximal de connexions

Threads

  • .NET CLR LocksAndThreads# des threads logiques actuels
  • .NET CLR LocksAnd Threads# des threads physiques actuels

Autres ressources

Pour plus d’informations sur ASP.NET l’analyse et le paramétrage des performances, consultez les rubriques suivantes :