Testowanie gęstości połączenia usługi SignalR za pomocą funkcji Crank

  • Artykuł

– autor Tom FitzMacken

Ostrzeżenie

Ta dokumentacja nie jest przeznaczona dla najnowszej wersji usługi SignalR. Przyjrzyj się ASP.NET Core SignalR.

W tym artykule opisano sposób używania narzędzia Crank do testowania aplikacji z wieloma symulowanymi klientami.

Po uruchomieniu aplikacji w jej środowisku hostingu (roli internetowej platformy Azure, usług IIS lub własnego hostowania przy użyciu Owin), możesz przetestować odpowiedź aplikacji na wysoki poziom gęstości połączenia przy użyciu narzędzia Korb. Środowisko hostingu może być serwerem usług Internet Information Services (IIS), hostem Owin lub rolą internetową platformy Azure. (Uwaga: liczniki wydajności nie są dostępne w Azure App Service Web Apps, więc nie będzie można uzyskać danych wydajności z testu gęstości połączenia).

Gęstość połączenia odnosi się do liczby równoczesnych połączeń TCP, które można ustanowić na serwerze. Każde połączenie TCP wiąże się z własnym obciążeniem, a otwarcie dużej liczby bezczynnych połączeń w końcu spowoduje utworzenie wąskiego gardła pamięci.

Baza kodu SignalR zawiera narzędzie do testowania obciążenia o nazwie Crank. Najnowszą wersję korby można znaleźć w gałęzi Dev w witrynie GitHub. Archiwum zip gałęzi Dev bazy kodu SignalR można pobrać tutaj.

W celu obliczenia całkowitej liczby bezczynnych połączeń na sprzęcie serwera można użyć korbowania. Alternatywnie można również użyć korby do testowania obciążenia serwera pod określoną ilością pamięci przez zwiększenie liczby połączeń do momentu osiągnięcia określonej liczby lub określonego progu pamięci.

Podczas testowania ważne jest, aby używać klientów zdalnych, aby uniknąć konkurencji dla zasobów (np. połączeń TCP i pamięci). Monitoruj klientów, aby upewnić się, że nie napotykają żadnych wąskich gardeł, które mogą uniemożliwić serwerowi osiągnięcie pełnej pojemności (pamięci lub procesora CPU). Może być konieczne zwiększenie liczby klientów w celu pełnego załadowania serwera.

Uruchamianie testu gęstości połączenia

W tej sekcji opisano kroki wymagane do uruchomienia testu gęstości połączenia w aplikacji SignalR.

  1. Pobierz i skompiluj gałąź dev bazy kodu usługi SignalR. W wierszu polecenia przejdź do <katalogu> projektu\src\Microsoft.AspNet.SignalR.Crank\bin\debug.
  2. Wdróż aplikację w zamierzonym środowisku hostingu. Zanotuj punkt końcowy używany przez aplikację; na przykład w aplikacji utworzonej w samouczku Wprowadzenie punkt końcowy to http://<yourhost>:8080/signalr.
  3. Zainstaluj liczniki wydajności usługi SignalR na serwerze. Jeśli aplikacja jest uruchomiona na platformie Azure, zobacz Using SignalR Performance Counters in an Azure Web Role (Używanie liczników wydajności usługi SignalR w roli internetowej platformy Azure).

Po pobraniu i utworzeniu bazy kodu oraz zainstalowaniu liczników wydajności na hoście narzędzie wiersza polecenia Crank można znaleźć w folderze src\Microsoft.AspNet.SignalR.Crank\bin\Debug .

Dostępne opcje narzędzia korbowego obejmują:

  • /?: Wyświetla ekran pomocy. Dostępne opcje są również wyświetlane, jeśli parametr adresu URL zostanie pominięty.
  • /Url: adres URL połączeń usługi SignalR. Ten parametr jest wymagany. W przypadku aplikacji SignalR używającej mapowania domyślnego ścieżka zakończy się ciągiem "/signalr".
  • /Transport: nazwa używanego transportu. Wartość domyślna to auto, która wybierze najlepszy dostępny protokół. Opcje obejmują WebSockets, ServerSentEventsi LongPolling (ForeverFrame nie jest opcją korb, ponieważ używany jest klient platformy .NET zamiast programu Internet Explorer). Aby uzyskać więcej informacji na temat sposobu wybierania transportów przez usługę SignalR, zobacz Transports and Fallbacks (Transports and Fallbacks).
  • /BatchSize: liczba klientów dodanych w każdej partii. Domyślna wartość wynosi 50.
  • /ConnectInterval: interwał w milisekundach między dodawaniem połączeń. Wartość domyślna to 500.
  • /Połączenia: liczba połączeń używanych do testowania obciążenia aplikacji. Wartość domyślna to 100 000.
  • /ConnectTimeout: limit czasu w sekundach przed przerwaniem testu. Wartość domyślna to 300.
  • MinServerMBytes: minimalna liczba megabajtów serwera do osiągnięcia. Wartość domyślna to 500.
  • SendBytes: rozmiar ładunku wysyłanego do serwera w bajtach. Wartość domyślna to 0.
  • SendInterval: opóźnienie w milisekundach między komunikatami na serwerze. Wartość domyślna to 500.
  • SendTimeout: limit czasu w milisekundach dla komunikatów na serwerze. Wartość domyślna to 300.
  • ControllerUrl: adres URL, w którym jeden klient będzie hostować centrum kontrolera. Wartość domyślna to null (bez koncentratora kontrolera). Centrum kontrolera jest uruchamiane po rozpoczęciu sesji korbowania; nie nawiązano dalszego kontaktu między koncentratorem kontrolera a korbą.
  • NumClients: liczba symulowanych klientów do nawiązania połączenia z aplikacją. Wartość domyślna to jeden.
  • Logfile: nazwa pliku dziennika dla przebiegu testu. Wartość domyślna to crank.csv.
  • SampleInterval: czas w milisekundach między przykładami licznika wydajności. Wartość domyślna to 1000.
  • SignalRInstance: nazwa wystąpienia liczników wydajności na serwerze. Wartością domyślną jest użycie stanu połączenia klienta.

Przykład

Następujące polecenie przetestuje witrynę o nazwie pfsignalr na platformie Azure, która hostuje aplikację na porcie 8080 z centrum o nazwie "ControllerHub" przy użyciu 100 połączeń.

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