Průvodce výkonem pro službu Azure SignalR Service
Jednou z klíčových výhod používání služby Azure SignalR Service je snadné škálování aplikací SignalR. Ve velkém scénáři je výkon důležitým faktorem.
Tento článek popisuje:
- Faktory, které ovlivňují výkon aplikace SignalR.
- Typický výkonvch
- Prostředí a nástroje, které můžete použít k vygenerování sestavy výkonu.
Rychlé vyhodnocení s využitím metrik
Službu můžete snadno monitorovat na webu Azure Portal. Na stránce Metriky vaší instance SignalR můžete vybrat metriky načtení serveru a zobrazit "tlak" vaší služby.
Graf znázorňuje výpočetní tlak vaší služby SignalR. Svůj scénář můžete otestovat a zkontrolovat tuto metriku a rozhodnout se, jestli se má vertikálně navýšit kapacitu. Latence služby SignalR zůstává nízká, pokud je zatížení serveru nižší než 70 %.
Poznámka:
Pokud používáte jednotku 50 nebo větší a váš scénář odesílá hlavně do malých skupin (velikost <skupiny 20) nebo do jednoho připojení, je potřeba zkontrolovat odesílání do malé skupiny nebo odesílání do připojení , abyste měli odkaz. V těchto scénářích jsou velké náklady na směrování, které nejsou zahrnuty do zatížení serveru.
Definice termínů
Příchozí: Příchozí zpráva do služby Azure SignalR.
Odchozí: Odchozí zpráva ze služby Azure SignalR.
Šířka pásma: Celková velikost všech zpráv za 1 sekundu.
Výchozí režim: Výchozí pracovní režim při vytvoření instance služby Azure SignalR. Služba Azure SignalR očekává, že aplikační server naváže spojení s ním, než přijme jakékoli připojení klienta.
Bezserverový režim: Režim, ve kterém služba Azure SignalR přijímá pouze připojení klientů. Není povoleno žádné připojení k serveru.
Přehled
Služba Azure SignalR definuje sedm úrovní Standard pro různé kapacity výkonu. Tato příručka odpovídá na následující otázky:
Jaký je typický výkon služby Azure SignalR pro každou úroveň (jednotku)?
Splňuje služba Azure SignalR požadavky na propustnost zpráv (například odesílání 100 000 zpráv za sekundu)?
Jak můžu pro svůj konkrétní scénář vybrat správnou úroveň?
Jaký druh aplikačního serveru (velikosti virtuálního počítače) je pro mě vhodný? Kolik z nich mám nasadit?
Abyste mohli na tyto otázky odpovědět, tento průvodce nejprve poskytuje základní vysvětlení faktorů, které ovlivňují výkon. Pak znázorňuje maximální příchozí a odchozí zprávy pro každou úroveň pro typické případy použití: echo, všesměrové vysílání, odesílání do skupiny a odesílání do připojení (chatování mezi dvěma účastníky).
Tato příručka nemůže pokrýt všechny scénáře (a různé případy použití, velikosti zpráv, vzory odesílání zpráv atd.). Nabízí ale několik metod, které vám pomůžou:
- Vyhodnoťte přibližný požadavek na příchozí nebo odchozí zprávy.
- Vyhledejte správné úrovně kontrolou tabulky výkonu.
Přehled výkonu
Tato část popisuje metodologie hodnocení výkonu a pak uvádí všechny faktory, které ovlivňují výkon. Nakonec poskytuje metody, které vám pomůžou vyhodnotit požadavky na výkon.
Metodologie
Propustnost a latence jsou dva typické aspekty kontroly výkonu. Pro službu Azure SignalR má každá úroveň skladové položky vlastní zásady omezování propustnosti. Zásada definuje maximální povolenou propustnost (příchozí a odchozí šířku pásma) jako maximální dosaženou propustnost, když 99 procent zpráv má latenci menší než 1 sekundu.
Latence je časové rozpětí od připojení odesílajícího zprávu do přijetí zprávy ze služby Azure SignalR. Jako příklad vezměte ozvěnu . Každé připojení klienta přidá do zprávy časové razítko. Centrum aplikačního serveru odešle původní zprávu zpět klientovi. Proto se zpoždění šíření snadno počítá každým připojením klienta. Časové razítko je připojeno ke každé zprávě ve vysílání, odesílání do skupiny a odesílání do připojení.
Pro simulaci tisíců souběžných klientských připojení se v Azure vytvoří několik virtuálních počítačů ve virtuální privátní síti. Všechny tyto virtuální počítače se připojují ke stejné instanci služby Azure SignalR.
Ve výchozím režimu služby Azure SignalR se virtuální počítače aplikačního serveru nasazují ve stejné virtuální privátní síti jako klientské virtuální počítače. Všechny klientské virtuální počítače a virtuální počítače aplikačního serveru se nasazují ve stejné síti stejné oblasti, aby se zabránilo latenci mezi oblastmi.
Faktory výkonu
Výkon služby SignalR ovlivňují následující faktory.
- Úroveň skladové položky (procesor/paměť)
- Počet připojení
- Velikost zprávy
- Rychlost odesílání zpráv
- Typ přenosu (WebSocket, Server-Sent-Event nebo Long-Polling)
- Scénář použití (náklady na směrování)
- Připojení aplikačního serveru a služby (v režimu serveru)
Prostředky počítače
Teoreticky je kapacita služby Azure SignalR omezená výpočetními prostředky: procesor, paměť a síť. Například více připojení ke službě Azure SignalR způsobí, že služba bude používat více paměti. Pro větší provoz zpráv (například každá zpráva je větší než 2 048 bajtů), služba Azure SignalR potřebuje ke zpracování provozu strávit více cyklů procesoru. Šířka pásma sítě Azure mezitím také omezuje maximální provoz.
Typ přenosu
Typ přenosu je dalším faktorem, který ovlivňuje výkon. Jedná se o tři typy:
- WebSocket: WebSocket je obousměrný a plně duplexní komunikační protokol přes jedno připojení TCP.
- Server-Sent-Event: Server-Sent-Event je jednosměrný protokol pro nabízení zpráv ze serveru do klienta.
- Dlouhé dotazování: Dlouhodobé dotazování vyžaduje, aby klienti pravidelně dotazovat informace ze serveru prostřednictvím požadavku HTTP.
Pro stejné rozhraní API za stejných podmínek má WebSocket nejlepší výkon, server-sent-event-event je pomalejší a long-polling je nejpomalejší. Služba Azure SignalR ve výchozím nastavení doporučuje WebSocket.
Náklady na směrování zpráv
Náklady na směrování zpráv také omezují výkon. Služba Azure SignalR hraje roli jako směrovač zpráv, který směruje zprávu ze sady klientů nebo serverů na jiné klienty nebo servery. Jiný scénář nebo rozhraní API vyžaduje jinou zásadu směrování.
Pro ozvěnu klient odešle zprávu sám sobě a cíl směrování je také sám. Tento model má nejnižší náklady na směrování. V případě vysílání, odesílání do skupiny a odesílání do připojení ale služba Azure SignalR potřebuje vyhledat cílová připojení prostřednictvím interní distribuované datové struktury. Toto dodatečné zpracování využívá více procesoru, paměti a šířky pásma sítě. V důsledku toho je výkon pomalejší.
Ve výchozím režimu se aplikační server může stát kritickým bodem i pro určité scénáře. Sada Azure SignalR SDK musí vyvolat centrum, zatímco udržuje živé připojení ke každému klientovi prostřednictvím signálů prezenčních signálů.
V bezserverovém režimu klient odešle zprávu podle příspěvku HTTP, který není tak efektivní jako WebSocket.
Protokol
Dalším faktorem je protokol: JSON a MessagePack. MessagePack je menší a doručuje se rychleji než JSON. MessagePack ale nemusí zvýšit výkon. Výkon služby Azure SignalR service není citlivý na protokoly, protože nekóduje datovou část zprávy během předávání zpráv z klientů na servery nebo naopak.
Vyhledání správné skladové položky
Jak můžete vyhodnotit příchozí nebo odchozí kapacitu nebo zjistit, která úroveň je vhodná pro konkrétní případ použití?
Předpokládejme, že aplikační server je dostatečně výkonný a není kritickým bodem výkonu. Pak zkontrolujte maximální příchozí a odchozí šířku pásma pro každou úroveň.
Rychlé vyhodnocení
Pro rychlé vyhodnocení předpokládejme následující výchozí nastavení:
- Typ přenosu je WebSocket.
- Velikost zprávy je 2 048 bajtů.
- Každých 1 sekundu se odešle zpráva.
- Služba Azure SignalR je ve výchozím režimu.
Každá úroveň má svou vlastní maximální šířku pásma pro příchozí spojení a odchozí šířku pásma. Bezproblémové uživatelské prostředí není zaručeno po překročení limitu příchozího nebo odchozího připojení.
Echo poskytuje maximální příchozí šířku pásma, protože má nejnižší náklady na směrování. Broadcast definuje maximální šířku pásma odchozích zpráv.
Nepřekračujte zvýrazněné hodnoty v následujících dvou tabulkách.
| Echo | Lekce 1 | Lekce 2 | Jednotka 10 | Jednotka 50 | Jednotka 100 | Lekce 200 | Jednotka 500 | Jednotka 1000 |
|---|---|---|---|---|---|---|---|---|
| Propojení | 1000 | 2 000 | 10,000 | 50 000 | 100 000 | 200 000 | 500,000 | 1 000 000 |
| Příchozí šířka pásma | 2 MB/s | 4 MB/s | 20 MB/s | 100 MB/s | 200 MB/s | 400 MB/s | 1 000 MB/s | 2 000 MB/s |
| Odchozí šířka pásma | 2 Mb/s | 4 Mb/s | 20 MB/s | 100 MB/s | 200 MB/s | 400 MB/s | 1 000 MB/s | 2 000 MB/s |
| Vysílání | Lekce 1 | Lekce 2 | Jednotka 10 | Jednotka 50 | Jednotka 100 | Lekce 200 | Jednotka 500 | Jednotka 1000 |
|---|---|---|---|---|---|---|---|---|
| Propojení | 1000 | 2 000 | 10,000 | 50 000 | 100 000 | 200 000 | 500,000 | 1 000 000 |
| Příchozí šířka pásma | 4 KB/s | 4 KB/s | 4 KB/s | 4 KB/s | 4 KB/s | 4 KB/s | 4 KB/s | 4 KB/s |
| Odchozí šířka pásma | 4 MB/s | 8 MB/s | 40 MB/s | 200 MB/s | 400 MB/s | 800 MB/s | 2 000 MB/s | 4 000 MB/s |
Příchozí šířka pásma a odchozí šířka pásma jsou celková velikost zprávy za sekundu. Tady jsou vzorce pro ně:
inboundBandwidth = inboundConnections * messageSize / sendInterval
outboundBandwidth = outboundConnections * messageSize / sendInterval
příchozí Připojení iony: počet připojení odesílaných zpráv.
odchozí Připojení iony: Počet připojení, která obdrží zprávu.
messageSize: Velikost jedné zprávy (průměrná hodnota). Malá zpráva, která je menší než 1 024 bajtů, má dopad na výkon podobný 1 024 bajtům.
sendInterval: Čas odeslání jedné zprávy. Obvykle je to 1 sekunda za zprávu, což znamená, že se posílá jedna zpráva každou sekundu. Menší interval znamená odesílání více zpráv v časovém období. Například 0,5 sekundy za zprávu znamená odesílání dvou zpráv každou sekundu.
Připojení iony: Potvrzená maximální prahová hodnota pro službu Azure SignalR pro každou úroveň. Pokud se číslo připojení ještě zvýší, dochází k omezování připojení.
Poznámka:
Pokud chcete mít velikost jednotky větší než 100, musíte vertikálně navýšit kapacitu na skladovou položku Premium_P2 .
Vyhodnocení složitých případů použití
Větší velikost zprávy nebo jiná rychlost odesílání
Skutečný případ použití je složitější. Může odeslat zprávu větší než 2 048 bajtů nebo míra odesílání zpráv není jedna zpráva za sekundu. Podívejme se na příklad vysílání lekce 100, abychom zjistili, jak vyhodnotit jeho výkon.
Následující tabulka ukazuje skutečný případ použití vysílání. Velikost zprávy, počet připojení a rychlost odesílání zpráv se ale liší od toho, co jsme předpokládali v předchozí části. Otázkou je způsob, jak můžeme odvodit některou z těchto položek (velikost zprávy, počet připojení nebo rychlost odesílání zpráv), pokud víme jen dvě z nich.
| Vysílání | Velikost zprávy | Souběžné příchozí zprávy | Propojení | Intervaly odesílání |
|---|---|---|---|---|
| 0 | 20 kB | 0 | 100 000 | 5 s |
| 2 | 256 kB | 0 | 8 000 | 5 s |
Následující vzorec lze snadno odvodit na základě předchozího vzorce:
outboundConnections = outboundBandwidth * sendInterval / messageSize
Pro jednotku 100 je maximální odchozí šířka pásma 400 MB z předchozí tabulky. Pro velikost zprávy o velikosti 20 kB by maximální odchozí připojení měla být 400 MB × 5 / 20 kB = 100 000, což odpovídá skutečné hodnotě.
Smíšené případy použití
Skutečný případ použití obvykle kombinuje čtyři základní případy použití dohromady: echo, broadcast, send to group a send to connection. Metodika, kterou použijete k vyhodnocení kapacity, je:
- Rozdělte smíšené případy použití do čtyř základních případů použití.
- Spočítejte maximální šířku pásma příchozích a odchozích zpráv pomocí předchozích vzorců samostatně.
- Součet výpočtů šířky pásma pro získání celkové maximální příchozí a odchozí šířky pásma
Pak vyberte správnou úroveň z tabulek maximální šířky pásma pro příchozí a odchozí provoz.
Poznámka:
Pro odeslání zprávy do stovek nebo tisíců malých skupin nebo pro tisíce klientů, kteří vzájemně odesílají zprávu, se náklady na směrování stanou dominantní. Vezměte v úvahu tento dopad.
V případě použití odesílání zprávy klientům se ujistěte, že aplikační server není kritickým bodem. Následující část Případová studie obsahuje pokyny k tomu, kolik aplikačních serverů potřebujete a kolik připojení k serveru byste měli nakonfigurovat.
Případová studie
Následující části procházejí čtyřmi typickými případy použití pro přenos protokolu WebSocket: echo, broadcast, send to group a send to connection. Pro každý scénář uvádí oddíl aktuální příchozí a odchozí kapacitu pro službu Azure SignalR. Vysvětluje také hlavní faktory, které ovlivňují výkon.
Ve výchozím režimu vytvoří aplikační server pět připojení k Azure SignalR Service. Aplikační server ve výchozím nastavení používá sadu SDK služby Azure SignalR. V následujících výsledcích testu výkonnosti se připojení k serveru zvýší na 15 (nebo více pro vysílání a odesílání zpráv velké skupině).
Různé případy použití mají různé požadavky na aplikační servery. Vysílání vyžaduje malý počet aplikačních serverů. Odezva nebo odeslání připojení vyžaduje mnoho aplikačních serverů.
Ve všech případech použití je výchozí velikost zprávy 2 048 bajtů a interval odeslání zprávy je 1 sekunda.
Výchozí režim
Klienti, servery webových aplikací a služba Azure SignalR jsou zapojeni do výchozího režimu. Každý klient představuje jedno připojení.
Echo
Nejprve se webová aplikace připojí ke službě Azure SignalR. Za druhé, mnoho klientů se připojí k webové aplikaci, která přesměruje klienty do služby Azure SignalR s přístupovým tokenem a koncovým bodem. Pak klienti navazují připojení WebSocket se službou Azure SignalR.
Jakmile všichni klienti navazují připojení, začnou posílat zprávu, která obsahuje časové razítko do konkrétního centra každou sekundu. Centrum vrátí zprávu zpět původnímu klientovi. Každý klient vypočítá latenci, když obdrží zprávu echo zpět.
V následujícím diagramu jsou ve smyčce 5 až 8 (červený zvýrazněný provoz). Smyčka se spustí po výchozí dobu (5 minut) a získá statistiku všech latencí zpráv.
Chování ozvěny určuje, že maximální příchozí šířka pásma se rovná maximální odchozí šířce pásma. Podrobnosti najdete v následující tabulce.
| Echo | Lekce 1 | Lekce 2 | Jednotka 10 | Jednotka 50 | Jednotka 100 | Lekce 200 | Jednotka 500 | Jednotka 1000 |
|---|---|---|---|---|---|---|---|---|
| Propojení | 1000 | 2 000 | 10,000 | 50 000 | 100 000 | 200 000 | 500,000 | 1 000 000 |
| Příchozí a odchozí zprávy za sekundu | 1000 | 2 000 | 10,000 | 50 000 | 100 000 | 200 000 | 500,000 | 1 000 000 |
| Příchozí/odchozí šířka pásma | 2 Mb/s | 4 Mb/s | 20 MB/s | 100 MB/s | 200 MB/s | 400 MB/s | 1 000 MB/s | 2 000 MB/s |
V tomto případě použití každý klient vyvolá centrum definované na aplikačním serveru. Centrum právě volá metodu definovanou na původní straně klienta. Toto centrum je nejlehčí rozbočovač pro ozvěnu.
public void Echo(IDictionary<string, object> data)
{
Clients.Client(Context.ConnectionId).SendAsync("RecordLatency", data);
}
I pro toto jednoduché centrum je zatížení provozu na aplikačním serveru výrazné, protože se zvyšuje zatížení příchozích zpráv ozvěny . Tento provoz vyžaduje mnoho aplikačních serverů pro velké úrovně skladových položek. Následující tabulka uvádí počet aplikačních serverů pro každou úroveň.
| Echo | Lekce 1 | Lekce 2 | Jednotka 10 | Jednotka 50 | Jednotka 100 | Lekce 200 | Jednotka 500 | Jednotka 1000 |
|---|---|---|---|---|---|---|---|---|
| Propojení | 1000 | 2 000 | 10,000 | 50 000 | 100 000 | 200 000 | 500,000 | 1 000 000 |
| Počet aplikačních serverů | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Poznámka:
Číslo připojení klienta, velikost zprávy, rychlost odesílání zpráv, úroveň skladové položky a procesor/paměť aplikačního serveru ovlivňují celkový výkon odezvy.
Vysílání
Když webová aplikace přijme zprávu, vysílají se pro všechny klienty. Čím více klientů je potřeba vysílat, tím více přenosů zpráv je pro všechny klienty. Podívejte se na následující diagram.
Malý počet klientů vysílá. Šířka pásma příchozí zprávy je malá, ale odchozí šířka pásma je obrovská. Šířka pásma odchozích zpráv se zvyšuje při zvýšení rychlosti připojení klienta nebo vysílání.
Následující tabulka shrnuje maximální počet klientských připojení, počet příchozích a odchozích zpráv a šířku pásma.
| Vysílání | Lekce 1 | Lekce 2 | Jednotka 10 | Jednotka 50 | Jednotka 100 | Lekce 200 | Jednotka 500 | Jednotka 1000 |
|---|---|---|---|---|---|---|---|---|
| Propojení | 1000 | 2 000 | 10,000 | 50 000 | 100 000 | 200 000 | 500,000 | 1 000 000 |
| Příchozí zprávy za sekundu | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| Odchozí zprávy za sekundu | 2 000 | 4 000 | 20,000 | 100 000 | 200 000 | 400 000 | 1 000 000 | 2,000,000 |
| Příchozí šířka pásma | 4 KB/s | 4 KB/s | 4 KB/s | 4 KB/s | 4 KB/s | 4 KB/s | 4 KB/s | 4 KB/s |
| Odchozí šířka pásma | 4 Mb/s | 8 Mb/s | 40 MB/s | 200 MB/s | 400 MB/s | 800 MB/s | 2 000 MB/s | 4 000 MB/s |
Klienti vysílání, kteří posílají zprávy, nejsou více než čtyři. Ve srovnání s ozvěnou potřebují méně aplikačních serverů, protože příchozí zpráva je malá. Dva aplikační servery jsou dostatečné pro aspekty sla i výkonu. Měli byste ale zvýšit výchozí připojení serveru, abyste se vyhnuli nevyváženostem, zejména pro jednotku větší než 50.
| Vysílání | Lekce 1 | Lekce 2 | Jednotka 10 | Jednotka 50 | Jednotka 100 | Lekce 200 | Jednotka 500 | Jednotka 1000 |
|---|---|---|---|---|---|---|---|---|
| Propojení | 1000 | 2 000 | 10,000 | 50 000 | 100 000 | 200 000 | 500,000 | 1 000 000 |
| Počet aplikačních serverů | 1 | 1 | 0 | 2 | 2 | 4 | 10 | 20 |
Poznámka:
Zvyšte výchozí připojení serveru z 5 na 40 na všech aplikačních serverech, abyste se vyhnuli možným nevyrovnaným serverovým připojením ke službě Azure SignalR.
Číslo připojení klienta, velikost zprávy, rychlost odesílání zpráv a úroveň skladové položky ovlivňují celkový výkon vysílání.
Odeslat do skupiny
Případ použití odesílání do skupiny má podobný model přenosu, který se má vysílat. Rozdíl je v tom, že když klienti vytvoří připojení WebSocket se službou Azure SignalR, musí se připojit ke skupinám, aby mohli odeslat zprávu konkrétní skupině. Následující diagram znázorňuje tok provozu.
Počet členů skupiny a skupin jsou dva faktory, které ovlivňují výkon. Pro zjednodušení analýzy definujeme dva druhy skupin:
Malá skupina: Každá skupina má 10 připojení. Číslo skupiny se rovná (maximální počet připojení) / 10. Pokud například pro jednotku 1 existuje 1 000 počtů připojení, máme 1000 / 10 = 100 skupin.
Velká skupina: Číslo skupiny je vždy 10. Počet členů skupiny se rovná (maximální počet připojení) / 10. Pokud například pro jednotku 1 existuje 1 000 počtu připojení, má každá skupina 1000 / 10 = 100 členů.
Služba Send to group přináší náklady na směrování do služby Azure SignalR, protože musí najít cílová připojení prostřednictvím distribuované datové struktury. S nárůstem počtu odesílajících připojení se náklady zvyšují.
Malá skupina
Náklady na směrování jsou významné pro odesílání zpráv mnoha malým skupinám. V současné době implementace služby Azure SignalR dosáhne limitu nákladů směrování na jednotku 50. Přidání dalšího procesoru a paměti nepomůže, takže jednotka 100 nemůže dále vylepšit návrhem. Pokud potřebujete větší šířku pásma pro příchozí spojení, obraťte se na zákaznickou podporu.
| Odeslat malé skupině | Lekce 1 | Lekce 2 | Jednotka 10 | Jednotka 50 | Jednotka 100 | Lekce 200 | Jednotka 500 | Jednotka 1000 |
|---|---|---|---|---|---|---|---|---|
| Propojení | 1000 | 2 000 | 10,000 | 50 000 | 100 000 | 200 000 | 500,000 | 1 000 000 |
| Počet členů skupiny | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| Počet skupin | 100 | 200 | 1 000 | 5 000 | 10,000 | 20,000 | 50 000 | 100 000 |
| Příchozí zprávy za sekundu | 200 | 400 | 2 000 | 10,000 | 10,000 | 20,000 | 50 000 | 100 000 |
| Příchozí šířka pásma | 400 KB/s | 800 KB/s | 4 Mb/s | 20 MB/s | 20 MB/s | 40 MB/s | 100 MB/s | 200 MB/s |
| Odchozí zprávy za sekundu | 2 000 | 4 000 | 20,000 | 100 000 | 100 000 | 200 000 | 500,000 | 1 000 000 |
| Odchozí šířka pásma | 4 Mb/s | 8 Mb/s | 40 MB/s | 200 MB/s | 200 MB/s | 400 MB/s | 1 000 MB/s | 2 000 MB/s |
Mnoho klientských připojení volá centrum, takže číslo aplikačního serveru je také důležité pro výkon. Následující tabulka uvádí počty navrhovaných aplikačních serverů.
| Odeslat malé skupině | Lekce 1 | Lekce 2 | Jednotka 10 | Jednotka 50 | Jednotka 100 | Lekce 200 | Jednotka 500 | Jednotka 1000 |
|---|---|---|---|---|---|---|---|---|
| Propojení | 1000 | 2 000 | 10,000 | 50 000 | 100 000 | 200 000 | 500,000 | 1 000 000 |
| Počet aplikačních serverů | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Poznámka:
Číslo připojení klienta, velikost zprávy, rychlost odesílání zpráv, náklady na směrování, úroveň skladové položky a procesor/paměť aplikačního serveru ovlivňují celkový výkon odesílání do malé skupiny.
Počet skupin, počet členů skupiny uvedený v tabulce, nejsou pevné limity. Tyto hodnoty parametrů jsou vybrány k vytvoření stabilního srovnávacího scénáře. Například je v pořádku přiřadit každou conneciton k jiné skupině. V rámci této konfigurace se výkon blíží odesílání do připojení.
Velká skupina
Pro odesílání do velké skupiny se odchozí šířka pásma stane kritickým bodem před dosažením limitu nákladů směrování. Následující tabulka uvádí maximální odchozí šířku pásma, která je téměř stejná jako pro všesměrové vysílání.
| Poslat velké skupině | Lekce 1 | Lekce 2 | Jednotka 10 | Jednotka 50 | Jednotka 100 | Lekce 200 | Jednotka 500 | Jednotka 1000 |
|---|---|---|---|---|---|---|---|---|
| Propojení | 1000 | 2 000 | 10,000 | 50 000 | 100 000 | 200 000 | 500,000 | 1 000 000 |
| Počet členů skupiny | 100 | 200 | 500 | 1000 | 2 000 | 5 000 | 10,000 | 20,000 |
| Počet skupin | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| Příchozí zprávy za sekundu | 20 | 20 | 20 | 20 | 20 | 20 | 20 | 20 |
| Příchozí šířka pásma | 40 KB/s | 40 KB/s | 40 KB/s | 40 KB/s | 40 KB/s | 40 KB/s | 40 KB/s | 40 KB/s |
| Odchozí zprávy za sekundu | 2 000 | 4 000 | 20,000 | 100 000 | 200 000 | 400 000 | 1 000 000 | 2,000,000 |
| Odchozí šířka pásma | 4 Mb/s | 8 Mb/s | 40 MB/s | 200 MB/s | 400 MB/s | 800 MB/s | 2 000 MB/s | 4 000 MB/s |
Počet odesílajících připojení není větší než 40. Zatížení aplikačního serveru je malé, takže navrhovaný počet webových aplikací je malý.
| Poslat velké skupině | Lekce 1 | Lekce 2 | Jednotka 10 | Jednotka 50 | Jednotka 100 | Lekce 200 | Jednotka 500 | Jednotka 1000 |
|---|---|---|---|---|---|---|---|---|
| Propojení | 1000 | 2 000 | 10,000 | 50 000 | 100 000 | 200 000 | 500,000 | 1 000 000 |
| Počet aplikačních serverů | 1 | 0 | 2 | 2 | 2 | 4 | 10 | 20 |
Poznámka:
Zvyšte výchozí připojení serveru z 5 na 40 na všech aplikačních serverech, abyste se vyhnuli možným nevyrovnaným serverovým připojením ke službě Azure SignalR.
Číslo připojení klienta, velikost zprávy, rychlost odesílání zpráv, náklady na směrování a úroveň skladové položky ovlivňují celkový výkon odesílání do velké skupiny.
Odeslat do připojení
V případě použití připojení k odesílání do připojení klienti navazují připojení ke službě Azure SignalR, každý klient zavolá zvláštní centrum, aby získal vlastní ID připojení. Srovnávací test výkonu shromažďuje všechna ID připojení, prohazuje je a znovu je přiřazuje všem klientům jako cíl odesílání. Klienti dál odesílají zprávu cílovému připojení, dokud se test výkonnosti nedokončí.
Náklady na směrování pro odesílání do připojení se podobají nákladům na odesílání do malé skupiny.
S rostoucím počtem připojení se náklady na směrování stávají kritickým faktorem, který omezuje celkový výkon. Jednotka 20 zejména označuje prahovou hodnotu, kdy služba dosáhne kritického bodu směrování. Další zvýšení počtu jednotek nepřináší vylepšení výkonu, pokud nedojde ke změně Premium_P2(jednotka >=100), což zlepšuje možnosti směrování.
Následující tabulka je statistický souhrn po mnoha zaokrouhlování spuštění srovnávacího testu odesílání na připojení .
| Odeslat do připojení | Lekce 1 | Lekce 2 | Lekce 20 | Jednotka 50 | Jednotka 100 | Lekce 200 | Jednotka 500 | Jednotka 1000 |
|---|---|---|---|---|---|---|---|---|
| Propojení | 1000 | 2 000 | 20,000 | 50 000 | 100 000 | 200 000 | 500,000 | 1 000 000 |
| Příchozí a odchozí zprávy za sekundu | 1000 | 2 000 | 20,000 | 20,000 | 20,000 | 40 000 | 100 000 | 200 000 |
| Příchozí/odchozí šířka pásma | 2 Mb/s | 4 Mb/s | 40 MB/s | 40 MB/s | 40 MB/s | 80 MB/s | 200 MB/s | 400 MB/s |
Poznámka:
I když se po jednotce 20 po jednotce 20 zvýší kapacita pro příchozí a odchozí zprávy za sekundu. V reálných obchodních scénářích se často jedná o počet připojení, nikoli jejich souběžnou aktivitu odesílání zpráv, která tvoří kritický bod. Je neobvyklé, že všechna připojení aktivně odesílají zprávy s takovou vysokou frekvencí jako srovnávací test.
Tento případ použití vyžaduje vysoké zatížení na straně aplikačního serveru. Podívejte se na počet navrhovaných aplikačních serverů v následující tabulce.
| Odeslat do připojení | Lekce 1 | Lekce 2 | Jednotka 10 | Jednotka 50 | Jednotka 100 | Lekce 200 | Jednotka 500 | Jednotka 1000 |
|---|---|---|---|---|---|---|---|---|
| Propojení | 1000 | 2 000 | 10,000 | 50 000 | 100 000 | 200 000 | 500,000 | 1 000 000 |
| Počet aplikačních serverů | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Poznámka:
Číslo připojení klienta, velikost zprávy, rychlost odesílání zpráv, náklady na směrování, úroveň skladové položky a procesor/paměť aplikačního serveru ovlivňují celkový výkon odesílání do připojení.
ASP.NET SignalR
Služba Azure SignalR poskytuje stejnou kapacitu výkonu pro ASP.NET SignalR.
Bezserverový režim
Klienti a služba Azure SignalR jsou zapojeni do bezserverového režimu. Každý klient představuje jedno připojení. Klient odesílá zprávy prostřednictvím rozhraní REST API jinému klientovi nebo všesměrové zprávy všem.
Odesílání zpráv s vysokou hustotou prostřednictvím rozhraní REST API není tak efektivní jako použití protokolu WebSocket. Vyžaduje, abyste pokaždé vytvořili nové připojení HTTP a to je dodatečné náklady v bezserverovém režimu.
Vysílání prostřednictvím rozhraní REST API
Všichni klienti navazují připojení WebSocket se službou Azure SignalR. Pak někteří klienti začnou vysílat prostřednictvím rozhraní REST API. Odesílání zpráv (příchozí) je vše prostřednictvím protokolu HTTP Post, což není ve srovnání s WebSocket efektivní.
| Vysílání prostřednictvím rozhraní REST API | Lekce 1 | Lekce 2 | Jednotka 10 | Jednotka 50 | Jednotka 100 | Lekce 200 | Jednotka 500 | Jednotka 1000 |
|---|---|---|---|---|---|---|---|---|
| Propojení | 1000 | 2 000 | 10,000 | 50 000 | 100 000 | 200 000 | 500,000 | 1 000 000 |
| Příchozí zprávy za sekundu | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| Odchozí zprávy za sekundu | 2 000 | 4 000 | 20,000 | 100 000 | 200 000 | 400 000 | 1 000 000 | 2,000,000 |
| Příchozí šířka pásma | 4 KB/s | 4 KB/s | 4 KB/s | 4 KB/s | 4 KB/s | 4 KB/s | 4 KB/s | 4 KB/s |
| Odchozí šířka pásma | 4 MB/s | 8 MB/s | 40 MB/s | 200 MB/s | 400 MB/s | 800 MB/s | 2 000 MB/s | 4 000 MB/s |
Odeslání uživateli prostřednictvím rozhraní REST API
Srovnávací test před zahájením připojování ke službě Azure SignalR přiřadí všem klientům uživatelská jména. Jakmile klienti navazují připojení WebSocket se službou Azure SignalR, začnou odesílat zprávy ostatním prostřednictvím protokolu HTTP Post.
| Odeslání uživateli prostřednictvím rozhraní REST API | Lekce 1 | Lekce 2 | Jednotka 10 | Jednotka 50 | Jednotka 100 | Lekce 200 | Jednotka 500 | Jednotka 1000 |
|---|---|---|---|---|---|---|---|---|
| Propojení | 1000 | 2 000 | 10,000 | 50 000 | 100 000 | 200 000 | 500,000 | 1 000 000 |
| Příchozí nebo odchozí zprávy za sekundu | 200 | 400 | 2 000 | 10,000 | 20,000 | 40 000 | 100 000 | 200 000 |
| Příchozí/odchozí šířka pásma | 400 KB/s | 800 KB/s | 4 Mb/s | 20 MB/s | 40 MB/s | 80 MB/s | 200 MB/s | 400 MB/s |
Testovací prostředí výkonu
Pro všechny výše uvedené případy použití jsme provedli testy výkonnosti v prostředí Azure. Ve většině případů jsme používali 200 klientských virtuálních počítačů a 100 virtuálních počítačů aplikačního serveru. Tady jsou některé podrobnosti:
Velikost klientského virtuálního počítače: StandardDS2V2 (2 vCPU, 7G paměť)
Velikost virtuálního počítače aplikačního serveru: StandardF4sV2 (4 vCPU, 8G paměť)
Připojení serveru sady Azure SignalR SDK: 15
Nástroje pro měření výkonu
Nástroje pro měření výkonu pro službu Azure SignalR Najdete na GitHubu.
Další kroky
V tomto článku jste získali přehled o výkonu služby Azure SignalR v typických scénářích použití.
Pokud chcete získat podrobnosti o interních informacích o službě a škálování pro ni, přečtěte si následující příručky: