Wydajność usługi SignalR

Artykuł
07/13/2023

Ostrzeżenie

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

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

Wersje oprogramowania używane w tym temacie

Visual Studio 2013

.NET 4.5

SignalR w wersji 2

Poprzednie wersje tego tematu

Aby uzyskać informacje o wcześniejszych wersjach usługi SignalR, zobacz SignalR Starsze wersje.

Pytania i komentarze

Przekaż opinię na temat tego, jak ci się podobał ten samouczek i co możemy ulepszyć w komentarzach w dolnej części strony. Jeśli masz pytania, które nie są bezpośrednio związane z tym samouczkiem, możesz opublikować je na forum ASP.NET SignalR lub StackOverflow.com.

Aby zapoznać się z niedawną prezentacją dotyczącą wydajności i skalowania usługi SignalR, zobacz Scaling the Real-time Web with ASP.NET SignalR (Skalowanie sieci Web w czasie rzeczywistym za pomocą usługi 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
Używanie 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 mają być 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, zapobiegaj 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 i jak skrócić nazwy właściwości:

Kod serwera .NET, który demonstruje atrybut JsonIgnore, aby wykluczyć dane z wysyłania 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ść/łatwość konserwacji w kodzie klienta, skrócone nazwy właściwości można ponownie mapować na przyjazne dla człowieka nazwy po odebraniu komunikatu. Poniższy przykład kodu przedstawia 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, używając tej samej metody.

Zmniejszenie zużycia 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 dostrajania 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 programie obsługi zdarzeń w aplikacji ASP.NET lub w Configuration metodzie klasy startowej OWIN w aplikacji hostowanej samodzielnie. W poniższym przykładzie pokazano, jak zmniejszyć tę wartość, aby zmniejszyć zużycie pamięci przez aplikację w celu zmniejszenia ilości używanej pamięci serwera:

Kod serwera .NET w pliku Startup.cs w celu zmniejszenia domyślnego rozmiaru buforu komunikatów
```
public class Startup
{
    public void Configuration(IAppBuilder app)
    {
        // Any connection or hub wire up and configuration should go here
        GlobalHost.Configuration.DefaultMessageBufferSize = 500;
        app.MapSignalR();
    }
}
```

Ustawienia konfiguracji usług IIS

Maksymalna liczba współbieżnych żądań na aplikację: zwiększenie liczby współbieżnych żądań usług IIS zwiększy ilość zasobów serwera dostępnych do 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
```
ApplicationPool QueueLength: jest to maksymalna liczba żądań, które Http.sys kolejki dla puli aplikacji. Gdy kolejka jest pełna, nowe żądania otrzymają odpowiedź 503 "Usługa niedostępna". Wartość domyślna to 1000.

Skrócenie długości kolejki dla procesu roboczego w puli aplikacji hostujące aplikację spowoduje zaoszczędzenie zasobów pamięci. Aby uzyskać więcej informacji, zobacz Zarządzanie, dostrajanie i konfigurowanie pul aplikacji.

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 CPU: 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ń: jeśli łączna liczba połączeń przekroczy maxConcurrentRequestsPerCPU ustawienie, ASP.NET rozpocznie ograniczanie żądań przy użyciu kolejki. Aby zwiększyć rozmiar kolejki, możesz zwiększyć requestQueueLimit ustawienie. W tym celu 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 a serwerem, natomiast protokół WebSocket oferuje znaczącą zaletę 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 protokołu WebSocket, zobacz Transports and Fallbacks (Transporty i rezerwowe). Aby określić, jaki transport jest używany w aplikacji, możesz użyć narzędzi deweloperskich przeglądarki i sprawdzić dzienniki, aby sprawdzić, jaki transport jest używany na potrzeby 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ów NuGetZarzą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 systemie <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ń przy użyciu następującego parametru:

SignalR.exe upc

Liczniki wydajności usługi SignalR

Pakiet narzędzi instaluje następujące liczniki wydajności. Liczniki "Suma" mierzą 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 połączone
Połączenia rozłączone
Połączenia bieżące

Metryki komunikatów

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

Odebrane komunikaty o połączeniu łącznie
Łączna liczba wysłanych komunikatów połączeń
Odebrane komunikaty połączenia/s
Wysłane komunikaty połączenia/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 SignalR. Komunikat jest publikowany po wysłaniu lub emisji. Subskrybent w tym kontekście jest subskrypcją w magistrali komunikatów; powinno to być równe liczbie klientów oraz samego 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ść.

Liczba odebranych komunikatów magistrali komunikatów
Odebrane komunikaty magistrali komunikatów na sekundę
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. Każdy strumień zapewnia uporządkowane operacje odczytu i zapisu; pojedynczy strumień jest potencjalnym wąskim gardłem skalowania, więc można zwiększyć liczbę strumieni, aby zmniejszyć to wąskie gardło. Jeśli jest używanych wiele strumieni, usługa SignalR automatycznie dystrybuuje (fragment) komunikaty między tymi strumieniami w sposób, który gwarantuje, że komunikaty wysyłane z dowolnego połączenia są uporządkowane.

Ustawienie MaxQueueLength kontroluje długość kolejki wysyłania w poziomie obsługiwanej przez usługę SignalR. Ustawienie wartości większej niż 0 spowoduje umieszczenie wszystkich komunikatów w kolejce wysyłania pojedynczo do skonfigurowanego planu obsługi komunikatów. Jeśli rozmiar kolejki przekroczy skonfigurowaną długość, kolejne wywołania do wysłania natychmiast zakończy się niepowodzeniem z błędem InvalidOperationException , dopóki liczba komunikatów w kolejce nie będzie mniejsza niż ustawienie. Kolejkowanie jest domyślnie wyłączone, ponieważ zaimplementowane płaszczyzny wsteczne zwykle mają własne kolejkowanie lub sterowanie przepływem. W przypadku SQL Server buforowanie połączeń skutecznie ogranicza liczbę wysyłanych w dowolnym momencie.

Domyślnie tylko jeden strumień jest używany dla SQL Server i Redis, pięć strumieni jest używanych dla usługi Service Bus, a kolejkowanie jest wyłączone, ale te ustawienia można zmienić za pomocą konfiguracji na SQL Server i Service Bus:

Kod programu .NET Server do konfigurowania liczby tabel i długości kolejki dla SQL Server backplane

var connectionString = "(your connection string)";
var config = new SqlScaleoutConfiguration(connectionString) { 
TableCount = 3,
MaxQueueLength = 50 };
GlobalHost.DependencyResolver.UseSqlServer(config);

Kod programu .NET Server do konfigurowania liczby tematów i długości kolejki dla wewnętrznej płaszczyzny usługi Service Bus

string connectionString = "(your connection string)";
var config = new ServiceBusScaleoutConfiguration(connectionString, "YourAppName") { 
TopicCount = 3,
MaxQueueLength = 50 };
GlobalHost.DependencyResolver.UseServiceBus(config);

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ęć

.NET CLR Memory\# bytes 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ść

Blokady i wątki środowiska .NET CLR\# bieżących wątków logicznych
Blokady i wątki środowiska .NET CLR\# 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:

Udostępnij za pośrednictwem