Przewodnik dotyczący wydajności usługi Azure SignalR Service
Jedną z kluczowych zalet korzystania z usługi Azure SignalR Service jest łatwość skalowania aplikacji SignalR. W scenariuszu na dużą skalę wydajność jest ważnym czynnikiem.
W tym artykule opisano:
- Czynniki wpływające na wydajność aplikacji SignalR.
- Typowa wydajność w różnych scenariuszach przypadków użycia.
- Środowisko i narzędzia, których można użyć do wygenerowania raportu wydajności.
Szybka ocena przy użyciu metryk
Usługę można łatwo monitorować w witrynie Azure Portal. Na stronie Metryki wystąpienia usługi SignalR możesz wybrać metryki Obciążenia serwera, aby wyświetlić "ciśnienie" usługi.
Wykres przedstawia ciśnienie obliczeniowe usługi SignalR. Możesz przetestować swój scenariusz i sprawdzić tę metryę, aby zdecydować, czy przeprowadzić skalowanie w górę. Opóźnienie w usłudze SignalR pozostaje niskie, jeśli obciążenie serwera jest mniejsze niż 70%.
Uwaga
Jeśli używasz lekcji 50 lub większej , a scenariusz wysyła głównie do małych grup (rozmiar <grupy 20) lub pojedynczego połączenia, musisz sprawdzić wysyłanie do małej grupy lub wysyłanie do połączenia w celu uzyskania informacji. W tych scenariuszach istnieje duży koszt routingu, który nie jest uwzględniony w obciążeniu serwera.
Definicje terminów
Ruch przychodzący: komunikat przychodzący do usługi Azure SignalR Service.
Wychodzący: komunikat wychodzący z usługi Azure SignalR Service.
Przepustowość: całkowity rozmiar wszystkich komunikatów na 1 sekundę.
Tryb domyślny: domyślny tryb roboczy podczas tworzenia wystąpienia usługi Azure SignalR Service. Usługa Azure SignalR Service oczekuje, że serwer aplikacji nawiąż połączenie z nim, zanim zaakceptuje jakiekolwiek połączenie klienta.
Tryb bezserwerowy: tryb, w którym usługa Azure SignalR Service akceptuje tylko połączenia klienckie. Połączenie z serwerem nie jest dozwolone.
Omówienie
Usługa Azure SignalR Service definiuje siedem warstw Standardowa dla różnych pojemności wydajności. Ten przewodnik odpowiada na następujące pytania:
Jaka jest typowa wydajność usługi Azure SignalR Service dla każdej warstwy (jednostki)?
Czy usługa Azure SignalR Service spełnia wymagania dotyczące przepływności komunikatów (na przykład wysyłania 100 000 komunikatów na sekundę)?
W przypadku mojego konkretnego scenariusza, jak mogę wybrać odpowiednią warstwę?
Jakiego rodzaju serwer aplikacji (rozmiar maszyny wirtualnej) jest odpowiedni dla mnie? Ile z nich należy wdrożyć?
Aby odpowiedzieć na te pytania, ten przewodnik zawiera ogólne wyjaśnienie czynników wpływających na wydajność. Następnie ilustruje maksymalną liczbę przychodzących i wychodzących komunikatów dla każdej warstwy dla typowych przypadków użycia: echo, emisja, wysyłanie do grupy i wysyłanie do połączenia (komunikacja równorzędna).
Ten przewodnik nie może obejmować wszystkich scenariuszy (i różnych przypadków użycia, rozmiarów komunikatów, wzorców wysyłania komunikatów itd.). Udostępnia jednak kilka metod ułatwiania wykonywania tych czynności:
- Oceń przybliżone wymaganie dotyczące komunikatów przychodzących lub wychodzących.
- Znajdź odpowiednie warstwy, sprawdzając tabelę wydajności.
Szczegółowe informacje o wydajności
W tej sekcji opisano metodologie oceny wydajności, a następnie wymieniono wszystkie czynniki wpływające na wydajność. W końcu udostępnia metody ułatwiające ocenę wymagań dotyczących wydajności.
Metodologia
Przepływność i opóźnienie to dwa typowe aspekty sprawdzania wydajności. W przypadku usługi Azure SignalR Service każda warstwa jednostki SKU ma własne zasady ograniczania przepływności. Zasady określają maksymalną dozwoloną przepływność (przepustowość ruchu przychodzącego i wychodzącego) jako maksymalną osiągniętą przepływność, gdy 99 procent komunikatów ma opóźnienie mniejsze niż 1 sekundę.
Opóźnienie to przedział czasu od połączenia wysyłającego komunikat do odbierania komunikatu odpowiedzi z usługi Azure SignalR Service. Weźmy echo jako przykład. Każde połączenie klienta dodaje sygnaturę czasową w komunikacie. Centrum serwera aplikacji wysyła oryginalną wiadomość z powrotem do klienta. Dlatego opóźnienie propagacji jest łatwo obliczane przez każde połączenie klienta. Sygnatura czasowa jest dołączona dla każdego komunikatu w emisji, wysyłania do grupy i wysyłania do połączenia.
Aby symulować tysiące współbieżnych połączeń klienckich, wiele maszyn wirtualnych jest tworzonych w wirtualnej sieci prywatnej na platformie Azure. Wszystkie te maszyny wirtualne łączą się z tym samym wystąpieniem usługi Azure SignalR Service.
W domyślnym trybie usługi Azure SignalR Service maszyny wirtualne serwera aplikacji są wdrażane w tej samej wirtualnej sieci prywatnej co maszyny wirtualne klienta. Wszystkie maszyny wirtualne klienta i maszyny wirtualne serwera aplikacji są wdrażane w tej samej sieci tego samego regionu, aby uniknąć opóźnienia między regionami.
Czynniki wydajności
Następujące czynniki wpływają na wydajność usługi SignalR.
- Warstwa jednostki SKU (procesor/pamięć)
- Liczba połączeń
- Rozmiar komunikatu
- Szybkość wysyłania komunikatów
- Typ transportu (WebSocket, Server-Sent-Event lub Long-Polling)
- Scenariusz przypadków użycia (koszt routingu)
- Połączenia serwera aplikacji i usługi (w trybie serwera)
Zasoby komputera
Teoretycznie pojemność usługi Azure SignalR Service jest ograniczona przez zasoby obliczeniowe: procesor CPU, pamięć i sieć. Na przykład więcej połączeń z usługą Azure SignalR Service powoduje użycie większej ilości pamięci przez usługę. W przypadku większego ruchu komunikatów (na przykład każdy komunikat jest większy niż 2048 bajtów), usługa Azure SignalR Service musi wydać więcej cykli procesora CPU na przetwarzanie ruchu. Tymczasem przepustowość sieci platformy Azure nakłada również limit maksymalnego ruchu.
Typ transportu
Typ transportu jest kolejnym czynnikiem wpływającym na wydajność. Trzy typy to:
- WebSocket: WebSocket to dwukierunkowy i pełnodupleksowy protokół komunikacyjny za pośrednictwem jednego połączenia TCP.
- Server-Sent-Event: Server-Sent-Event to jednokierunkowy protokół do wypychania komunikatów z serwera do klienta.
- Długie sondowanie: długie sondowanie wymaga od klientów okresowego sondowania informacji z serwera za pośrednictwem żądania HTTP.
W przypadku tego samego interfejsu API w tych samych warunkach usługa WebSocket ma najlepszą wydajność, serwer-sent-event jest wolniejszy, a długotrwałe sondowanie jest najwolniejsze. Usługa Azure SignalR Service domyślnie zaleca korzystanie z protokołu WebSocket.
Koszt routingu komunikatów
Koszt routingu komunikatów ogranicza również wydajność. Usługa Azure SignalR Service pełni rolę routera komunikatów, który kieruje komunikat z zestawu klientów lub serwerów do innych klientów lub serwerów. Inny scenariusz lub interfejs API wymaga innych zasad routingu.
W przypadku echa klient wysyła do siebie komunikat, a lokalizacja docelowa routingu jest również sama. Ten wzorzec ma najniższy koszt routingu. Jednak w przypadku emisji, wysyłania do grupy i wysyłania do połączenia usługa Azure SignalR Service musi wyszukać połączenia docelowe za pośrednictwem wewnętrznej rozproszonej struktury danych. To dodatkowe przetwarzanie wykorzystuje więcej procesora CPU, pamięci i przepustowości sieci. W związku z tym wydajność jest niższa.
W trybie domyślnym serwer aplikacji może również stać się wąskim gardłem w niektórych scenariuszach. Zestaw SDK usługi Azure SignalR musi wywołać centrum, podczas gdy utrzymuje połączenie na żywo z każdym klientem za pośrednictwem sygnałów pulsu.
W trybie bezserwerowym klient wysyła komunikat pocztą HTTP, który nie jest tak wydajny, jak protokół WebSocket.
Protokół
Innym czynnikiem jest protokół: JSON i MessagePack. Pakiet MessagePack jest mniejszy i dostarczany szybciej niż JSON. Pakiet MessagePack może jednak nie poprawić wydajności. Wydajność usługi Azure SignalR Service nie jest wrażliwa na protokoły, ponieważ nie dekoduje ładunku komunikatu podczas przekazywania komunikatów od klientów do serwerów lub odwrotnie.
Znajdowanie odpowiedniej jednostki SKU
Jak ocenić pojemność ruchu przychodzącego/wychodzącego lub sprawdzić, która warstwa jest odpowiednia dla konkretnego przypadku użycia?
Załóżmy, że serwer aplikacji jest wystarczająco zaawansowany i nie jest wąskim gardłem wydajności. Następnie sprawdź maksymalną przepustowość ruchu przychodzącego i wychodzącego dla każdej warstwy.
Szybka ocena
W przypadku szybkiej oceny przyjmij następujące ustawienia domyślne:
- Typ transportu to WebSocket.
- Rozmiar komunikatu to 2048 bajtów.
- Wiadomość jest wysyłana co 1 sekundę.
- Usługa Azure SignalR Service jest w trybie domyślnym.
Każda warstwa ma własną maksymalną przepustowość ruchu przychodzącego i przepustowość ruchu wychodzącego. Bezproblemowe środowisko użytkownika nie jest gwarantowane po przekroczeniu limitu przez połączenie przychodzące lub wychodzące.
Echo zapewnia maksymalną przepustowość ruchu przychodzącego, ponieważ ma najniższy koszt routingu. Emisja definiuje maksymalną przepustowość komunikatów wychodzących.
Nie należy przekraczać wyróżnionych wartości w następujących dwóch tabelach.
| Echo | Lekcja 1 | Lekcja 2 | Lekcja 10 | Lekcja 50 | Lekcja 100 | Lekcja 200 | Lekcja 500 | Lekcja 1000 |
|---|---|---|---|---|---|---|---|---|
| Połączenia | 1000 | 2000 | 10,000 | 50,000 | 100 000 | 200,000 | 500,000 | 1 000 000 |
| Przepustowość ruchu przychodzącego | 2 MB/s | 4 MB/s | 20 MB/s | 100 MB/s | 200 MB/s | 400 MB/s | 1000 MB/s | 2000 MB/s |
| Przepustowość wychodząca | 2 MB/s | 4 MB/s | 20 MB/s | 100 MB/s | 200 MB/s | 400 MB/s | 1000 MB/s | 2000 MB/s |
| Emisja | Lekcja 1 | Lekcja 2 | Lekcja 10 | Lekcja 50 | Lekcja 100 | Lekcja 200 | Lekcja 500 | Lekcja 1000 |
|---|---|---|---|---|---|---|---|---|
| Połączenia | 1000 | 2000 | 10,000 | 50,000 | 100 000 | 200,000 | 500,000 | 1 000 000 |
| Przepustowość ruchu przychodzącego | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps |
| Przepustowość ruchu wychodzącego | 4 MB/s | 8 MB/s | 40 MB/s | 200 MB/s | 400 MB/s | 800 MB/s | 2000 MB/s | 4000 MB/s |
Przepustowość ruchu przychodzącego i przepustowość ruchu wychodzącego to łączny rozmiar komunikatu na sekundę. Oto formuły dla nich:
inboundBandwidth = inboundConnections * messageSize / sendInterval
outboundBandwidth = outboundConnections * messageSize / sendInterval
przychodzące Połączenie ions: liczba połączeń wysyłających komunikat.
wychodzące Połączenie ions: liczba połączeń odbierających komunikat.
messageSize: rozmiar pojedynczego komunikatu (średnia wartość). Mała wiadomość, która jest mniejsza niż 1024 bajty, ma wpływ na wydajność podobną do komunikatu o wartości 1024 bajtów.
sendInterval: czas wysyłania jednej wiadomości. Zazwyczaj jest to 1 sekunda na komunikat, co oznacza wysłanie jednej wiadomości co sekundę. Mniejszy interwał oznacza wysyłanie większej liczby komunikatów w danym okresie. Na przykład 0,5 sekundy na komunikat oznacza wysyłanie dwóch komunikatów co sekundę.
Połączenie ions: zatwierdzony maksymalny próg dla usługi Azure SignalR Service dla każdej warstwy. Jeśli numer połączenia zostanie jeszcze bardziej zwiększony, występuje problem z ograniczaniem połączeń.
Uwaga
Aby rozmiar jednostki był większy niż 100, należy skalować w górę do jednostki SKU Premium_P2 .
Ocena złożonych przypadków użycia
Większy rozmiar wiadomości lub inna szybkość wysyłania
Rzeczywisty przypadek użycia jest bardziej skomplikowany. Może ona wysłać komunikat większy niż 2048 bajtów lub szybkość wysyłania komunikatów nie jest jedną wiadomością na sekundę. Przyjrzyjmy się emisji lekcji 100 jako przykładu, aby dowiedzieć się, jak ocenić jego wydajność.
W poniższej tabeli przedstawiono rzeczywisty przypadek użycia emisji. Jednak rozmiar komunikatu, liczba połączeń i szybkość wysyłania komunikatów różnią się od tego, co zakładaliśmy w poprzedniej sekcji. Pytanie brzmi, jak możemy wyłudić dowolny z tych elementów (rozmiar komunikatu, liczba połączeń lub szybkość wysyłania komunikatów), jeśli wiemy tylko dwa z nich.
| Emisja | Rozmiar komunikatu | Współbieżne komunikaty przychodzące | Połączenia | Interwały wysyłania |
|---|---|---|---|---|
| 1 | 20 KB | 1 | 100 000 | 5 sek |
| 2 | 256 KB | 1 | 8000 | 5 sek |
Następująca formuła jest łatwa do wywnioskowania na podstawie poprzedniej formuły:
outboundConnections = outboundBandwidth * sendInterval / messageSize
W przypadku jednostki 100 maksymalna przepustowość ruchu wychodzącego wynosi 400 MB z poprzedniej tabeli. W przypadku rozmiaru komunikatu o rozmiarze 20 KB maksymalna liczba połączeń wychodzących powinna wynosić 400 MB * 5/ 20 KB = 100 000, co odpowiada rzeczywistej wartości.
Mieszane przypadki użycia
Rzeczywisty przypadek użycia zwykle łączy cztery podstawowe przypadki użycia: echo, emisję, wysyłanie do grupy i wysyłanie do połączenia. Metodologia, której używasz do oceny pojemności, to:
- Podziel mieszane przypadki użycia na cztery podstawowe przypadki użycia.
- Oblicz maksymalną przepustowość komunikatów przychodzących i wychodzących przy użyciu poprzednich formuł oddzielnie.
- Sumuj obliczenia przepustowości, aby uzyskać łączną maksymalną przepustowość ruchu przychodzącego/wychodzącego.
Następnie należy pobrać odpowiednią warstwę z maksymalnych tabel przepustowości ruchu przychodzącego/wychodzącego.
Uwaga
W przypadku wysyłania komunikatu do setek lub tysięcy małych grup lub dla tysięcy klientów wysyłających wiadomość do siebie nawzajem koszt routingu stanie się dominujący. Weź pod uwagę ten wpływ.
W przypadku użycia wysyłania komunikatu do klientów upewnij się, że serwer aplikacji nie jest wąskim gardłem. Poniższa sekcja "Analiza przypadku" zawiera wskazówki dotyczące liczby potrzebnych serwerów aplikacji i liczby skonfigurowanych połączeń serwera.
Analiza przypadku
W poniższych sekcjach przedstawiono cztery typowe przypadki użycia transportu protokołu WebSocket: echo, emisja, wysyłanie do grupy i wysyłanie do połączenia. W przypadku każdego scenariusza sekcja zawiera listę bieżącej pojemności ruchu przychodzącego i wychodzącego dla usługi Azure SignalR Service. Wyjaśniono również główne czynniki wpływające na wydajność.
W trybie domyślnym serwer aplikacji tworzy pięć połączeń serwera z usługą Azure SignalR Service. Serwer aplikacji domyślnie używa zestawu SDK usługi Azure SignalR Service. W poniższych wynikach testu wydajnościowego połączenia serwera są zwiększane do 15 (lub więcej w przypadku emisji i wysyłania komunikatu do dużej grupy).
Różne przypadki użycia mają różne wymagania dotyczące serwerów aplikacji. Emisja wymaga niewielkiej liczby serwerów aplikacji. Echo lub wysyłanie do połączenia wymaga wielu serwerów aplikacji.
We wszystkich przypadkach użycia domyślny rozmiar komunikatu to 2048 bajtów, a interwał wysyłania komunikatów to 1 sekunda.
Tryb domyślny
Klienci, serwery aplikacji internetowej i usługa Azure SignalR Service są zaangażowani w tryb domyślny. Każdy klient oznacza jedno połączenie.
Echo
Najpierw aplikacja internetowa łączy się z usługą Azure SignalR Service. Po drugie, wielu klientów łączy się z aplikacją internetową, która przekierowuje klientów do usługi Azure SignalR Service przy użyciu tokenu dostępu i punktu końcowego. Następnie klienci ustanawiają połączenia protokołu WebSocket z usługą Azure SignalR Service.
Po nawiązaniu połączeń przez wszystkich klientów zaczynają wysyłać komunikat zawierający sygnaturę czasową do określonego centrum co sekundę. Koncentrator zwraca komunikat z powrotem do oryginalnego klienta. Każdy klient oblicza opóźnienie po odebraniu komunikatu echa z powrotem.
Na poniższym diagramie w pętli znajdują się od 5 do 8 (czerwony wyróżniony ruch). Pętla jest uruchamiana przez domyślny czas trwania (5 minut) i pobiera statystykę wszystkich opóźnień komunikatów.
Zachowanie echo określa, że maksymalna przepustowość ruchu przychodzącego jest równa maksymalnej przepustowości wychodzącej. Aby uzyskać szczegółowe informacje, zobacz poniższą tabelę.
| Echo | Lekcja 1 | Lekcja 2 | Lekcja 10 | Lekcja 50 | Lekcja 100 | Lekcja 200 | Lekcja 500 | Lekcja 1000 |
|---|---|---|---|---|---|---|---|---|
| Połączenia | 1000 | 2000 | 10,000 | 50,000 | 100 000 | 200,000 | 500,000 | 1 000 000 |
| Komunikaty przychodzące/wychodzące na sekundę | 1000 | 2000 | 10,000 | 50,000 | 100 000 | 200,000 | 500,000 | 1 000 000 |
| Przepustowość ruchu przychodzącego/wychodzącego | 2 MB/s | 4 MB/s | 20 MB/s | 100 MB/s | 200 MB/s | 400 MB/s | 1000 MB/s | 2000 MB/s |
W tym przypadku użycia każdy klient wywołuje centrum zdefiniowane na serwerze aplikacji. Centrum po prostu wywołuje metodę zdefiniowaną po stronie oryginalnego klienta. Ten koncentrator jest najbardziej lekkim koncentratorem do obsługi echa.
public void Echo(IDictionary<string, object> data)
{
Clients.Client(Context.ConnectionId).SendAsync("RecordLatency", data);
}
Nawet w przypadku tego prostego centrum obciążenie ruchu na serwerze aplikacji jest widoczne, ponieważ obciążenie komunikatów przychodzących echo wzrasta. To obciążenie ruchu wymaga wielu serwerów aplikacji dla dużych warstw jednostki SKU. W poniższej tabeli wymieniono liczbę serwerów aplikacji dla każdej warstwy.
| Echo | Lekcja 1 | Lekcja 2 | Lekcja 10 | Lekcja 50 | Lekcja 100 | Lekcja 200 | Lekcja 500 | Lekcja 1000 |
|---|---|---|---|---|---|---|---|---|
| Połączenia | 1000 | 2000 | 10,000 | 50,000 | 100 000 | 200,000 | 500,000 | 1 000 000 |
| Liczba serwerów aplikacji | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Uwaga
Numer połączenia klienta, rozmiar komunikatu, szybkość wysyłania komunikatów, warstwa SKU i procesor/pamięć serwera aplikacji wpływają na ogólną wydajność echa.
Emisja
W przypadku emisji, gdy aplikacja internetowa odbiera komunikat, jest emitowana do wszystkich klientów. Tym więcej klientów ma być rozgłaszanych, tym większy ruch komunikatów jest kierowany do wszystkich klientów. Zapoznaj się z poniższym diagramem.
Niewielka liczba klientów emituje. Przepustowość komunikatów przychodzących jest niewielka, ale przepustowość ruchu wychodzącego jest ogromna. Przepustowość komunikatów wychodzących zwiększa się w miarę wzrostu połączenia klienta lub szybkości emisji.
Poniższa tabela zawiera podsumowanie maksymalnej liczby połączeń klientów, liczby komunikatów przychodzących/wychodzących i przepustowości.
| Emisja | Lekcja 1 | Lekcja 2 | Lekcja 10 | Lekcja 50 | Lekcja 100 | Lekcja 200 | Lekcja 500 | Lekcja 1000 |
|---|---|---|---|---|---|---|---|---|
| Połączenia | 1000 | 2000 | 10,000 | 50,000 | 100 000 | 200,000 | 500,000 | 1 000 000 |
| Komunikaty przychodzące na sekundę | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| Komunikaty wychodzące na sekundę | 2000 | 4000 | 20,000 | 100 000 | 200,000 | 400 000 | 1 000 000 | 2,000,000 |
| Przepustowość ruchu przychodzącego | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps |
| Przepustowość wychodząca | 4 MB/s | 8 MB/s | 40 MB/s | 200 MB/s | 400 MB/s | 800 MB/s | 2000 MB/s | 4000 MB/s |
Klienci rozgłaszający, którzy publikują komunikaty, nie są więcej niż cztery. Potrzebują one mniejszej liczby serwerów aplikacji w porównaniu z echo , ponieważ ilość komunikatów przychodzących jest niewielka. Dwa serwery aplikacji są wystarczające zarówno w przypadku zagadnień dotyczących umowy SLA, jak i wydajności. Należy jednak zwiększyć domyślne połączenia serwera, aby uniknąć dysproporcji, zwłaszcza w przypadku jednostek większych niż 50.
| Emisja | Lekcja 1 | Lekcja 2 | Lekcja 10 | Lekcja 50 | Lekcja 100 | Lekcja 200 | Lekcja 500 | Lekcja 1000 |
|---|---|---|---|---|---|---|---|---|
| Połączenia | 1000 | 2000 | 10,000 | 50,000 | 100 000 | 200,000 | 500,000 | 1 000 000 |
| Liczba serwerów aplikacji | 1 | 1 | 1 | 2 | 2 | 4 | 10 | 20 |
Uwaga
Zwiększ domyślne połączenia serwera z zakresu od 5 do 40 na każdym serwerze aplikacji, aby uniknąć możliwych niezrównoważonych połączeń serwera z usługą Azure SignalR Service.
Numer połączenia klienta, rozmiar komunikatu, szybkość wysyłania komunikatów i warstwa jednostki SKU wpływają na ogólną wydajność emisji.
Wyślij do grupy
Przypadek użycia wysyłania do grupy ma podobny wzorzec ruchu do emisji. Różnica polega na tym, że po nawiązaniu przez klientów połączeń Protokołu WebSocket z usługą Azure SignalR Service muszą dołączyć grupy, zanim będą mogli wysłać komunikat do określonej grupy. Na poniższym diagramie przedstawiono przepływ ruchu.
Liczba członków grupy i grupy to dwa czynniki wpływające na wydajność. Aby uprościć analizę, definiujemy dwa rodzaje grup:
Mała grupa: każda grupa ma 10 połączeń. Liczba grup jest równa (maksymalna liczba połączeń) / 10. Na przykład w przypadku lekcji 1, jeśli liczba połączeń wynosi 1000, mamy 1000 / 10 = 100 grup.
Duża grupa: liczba grup jest zawsze 10. Liczba członków grupy jest równa (maksymalna liczba połączeń) / 10. Na przykład w przypadku lekcji 1, jeśli liczba połączeń wynosi 1000, każda grupa ma 1000 / 10 = 100 członków.
Wysyłanie do grupy powoduje przeniesienie kosztów routingu do usługi Azure SignalR Service, ponieważ musi znaleźć połączenia docelowe za pośrednictwem rozproszonej struktury danych. Wraz ze wzrostem liczby połączeń wysyłających koszty rosną.
Mała grupa
Koszt routingu jest znaczący w przypadku wysyłania komunikatów do wielu małych grup. Obecnie implementacja usługi Azure SignalR Service osiąga limit kosztów routingu w jednostce 50. Dodanie większej ilości procesora CPU i pamięci nie pomaga, więc jednostka 100 nie może jeszcze bardziej poprawić zgodnie z projektem. Jeśli potrzebujesz większej przepustowości ruchu przychodzącego, skontaktuj się z pomocą techniczną klienta.
| Wyślij do małej grupy | Lekcja 1 | Lekcja 2 | Lekcja 10 | Lekcja 50 | Lekcja 100 | Lekcja 200 | Lekcja 500 | Lekcja 1000 |
|---|---|---|---|---|---|---|---|---|
| Połączenia | 1000 | 2000 | 10,000 | 50,000 | 100 000 | 200,000 | 500,000 | 1 000 000 |
| Liczba członków grupy | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| Liczba grup | 100 | 200 | 1 000 | 5000 | 10,000 | 20,000 | 50,000 | 100 000 |
| Komunikaty przychodzące na sekundę | 200 | 400 | 2000 | 10,000 | 10,000 | 20,000 | 50,000 | 100 000 |
| Przepustowość ruchu przychodzącego | 400 KBps | 800 KBps | 4 MB/s | 20 MB/s | 20 MB/s | 40 MB/s | 100 MB/s | 200 MB/s |
| Komunikaty wychodzące na sekundę | 2000 | 4000 | 20,000 | 100 000 | 100 000 | 200,000 | 500,000 | 1 000 000 |
| Przepustowość wychodząca | 4 MB/s | 8 MB/s | 40 MB/s | 200 MB/s | 200 MB/s | 400 MB/s | 1000 MB/s | 2000 MB/s |
Wiele połączeń klienckich wywołuje centrum, więc numer serwera aplikacji ma również krytyczne znaczenie dla wydajności. W poniższej tabeli wymieniono sugerowane liczby serwerów aplikacji.
| Wyślij do małej grupy | Lekcja 1 | Lekcja 2 | Lekcja 10 | Lekcja 50 | Lekcja 100 | Lekcja 200 | Lekcja 500 | Lekcja 1000 |
|---|---|---|---|---|---|---|---|---|
| Połączenia | 1000 | 2000 | 10,000 | 50,000 | 100 000 | 200,000 | 500,000 | 1 000 000 |
| Liczba serwerów aplikacji | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Uwaga
Numer połączenia klienta, rozmiar komunikatu, szybkość wysyłania komunikatów, koszt routingu, warstwa SKU i procesor/pamięć serwera aplikacji wpływają na ogólną wydajność wysyłania do małej grupy.
Liczba członków grupy, liczba członków grupy wymienionych w tabeli nie są limitami twardymi. Te wartości parametrów są wybierane w celu ustanowienia stabilnego scenariusza porównawczego. Na przykład jest ok, aby przypisać każdy conneciton do odrębnej grupy. W ramach tej konfiguracji wydajność jest bliska wysyłania do połączenia.
Duża grupa
W przypadku wysyłania do dużej grupy przepustowość wychodząca staje się wąskim gardłem przed przekroczeniem limitu kosztów routingu. W poniższej tabeli wymieniono maksymalną przepustowość ruchu wychodzącego, która jest prawie taka sama jak w przypadku emisji.
| Wyślij do dużej grupy | Lekcja 1 | Lekcja 2 | Lekcja 10 | Lekcja 50 | Lekcja 100 | Lekcja 200 | Lekcja 500 | Lekcja 1000 |
|---|---|---|---|---|---|---|---|---|
| Połączenia | 1000 | 2000 | 10,000 | 50,000 | 100 000 | 200,000 | 500,000 | 1 000 000 |
| Liczba członków grupy | 100 | 200 | 500 | 1000 | 2000 | 5000 | 10,000 | 20,000 |
| Liczba grup | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| Komunikaty przychodzące na sekundę | 20 | 20 | 20 | 20 | 20 | 20 | 20 | 20 |
| Przepustowość ruchu przychodzącego | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps |
| Komunikaty wychodzące na sekundę | 2000 | 4000 | 20,000 | 100 000 | 200,000 | 400 000 | 1 000 000 | 2,000,000 |
| Przepustowość wychodząca | 4 MB/s | 8 MB/s | 40 MB/s | 200 MB/s | 400 MB/s | 800 MB/s | 2000 MB/s | 4000 MB/s |
Liczba połączeń wysyłających nie przekracza 40. Obciążenie serwera aplikacji jest małe, więc sugerowana liczba aplikacji internetowych jest niewielka.
| Wyślij do dużej grupy | Lekcja 1 | Lekcja 2 | Lekcja 10 | Lekcja 50 | Lekcja 100 | Lekcja 200 | Lekcja 500 | Lekcja 1000 |
|---|---|---|---|---|---|---|---|---|
| Połączenia | 1000 | 2000 | 10,000 | 50,000 | 100 000 | 200,000 | 500,000 | 1 000 000 |
| Liczba serwerów aplikacji | 1 | 1 | 2 | 2 | 2 | 4 | 10 | 20 |
Uwaga
Zwiększ domyślne połączenia serwera z zakresu od 5 do 40 na każdym serwerze aplikacji, aby uniknąć możliwych niezrównoważonych połączeń serwera z usługą Azure SignalR Service.
Numer połączenia klienta, rozmiar komunikatu, szybkość wysyłania komunikatów, koszt routingu i warstwa jednostki SKU wpływają na ogólną wydajność wysyłania do dużej grupy.
Wyślij do połączenia
W przypadku użycia wysyłania do połączenia , gdy klienci nawiązują połączenia z usługą Azure SignalR Service, każdy klient wywołuje specjalne centrum w celu uzyskania własnego identyfikatora połączenia. Test porównawczy wydajności zbiera wszystkie identyfikatory połączeń, tasuje je i ponownie przypisuje je do wszystkich klientów jako element docelowy wysyłania. Klienci nadal wysyłają komunikat do połączenia docelowego do momentu zakończenia testu wydajnościowego.
Koszt routingu wysyłania do połączenia jest podobny do kosztu wysyłania do małej grupy.
Wraz ze wzrostem liczby połączeń koszt routingu staje się krytycznym czynnikiem ograniczającym ogólną wydajność. W szczególności jednostka 20 oznacza próg, w którym usługa osiąga wąskie gardło routingu. Dalsze wzrosty liczby jednostek nie dają poprawy wydajności, chyba że nastąpiła zmiana na Premium_P2 (jednostka >=100), co zwiększa możliwości routingu.
Poniższa tabela jest podsumowaniem statystycznym po wielu rundach uruchamiania testu porównawczego wysyłania do połączenia .
| Wyślij do połączenia | Lekcja 1 | Lekcja 2 | Lekcja 20 | Lekcja 50 | Lekcja 100 | Lekcja 200 | Lekcja 500 | Lekcja 1000 |
|---|---|---|---|---|---|---|---|---|
| Połączenia | 1000 | 2000 | 20,000 | 50,000 | 100 000 | 200,000 | 500,000 | 1 000 000 |
| Komunikaty przychodzące/wychodzące na sekundę | 1000 | 2000 | 20,000 | 20,000 | 20,000 | 40,000 | 100 000 | 200,000 |
| Przepustowość ruchu przychodzącego/wychodzącego | 2 MB/s | 4 MB/s | 40 MB/s | 40 MB/s | 40 MB/s | 80 MB/s | 200 MB/s | 400 MB/s |
Uwaga
Pomimo stagnacji w komunikatach przychodzących/wychodzących na sekundę po lekcji 20 pojemność dla większej liczby połączeń nadal rośnie. W rzeczywistych scenariuszach biznesowych często jest to liczba połączeń, a nie ich równoczesne działanie wysyłania komunikatów, które stanowi wąskie gardło. Często zdarza się, że wszystkie połączenia aktywnie wysyłają komunikaty o tak wysokich częstotliwościach, jak test porównawczy.
Ten przypadek użycia wymaga dużego obciążenia po stronie serwera aplikacji. Zobacz sugerowaną liczbę serwerów aplikacji w poniższej tabeli.
| Wyślij do połączenia | Lekcja 1 | Lekcja 2 | Lekcja 10 | Lekcja 50 | Lekcja 100 | Lekcja 200 | Lekcja 500 | Lekcja 1000 |
|---|---|---|---|---|---|---|---|---|
| Połączenia | 1000 | 2000 | 10,000 | 50,000 | 100 000 | 200,000 | 500,000 | 1 000 000 |
| Liczba serwerów aplikacji | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Uwaga
Numer połączenia klienta, rozmiar komunikatu, szybkość wysyłania komunikatów, koszt routingu, warstwa SKU i procesor/pamięć serwera aplikacji wpływają na ogólną wydajność wysyłania do połączenia.
ASP.NET SignalR
Usługa Azure SignalR Service zapewnia tę samą wydajność dla usługi ASP.NET SignalR.
Tryb bezserwerowy
Klienci i usługa Azure SignalR Service są zaangażowani w tryb bezserwerowy. Każdy klient oznacza jedno połączenie. Klient wysyła komunikaty za pośrednictwem interfejsu API REST do innego klienta lub rozgłaszania komunikatów do wszystkich.
Wysyłanie komunikatów o wysokiej gęstości za pośrednictwem interfejsu API REST nie jest tak wydajne, jak używanie protokołu WebSocket. Wymaga to utworzenia nowego połączenia HTTP za każdym razem i jest to dodatkowy koszt w trybie bezserwerowym.
Emisja za pośrednictwem interfejsu API REST
Wszyscy klienci ustanawiają połączenia protokołu WebSocket z usługą Azure SignalR Service. Następnie niektórzy klienci zaczynają emitować za pośrednictwem interfejsu API REST. Wysyłanie komunikatów (przychodzących) odbywa się za pośrednictwem protokołu HTTP Post, co nie jest wydajne w porównaniu z protokołem WebSocket.
| Emisja za pośrednictwem interfejsu API REST | Lekcja 1 | Lekcja 2 | Lekcja 10 | Lekcja 50 | Lekcja 100 | Lekcja 200 | Lekcja 500 | Lekcja 1000 |
|---|---|---|---|---|---|---|---|---|
| Połączenia | 1000 | 2000 | 10,000 | 50,000 | 100 000 | 200,000 | 500,000 | 1 000 000 |
| Komunikaty przychodzące na sekundę | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| Komunikaty wychodzące na sekundę | 2000 | 4000 | 20,000 | 100 000 | 200,000 | 400 000 | 1 000 000 | 2,000,000 |
| Przepustowość ruchu przychodzącego | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps |
| Przepustowość ruchu wychodzącego | 4 MB/s | 8 MB/s | 40 MB/s | 200 MB/s | 400 MB/s | 800 MB/s | 2000 MB/s | 4000 MB/s |
Wysyłanie do użytkownika za pośrednictwem interfejsu API REST
Test porównawczy przypisuje nazwy użytkowników do wszystkich klientów przed rozpoczęciem nawiązywania połączenia z usługą Azure SignalR Service. Po nawiązaniu przez klientów połączeń protokołu WebSocket z usługą Azure SignalR Service zaczynają wysyłać komunikaty do innych osób za pośrednictwem protokołu HTTP Post.
| Wysyłanie do użytkownika za pośrednictwem interfejsu API REST | Lekcja 1 | Lekcja 2 | Lekcja 10 | Lekcja 50 | Lekcja 100 | Lekcja 200 | Lekcja 500 | Lekcja 1000 |
|---|---|---|---|---|---|---|---|---|
| Połączenia | 1000 | 2000 | 10,000 | 50,000 | 100 000 | 200,000 | 500,000 | 1 000 000 |
| Komunikaty przychodzące/wychodzące na sekundę | 200 | 400 | 2000 | 10,000 | 20,000 | 40,000 | 100 000 | 200,000 |
| Przepustowość ruchu przychodzącego/wychodzącego | 400 KBps | 800 KBps | 4 MB/s | 20 MB/s | 40 MB/s | 80 MB/s | 200 MB/s | 400 MB/s |
Środowiska testów wydajnościowych
We wszystkich przypadkach użycia wymienionych powyżej przeprowadziliśmy testy wydajnościowe w środowisku platformy Azure. W większości używaliśmy 200 maszyn wirtualnych klienta i 100 maszyn wirtualnych serwera aplikacji. Oto kilka szczegółów:
Rozmiar maszyny wirtualnej klienta: StandardDS2V2 (2 procesory wirtualne, pamięć 7G)
Rozmiar maszyny wirtualnej serwera aplikacji: StandardowaF4sV2 (4 procesory wirtualne, pamięć 8G)
Połączenia serwera zestawu SDK usługi Azure SignalR: 15
Narzędzia wydajności
Narzędzia do wydajności dla usługi Azure SignalR Service można znaleźć w witrynie GitHub.
Następne kroki
W tym artykule przedstawiono omówienie wydajności usługi Azure SignalR Service w typowych scenariuszach przypadków użycia.
Aby uzyskać szczegółowe informacje na temat wewnętrznych usług i skalowania dla niej, przeczytaj następujące przewodniki: