Wydajność usługi SignalR
Autor : Patrick Fletcher
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 wConfiguration
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łaprocessModel
w programieconfig/machine.config
(zamiastaspnet.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: