Partager via

Test de la densité des connexions SignalR avec Crank

  • Article

par Tom FitzMacken

Avertissement

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

Cet article explique comment utiliser l’outil Crank pour tester une application avec plusieurs clients simulés.

Une fois que votre application s’exécute dans son environnement d’hébergement (rôle web Azure, IIS ou auto-hébergé à l’aide d’Owin), vous pouvez tester la réponse de l’application à un niveau élevé de densité de connexion à l’aide de l’outil Crank. L’environnement d’hébergement peut être un serveur IIS (Internet Information Services), un hôte Owin ou un rôle web Azure. (Remarque : les compteurs de performances ne étant pas disponibles sur Azure App Service Web Apps, vous ne pourrez pas obtenir de données de performances à partir d’un test de densité de connexion.)

La densité de connexion fait référence au nombre de connexions TCP simultanées qui peuvent être établies sur un serveur. Chaque connexion TCP entraîne sa propre surcharge et l’ouverture d’un grand nombre de connexions inactives crée un goulot d’étranglement de la mémoire.

Le codebase SignalR comprend un outil de test de charge appelé Crank. La dernière version de Crank se trouve dans la branche Dev sur GitHub. Vous pouvez télécharger une archive Zip de la branche Dev du codebase SignalR ici.

La manivelle peut être utilisée pour saturer entièrement la mémoire du serveur afin de calculer le nombre total de connexions inactives possibles sur le matériel du serveur. Vous pouvez également utiliser Crank pour tester la charge du serveur sous une certaine pression de mémoire, en augmentant les connexions jusqu’à ce qu’un nombre spécifique ou un seuil de mémoire spécifique soit atteint.

Lors du test, il est important d’utiliser le ou les clients distants pour éviter toute concurrence pour les ressources (c’est-à-dire, les connexions TCP et la mémoire). Surveillez le ou les clients pour vous assurer qu’ils n’atteignent pas de goulots d’étranglement susceptibles d’empêcher le serveur d’atteindre sa pleine capacité (mémoire ou processeur). Vous devrez peut-être augmenter le nombre de clients pour charger entièrement le serveur.

Exécution d’un test de densité de connexion

Cette section décrit les étapes nécessaires pour exécuter un test de densité de connexion sur une application SignalR.

  1. Téléchargez et générez la branche Dev du codebase SignalR. Dans une invite de commandes, accédez à <répertoire> de projet\src\Microsoft.AspNet.SignalR.Crank\bin\debug.
  2. Déployez votre application dans son environnement d’hébergement prévu. Notez le point de terminaison utilisé par votre application ; par exemple, dans l’application créée dans le tutoriel Prise en main, le point de terminaison est http://<yourhost>:8080/signalr.
  3. Installez les compteurs de performances SignalR sur le serveur. Si votre application s’exécute sur Azure, consultez Utilisation de compteurs de performances SignalR dans un rôle web Azure.

Une fois que vous avez téléchargé et généré le codebase et installé des compteurs de performances sur votre hôte, l’outil en ligne de commande Crank se trouve dans le src\Microsoft.AspNet.SignalR.Crank\bin\Debug dossier.

Les options disponibles pour l’outil Manivelle sont les suivantes :

  • /?: Affiche l’écran d’aide. Les options disponibles s’affichent également si le paramètre Url est omis.
  • /Url : URL des connexions SignalR. Ce paramètre est obligatoire. Pour une application SignalR utilisant le mappage par défaut, le chemin d’accès se termine par « /signaleur ».
  • /Transport : nom du transport utilisé. La valeur par défaut est auto, qui sélectionne le meilleur protocole disponible. Les options incluent WebSockets, ServerSentEventset LongPolling (ForeverFrame n’est pas une option pour Crank, car le client .NET plutôt que l’Explorer Internet est utilisé). Pour plus d’informations sur la façon dont SignalR sélectionne les transports, consultez Transports et secours.
  • /BatchSize : nombre de clients ajoutés dans chaque lot. La valeur par défaut est de 50.
  • /ConnectInterval : intervalle en millisecondes entre l’ajout de connexions. La valeur par défaut est 500.
  • /Connections : nombre de connexions utilisées pour tester la charge de l’application. La valeur par défaut est 100 000.
  • /ConnectTimeout : délai d’expiration en secondes avant l’abandon du test. La valeur par défaut est 300.
  • MinServerMBytes : mégaoctets de serveur minimum à atteindre. La valeur par défaut est 500.
  • SendBytes : taille de la charge utile envoyée au serveur en octets. La valeur par défaut est 0.
  • SendInterval : délai en millisecondes entre les messages vers le serveur. La valeur par défaut est 500.
  • SendTimeout : délai d’expiration en millisecondes pour les messages envoyés au serveur. La valeur par défaut est 300.
  • ControllerUrl : URL où un client hébergera un hub de contrôleur. La valeur par défaut est null (aucun hub de contrôleur). Le hub du contrôleur est démarré au démarrage de la session Crank ; aucun autre contact entre le hub du contrôleur et Crank n’est effectué.
  • NumClients : nombre de clients simulés à connecter à l’application. La valeur par défaut est 1.
  • Logfile : nom de fichier du fichier journal de la série de tests. Par défaut, il s’agit de crank.csv.
  • SampleInterval : temps en millisecondes entre les exemples de compteur de performances. La valeur par défaut est 1000.
  • SignalRInstance : nom instance des compteurs de performances sur le serveur. La valeur par défaut consiste à utiliser l’état de connexion du client.

Exemple

La commande suivante teste un site appelé pfsignalr sur Azure qui héberge une application sur le port 8080 avec un hub nommé « ControllerHub », à l’aide de 100 connexions.

crank /Connections:100 /Url:http://pfsignalr.cloudapp.net:8080/signalr