Przewodnik dotyczący wydajności usługi Azure Web PubSub Service
Jedną z najważniejszych zalet korzystania z usługi Azure Web PubSub jest łatwość skalowania. W scenariuszu na dużą skalę wydajność jest ważnym czynnikiem.
W tym przewodniku przedstawiono czynniki wpływające na wydajność usługi Web PubSub. Opisujemy typową wydajność w różnych scenariuszach przypadków użycia.
Szybka ocena przy użyciu metryk
Zanim przejdziemy przez czynniki wpływające na wydajność, najpierw przedstawimy łatwy sposób monitorowania ciśnienia usługi. W portalu istnieje metryka o nazwie Obciążenie serwera.
Przedstawia ona presję obliczeniową usługi Azure Web PubSub. Możesz przetestować własny scenariusz i sprawdzić tę metryę, aby zdecydować, czy chcesz przeprowadzić skalowanie w górę. Opóźnienie w usłudze Azure Web PubSub pozostanie 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), musisz sprawdzić wysyłanie do małej grupy w celu uzyskania informacji. W tych scenariuszach istnieje duży koszt routingu, który nie jest uwzględniony w obciążeniu serwera.
Poniżej przedstawiono szczegółowe pojęcia dotyczące oceny wydajności.
Definicje terminów
Ruch przychodzący: komunikat przychodzący do usługi Azure Web PubSub Service.
Wychodzący: komunikat wychodzący z usługi Azure Web PubSub Service.
Przepustowość: całkowity rozmiar wszystkich komunikatów na 1 sekundę.
Omówienie
Ten przewodnik odpowiada na następujące pytania:
Jaka jest typowa wydajność usługi Azure Web PubSub Service dla każdego rozmiaru jednostki?
Czy usługa Azure Web PubSub 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 rozmiar jednostki?
Aby odpowiedzieć na te pytania, ten przewodnik zawiera ogólne wyjaśnienie czynników wpływających na wydajność. Następnie ilustruje maksymalną liczbę komunikatów przychodzących i wychodzących dla typowych przypadków użycia: Wysyłanie do grup za pośrednictwem podprotocol web PubSub, nadrzędnego i interfejsu API REST.
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.). Zawiera jednak pewne podstawowe informacje, aby zrozumieć ograniczenie 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. Maksymalna przepływność (przepustowość ruchu przychodzącego i wychodzącego) jest definiowana jako maksymalna osiągnięta przepływność, gdy 99 procent komunikatów ma opóźnienie mniejsze niż 1 sekundę. To nie jest twardy limit.
Czynniki wydajności
Teoretycznie pojemność usługi Azure Web PubSub Service jest ograniczona przez zasoby obliczeniowe: procesor CPU, pamięć i sieć. Na przykład więcej połączeń z usługą Azure Web PubSub 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 Web PubSub Service musi wydać więcej cykli procesora CPU na przetwarzanie ruchu.
Koszt routingu komunikatów ogranicza również wydajność. Usługa Azure Web PubSub pełni rolę brokera komunikatów, który kieruje komunikat między zestawem klientów. Inny scenariusz lub interfejs API wymaga innych zasad routingu.
W przypadku echa klient wysyła komunikat do nadrzędnego strumienia i przekazuje komunikat z powrotem do klienta. Ten wzorzec ma najniższy koszt routingu. Jednak w przypadku emisji, wysyłania do grupy i wysyłania do połączenia usługa Azure Web PubSub 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.
Podsumowując, następujące czynniki wpływają na pojemność przychodzącą i wychodzącą:
Rozmiar jednostki (procesor/pamięć)
Liczba połączeń
Rozmiar komunikatu
Szybkość wysyłania komunikatów
Scenariusz przypadków użycia (koszt routingu)
Znajdowanie odpowiedniego rozmiaru jednostki
Jak ocenić pojemność ruchu przychodzącego/wychodzącego lub sprawdzić, który rozmiar jednostki jest odpowiedni dla konkretnego przypadku użycia?
Każdy rozmiar jednostki ma własną maksymalną przepustowość ruchu przychodzącego i przepustowość ruchu wychodzącego. Bezproblemowe środowisko użytkownika nie jest gwarantowane po przekroczeniu progu przez ruch przychodzący lub wychodzący.
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: interwał wysyłania komunikatów. Na przykład 1 sekunda 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 oznacza wysyłanie dwóch komunikatów co sekundę.
- Połączenie ions: zatwierdzony maksymalny próg dla usługi Azure Web PubSub Service dla każdego rozmiaru jednostki. Połączenie, które przekraczają próg, są ograniczane.
Załóżmy, że nadrzędny strumień 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żdego rozmiaru jednostki.
Analiza przypadku
W poniższych sekcjach przedstawiono trzy typowe przypadki użycia: wysyłanie do grup za pośrednictwem podprotokolu Web PubSub, wyzwalanie elementu CloudEvent, wywoływanie interfejsu API rest. W przypadku każdego scenariusza sekcja zawiera listę bieżącej pojemności ruchu przychodzącego i wychodzącego dla usługi Azure Web PubSub Service. Wyjaśniono również główne czynniki wpływające na wydajność.
We wszystkich przypadkach użycia domyślny rozmiar komunikatu to 2048 bajtów, a interwał wysyłania komunikatów to 1 sekunda.
Wysyłanie do grup za pośrednictwem podprotoku Web PubSub
Usługa obsługuje określoną podprotokolę o nazwie json.webpubsub.azure.v1, która umożliwia klientom bezpośrednie publikowanie/subskrybowanie zamiast rundy na serwerze nadrzędnym. Ten scenariusz jest wydajny, ponieważ żaden serwer nie jest zaangażowany, a cały ruch przechodzi przez połączenie WebSocket usługi klienta.
Liczba członków grupy i grupy to dwa czynniki wpływające na wydajność. Aby uprościć analizę, definiujemy dwa rodzaje 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.
- 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.
Wysyłanie do grupy powoduje przeniesienie kosztów routingu do usługi Azure Web PubSub Service, ponieważ musi znaleźć połączenia docelowe za pośrednictwem rozproszonej struktury danych. Wraz ze wzrostem liczby połączeń wysyłających koszty rosną.
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.
| 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 | 1 000 | 5000 | 10,000 | 5000 | 10,000 | 20,000 |
| Liczba grup | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| Komunikaty przychodzące na sekundę | 30 | 30 | 30 | 30 | 30 | 30 | 30 | 30 |
| Przepustowość ruchu przychodzącego | 60 KBps | 60 KBps | 60 KBps | 60 KBps | 60 KBps | 60 KBps | 60 KBps | 60 KBps |
| Komunikaty wychodzące na sekundę | 3000 | 6000 | 30,000 | 150,000 | 300,000 | 600,000 | 1,500,000 | 3,000,000 |
| Przepustowość wychodząca | 6 MB/s | 12 MB/s | 60 MB/s | 300 MB/s | 600 MB/s | 1200 MB/s | 3000 MB/s | 6000 MB/s |
Mała grupa
Koszt routingu jest znaczący w przypadku wysyłania komunikatów do wielu małych grup. Obecnie implementacja usługi Azure Web PubSub 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, musisz skalować w górę, aby użyć Premium_P2 (jednostka >100).
| 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 |
Uwaga
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.
Wyzwalanie zdarzenia w chmurze
Usługa dostarcza zdarzenia klienta do nadrzędnego elementu webhook przy użyciu protokołu HTTP CloudEvents.
Dla każdego zdarzenia formułuje żądanie HTTP POST do zarejestrowanego nadrzędnego strumienia i oczekuje odpowiedzi HTTP.
Uwaga
Usługa Web PubSub obsługuje również protokół HTTP 2.0 na potrzeby dostarczania zdarzeń nadrzędnych. Poniższy wynik jest testowany przy użyciu protokołu HTTP 1.1. Jeśli serwer aplikacji obsługuje protokół HTTP 2.0, wydajność będzie lepsza.
Echo
W takim przypadku serwer aplikacji zapisuje oryginalny komunikat z powrotem w odpowiedzi http. 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ę | 500 | 1 000 | 5000 | 25,000 | 50,000 | 100 000 | 250 000 | 500,000 |
| Przepustowość ruchu przychodzącego/wychodzącego | 1 MB/s | 2 MB/s | 10 MB/s | 50 MB/s | 100 MB/s | 200 MB/s | 500 MB/s | 1000 MB/s |
Interfejs API REST
Usługa Azure Web PubSub udostępnia zaawansowane interfejsy API do zarządzania klientami i dostarczania komunikatów w czasie rzeczywistym.
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 Web PubSub Service.
| 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ę | 180 | 360 | 1800 | 9000 | 18 000 | 36,000 | 90,000 | 180,000 |
| Przepustowość ruchu przychodzącego/wychodzącego | 360 KBps | 720 KBps | 3,6 MB/s | 18 MB/s | 36 MB/s | 72 MB/s | 180 MB/s | 360 MB/s |
Emisja za pośrednictwem interfejsu API REST
Przepustowość jest taka sama jak w przypadku wysyłania do dużej grupy.
| 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ę | 3 | 3 | 3 | 3 | 3 | 3 | 3 | 3 |
| Komunikaty wychodzące na sekundę | 3000 | 6000 | 30,000 | 150,000 | 300,000 | 600,000 | 1,500,000 | 3,000,000 |
| Przepustowość ruchu przychodzącego | 6 KBps | 6 KBps | 6 KBps | 6 KBps | 6 KBps | 6 KBps | 6 KBps | 6 KBps |
| Przepustowość wychodząca | 6 MB/s | 12 MB/s | 60 MB/s | 300 MB/s | 600 MB/s | 1200 MB/s | 3000 MB | 6000 MB |
Następne kroki
Użyj tych zasobów, aby rozpocząć tworzenie własnej aplikacji:
Opinia
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź: https://aka.ms/ContentUserFeedback.
Prześlij i wyświetl opinię dla