Wydajność usługi SignalR (SignalR 1.x)

Artykuł
07/13/2023

Ostrzeżenie

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

W tym temacie opisano sposób projektowania, mierzenia i zwiększania wydajności w aplikacji SignalR.

Aby zapoznać się z najnowszą prezentacją dotyczącą wydajności i skalowania usługi SignalR, zobacz Skalowanie sieci Web w czasie rzeczywistym przy użyciu ASP.NET SignalR.

Ten temat zawiera następujące sekcje:

Zagadnienia dotyczące projektowania
Dostrajanie serwera SignalR pod kątem wydajności
Rozwiązywanie problemów z wydajnością
Używanie liczników wydajności usługi SignalR
Korzystanie z innych liczników wydajności
Inne zasoby

Zagadnienia dotyczące projektowania

W tej sekcji opisano wzorce, które można zaimplementować podczas projektowania aplikacji SignalR, aby zapewnić, że wydajność nie jest utrudniona przez generowanie niepotrzebnego ruchu sieciowego.

Częstotliwość komunikatów ograniczania przepustowości

Nawet w aplikacji, która wysyła komunikaty o wysokiej częstotliwości (na przykład aplikacji do gier w czasie rzeczywistym), większość aplikacji nie musi wysyłać więcej niż kilku komunikatów na sekundę. Aby zmniejszyć ilość ruchu generowanego przez każdego klienta, można zaimplementować pętlę komunikatów, która kolejkuje i wysyła komunikaty nie częściej niż stała szybkość (czyli do określonej liczby komunikatów będzie wysyłana co sekundę, jeśli w tym interwale czasu będą wysyłane komunikaty). Aby uzyskać przykładową aplikację, która ogranicza komunikaty do określonej szybkości (zarówno z klienta, jak i serwera), zobacz High-Frequency Realtime with SignalR (Czas rzeczywisty o wysokiej częstotliwości za pomocą usługi SignalR).

Zmniejszenie rozmiaru komunikatu

Rozmiar komunikatu usługi SignalR można zmniejszyć, zmniejszając rozmiar serializowanych obiektów. W kodzie serwera, jeśli wysyłasz obiekt zawierający właściwości, które nie muszą być przesyłane, uniemożliwić serializacji tych właściwości przy użyciu atrybutu JsonIgnore . Nazwy właściwości są również przechowywane w komunikacie; nazwy właściwości można skrócić przy użyciu atrybutu JsonProperty . W poniższym przykładzie kodu pokazano, jak wykluczyć właściwość z wysyłania do klienta oraz jak skrócić nazwy właściwości:

Kod serwera .NET, który demonstruje atrybut JsonIgnore, aby wykluczyć dane wysyłane do klienta, oraz atrybut JsonProperty w celu zmniejszenia rozmiaru komunikatu

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

Aby zachować czytelność/konserwację w kodzie klienta, skrócone nazwy właściwości można ponownie zamapować na nazwy przyjazne dla człowieka po odebraniu komunikatu. Poniższy przykładowy kod pokazuje jeden z możliwych sposobów ponownego mapowania skróconych nazw na dłuższe, definiując kontrakt komunikatu (mapowanie) i używając reMap funkcji w celu zastosowania kontraktu do zoptymalizowanej klasy komunikatów:

Kod JavaScript po stronie klienta, który ponownie mapuje skrócone nazwy właściwości na nazwy czytelne dla człowieka

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

Nazwy można również skrócić w komunikatach od klienta do serwera przy użyciu tej samej metody.

Zmniejszenie pamięci (czyli ilość pamięci używanej dla komunikatu) obiektu komunikatu może również zwiększyć wydajność. Jeśli na przykład pełny zakres elementu int nie jest potrzebny, można zamiast tego użyć elementu short lub byte .

Ponieważ komunikaty są przechowywane w magistrali komunikatów w pamięci serwera, zmniejszenie rozmiaru komunikatów może również rozwiązać problemy z pamięcią serwera.

Dostrajanie serwera SignalR pod kątem wydajności

Następujące ustawienia konfiguracji mogą służyć do dostosowywania serwera w celu uzyskania lepszej wydajności w aplikacji SignalR. Aby uzyskać ogólne informacje na temat zwiększania wydajności w aplikacji ASP.NET, zobacz Poprawianie wydajności ASP.NET.

Ustawienia konfiguracji usługi SignalR

DefaultMessageBufferSize: Domyślnie usługa SignalR zachowuje 1000 komunikatów w pamięci na koncentrator na połączenie. Jeśli są używane duże komunikaty, może to spowodować problemy z pamięcią, które można złagodzić, zmniejszając tę wartość. To ustawienie można ustawić w Application_Start procedurze obsługi zdarzeń w aplikacji ASP.NET lub w Configuration metodzie klasy uruchamiania OWIN w aplikacji hostowanej samodzielnie. W poniższym przykładzie pokazano, jak zmniejszyć tę wartość w celu zmniejszenia pamięci aplikacji w celu zmniejszenia ilości używanej pamięci serwera:

Kod serwera .NET w pliku Global.asax w celu zmniejszenia domyślnego rozmiaru buforu komunikatów
```
protected void Application_Start(object sender, EventArgs e)
{
    GlobalHost.Configuration.DefaultMessageBufferSize = 500;
}
```

Ustawienia konfiguracji usług IIS

Maksymalna liczba współbieżnych żądań na aplikację: zwiększenie liczby współbieżnych żądań usług IIS spowoduje zwiększenie dostępności zasobów serwera na potrzeby obsługi żądań. Wartość domyślna to 5000; aby zwiększyć to ustawienie, wykonaj następujące polecenia w wierszu polecenia z podwyższonym poziomem uprawnień:
```
cd %windir%\System32\inetsrv\
appcmd.exe set config /section:system.webserver/serverRuntime 
        /appConcurrentRequestLimit:10000
```

ustawienia konfiguracji ASP.NET

Ta sekcja zawiera ustawienia konfiguracji, które można ustawić w aspnet.config pliku. Ten plik znajduje się w jednej z dwóch lokalizacji, w zależności od platformy:

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

ASP.NET ustawienia, które mogą poprawić wydajność usługi SignalR, obejmują następujące elementy:

Maksymalna liczba współbieżnych żądań na procesor: zwiększenie tego ustawienia może zmniejszyć wąskie gardła wydajności. Aby zwiększyć to ustawienie, dodaj następujące ustawienie konfiguracji do aspnet.config pliku:
```
<?xml version="1.0" encoding="UTF-8" ?>
<configuration>
    <system.web>
        <applicationPool maxConcurrentRequestsPerCPU="20000" />
    </system.web>
</configuration>
```
Limit kolejki żądań: gdy łączna liczba połączeń przekracza maxConcurrentRequestsPerCPU ustawienie, ASP.NET rozpocznie ograniczanie żądań przy użyciu kolejki. Aby zwiększyć rozmiar kolejki, możesz zwiększyć requestQueueLimit ustawienie. Aby to zrobić, dodaj następujące ustawienie konfiguracji do węzła processModel w programie config/machine.config (zamiast aspnet.config):
```
<processModel autoConfig="false" requestQueueLimit="250000" />
```

Rozwiązywanie problemów z wydajnością

W tej sekcji opisano sposoby znajdowania wąskich gardeł wydajności w aplikacji.

Sprawdzanie, czy jest używany zestaw WebSocket

Usługa SignalR może używać różnych transportów do komunikacji między klientem i serwerem, jednak protokół WebSocket oferuje znaczną przewagę wydajności i powinien być używany, jeśli klient i serwer go obsługują. Aby określić, czy klient i serwer spełniają wymagania dotyczące protokołu WebSocket, zobacz Transports and Fallbacks (Transports and Fallbacks). Aby określić, jaki transport jest używany w aplikacji, możesz użyć narzędzi deweloperskich przeglądarki i zbadać dzienniki, aby zobaczyć, jaki transport jest używany do połączenia. Aby uzyskać informacje na temat korzystania z narzędzi programistycznych przeglądarki w programach Internet Explorer i Chrome, zobacz Transports and Fallbacks (Transports and Fallbacks).

Używanie liczników wydajności usługi SignalR

W tej sekcji opisano sposób włączania i używania liczników wydajności usługi SignalR znalezionych w pakiecie Microsoft.AspNet.SignalR.Utils .

Instalowanie signalr.exe

Liczniki wydajności można dodać do serwera przy użyciu narzędzia o nazwie SignalR.exe. Aby zainstalować to narzędzie, wykonaj następujące kroki:

W programie Visual Studio wybierz pozycję Narzędzia>Menedżer> pakietówNuGet Zarządzaj pakietami NuGet dla rozwiązania
Wyszukaj ciąg signalr.utils i wybierz pozycję Zainstaluj.
Zaakceptuj umowę licencyjną, aby zainstalować pakiet.
SignalR.exe zostanie zainstalowana w usłudze <project folder>/packages/Microsoft.AspNet.SignalR.Utils.<version>/tools.

Instalowanie liczników wydajności za pomocą SignalR.exe

Aby zainstalować liczniki wydajności usługi SignalR, uruchom SignalR.exe w wierszu polecenia z podwyższonym poziomem uprawnień przy użyciu następującego parametru:

SignalR.exe ipc

Aby usunąć liczniki wydajności usługi SignalR, uruchom SignalR.exe w wierszu polecenia z podwyższonym poziomem uprawnień za pomocą następującego parametru:

SignalR.exe upc

Liczniki wydajności usługi SignalR

Pakiet narzędzi instaluje następujące liczniki wydajności. Liczniki "Total" mierzy liczbę zdarzeń od czasu ostatniego ponownego uruchomienia puli aplikacji lub serwera.

Metryki połączeń

Poniższe metryki mierzą zdarzenia okresu istnienia połączenia, które występują. Aby uzyskać więcej informacji, zobacz Opis i obsługa zdarzeń okresu istnienia połączenia.

Połączenia połączone
Połączenia ponownie nawiązane
Połączenia rozłączone
Połączenia bieżące

Metryki komunikatów

Poniższe metryki mierzą ruch komunikatów generowany przez usługę SignalR.

Odebrano łączną liczbę komunikatów połączenia
Łączna liczba wysłanych komunikatów połączenia
Odebrane komunikaty połączenia/s
Komunikaty połączeń wysłane/s

Metryki magistrali komunikatów

Poniższe metryki mierzą ruch przez wewnętrzną magistralę komunikatów usługi SignalR, kolejkę, w której są umieszczane wszystkie przychodzące i wychodzące komunikaty usługi SignalR. Komunikat jest publikowany po wysłaniu lub emisji. Subskrybent w tym kontekście jest subskrypcją w magistrali komunikatów; ta wartość powinna być równa liczbie klientów i samej samej serwera. Przydzielony proces roboczy to składnik, który wysyła dane do aktywnych połączeń; Zajęty proces roboczy to taki, który aktywnie wysyła wiadomość.

Odebrano łączną liczbę komunikatów magistrali komunikatów
Odebrane komunikaty magistrali komunikatów/s
Liczba opublikowanych komunikatów magistrali komunikatów
Opublikowane komunikaty magistrali komunikatów na sekundę
Subskrybenci magistrali komunikatów bieżący
Łączna liczba subskrybentów magistrali komunikatów
Subskrybenci magistrali komunikatów/s
Przydzielone procesy robocze magistrali komunikatów
Pracownicy zajęci magistrali komunikatów
Bieżąca magistrala komunikatów

Metryki błędów

Poniższe metryki mierzą błędy generowane przez ruch komunikatów usługi SignalR. Błędy rozwiązania koncentratora występują, gdy nie można rozpoznać metody centrum lub centrum. Błędy wywołania centrum to wyjątki zgłaszane podczas wywoływania metody centrum. Błędy transportu to błędy połączenia zgłaszane podczas żądania HTTP lub odpowiedzi.

Błędy: Wszystkie sumy
Błędy: Wszystkie/s
Błędy: Suma rozwiązania koncentratora
Błędy: Rozdzielczość koncentratora/s
Błędy: Łączna liczba wywołań koncentratora
Błędy: wywołanie koncentratora/s
Błędy: Suma transportu
Błędy: Transport/s

Metryki skalowania w poziomie

Poniższe metryki mierzą ruch i błędy generowane przez dostawcę skalowania. Strumień w tym kontekście jest jednostką skalowania używaną przez dostawcę skalowania; Jest to tabela, jeśli jest używana SQL Server, temat, jeśli jest używana usługa Service Bus i subskrypcja, jeśli jest używana usługa Redis. Domyślnie jest używany tylko jeden strumień, ale można go zwiększyć za pomocą konfiguracji w usłudze SQL Server i Service Bus. Strumień buforowania to strumień, który został wprowadzony w stan błędu; gdy strumień jest w stanie błędu, wszystkie komunikaty wysyłane do płaszczyzny wstecznej będą działać natychmiast, dopóki strumień nie będzie już uszkodzony. Długość kolejki wysyłania to liczba komunikatów, które zostały opublikowane, ale nie zostały jeszcze wysłane.

Liczba odebranych komunikatów magistrali komunikatów skalowanych w poziomie na sekundę
Łączna liczba strumieni skalowanych w poziomie
Skalowanie strumieni w poziomie otwarte
Buforowanie strumieni skalowanych w poziomie
Łączna liczba błędów skalowania w poziomie
Błędy skalowania w poziomie/s
Długość kolejki wysyłania skalowalnego w poziomie

Aby uzyskać więcej informacji na temat pomiarów tych liczników, zobacz SignalR Scaleout with Azure Service Bus (Skalowanie usługi SignalR w poziomie z Azure Service Bus).

Używanie innych liczników wydajności

Poniższe liczniki wydajności mogą być również przydatne podczas monitorowania wydajności aplikacji.

Pamięć

Bajty pamięci środowiska .NET CLR we wszystkich stertach (dla w3wp)

ASP.NET

ASP.NET\Żądania bieżące
ASP.NET\Queued
ASP.NET\Odrzucone

Procesor CPU

Informacje o procesorze\Czas procesora

TCP/IP

TCPv6/Nawiązane połączenia
TCPv4/Nawiązane połączenia

Usługa sieci Web

Usługa sieci Web\Bieżące połączenia
Usługa sieci Web\Maksymalna liczba połączeń

Wątkowość

.NET CLR LocksAndThreads# bieżących wątków logicznych
.NET CLR LocksAnd Threads# bieżących wątków fizycznych

Inne zasoby

Aby uzyskać więcej informacji na temat monitorowania i dostrajania wydajności ASP.NET, zobacz następujące tematy: