Teljesítménnyel kapcsolatos útmutatás az Azure SignalR Service-hez
Az Azure SignalR Szolgáltatás használatának egyik fő előnye a SignalR-alkalmazások egyszerű skálázása. Nagy léptékű forgatókönyvekben a teljesítmény fontos tényező.
Ez a cikk a következőket ismerteti:
- A SignalR-alkalmazás teljesítményét befolyásoló tényezők.
- A különböző használati esetek jellemző teljesítménye.
- A teljesítményjelentés létrehozásához használható környezet és eszközök.
Gyors értékelés metrikák használatával
A szolgáltatást egyszerűen monitorozhatja az Azure Portalon. A SignalR-példány Metrikák lapján kiválaszthatja a kiszolgálói terhelés mérőszámait a szolgáltatás "nyomásának" megtekintéséhez.
A diagram a SignalR szolgáltatás számítási nyomását mutatja. Tesztelheti a forgatókönyvet, és ellenőrizheti ezt a metrikát, hogy eldöntse, felskáláz-e. A SignalR szolgáltatás késése alacsony marad, ha a kiszolgáló terhelése 70% alatt van.
Megjegyzés:
Ha az 50-es vagy annál nagyobb egységet használja, és a forgatókönyv főként kis csoportoknak (20-os csoportméret <) vagy egyetlen kapcsolatnak küldi el a forgatókönyvet, ellenőriznie kell a kis csoportokba való küldést vagy a kapcsolatra való küldést hivatkozás céljából. Ezekben a forgatókönyvekben nagy útválasztási költségek merülnek fel, amelyek nem szerepelnek a kiszolgáló terhelésében.
Kifejezésdefiníciók
Bejövő: A bejövő üzenet az Azure SignalR Service-nek.
Kimenő: Az Azure SignalR Service kimenő üzenete.
Sávszélesség: Az összes üzenet teljes mérete 1 másodperc alatt.
Alapértelmezett mód: Az Azure SignalR Service-példány létrehozásakor az alapértelmezett munkamód. Az Azure SignalR Service elvárja, hogy az alkalmazáskiszolgáló kapcsolatot létesítsen vele, mielőtt bármilyen ügyfélkapcsolatot elfogad.
Kiszolgáló nélküli mód: Olyan mód, amelyben az Azure SignalR Service csak ügyfélkapcsolatokat fogad el. Nincs kiszolgálókapcsolat.
Áttekintés
Az Azure SignalR Service hét standard szintet határoz meg a különböző teljesítménykapacitásokhoz. Ez az útmutató a következő kérdésekre ad választ:
Mi a tipikus Azure SignalR-szolgáltatás teljesítménye az egyes szintekhez (egységekhez)?
Megfelel az Azure SignalR Szolgáltatás az üzenet átviteli sebességére vonatkozó követelményeimnek (például másodpercenként 100 000 üzenet küldése)?
Az adott forgatókönyv esetében hogyan választhatom ki a megfelelő szintet?
Milyen típusú alkalmazáskiszolgáló (virtuálisgép-méret) alkalmas számomra? Hányat helyezzek üzembe?
Ezeknek a kérdéseknek a megválaszolásához ez az útmutató először magas szintű magyarázatot ad a teljesítményt befolyásoló tényezőkről. Ezután bemutatja az egyes szintek maximális bejövő és kimenő üzeneteit a tipikus használati esetekhez: echo, szórás, küldés csoportnak és küldés a kapcsolatra (társközi csevegés).
Ez az útmutató nem fedi le az összes forgatókönyvet (és a különböző használati eseteket, üzenetméreteket, üzenetküldési mintákat stb.). De néhány módszert kínál a segítségére:
- Értékelje ki a bejövő vagy kimenő üzenetekre vonatkozó hozzávetőleges követelményt.
- A teljesítménytáblázat ellenőrzésével keresse meg a megfelelő szinteket.
Teljesítményelemzés
Ez a szakasz a teljesítményértékelés módszertanát ismerteti, majd felsorolja a teljesítményt befolyásoló összes tényezőt. Végül olyan módszereket biztosít, amelyekkel kiértékelheti a teljesítménykövetelményeket.
Módszertan
Az átviteli sebesség és a késés a teljesítmény-ellenőrzés két jellemző aspektusa. Az Azure SignalR Szolgáltatás esetében minden termékváltozat-szint saját átviteli sebességszabályozási szabályzattal rendelkezik. A szabályzat az engedélyezett maximális átviteli sebességet (bejövő és kimenő sávszélességet) határozza meg az elért maximális átviteli sebességként, ha az üzenetek 99%-a 1 másodpercnél kisebb késéssel rendelkezik.
A késés az az időtartam, amely az üzenetet küldő kapcsolattól az Azure SignalR Service-től érkező válaszüzenet fogadásához szükséges. Vegyük példaként az echot . Minden ügyfélkapcsolat hozzáad egy időbélyeget az üzenethez. Az alkalmazáskiszolgáló központja visszaküldi az eredeti üzenetet az ügyfélnek. Így a propagálási késleltetést könnyen kiszámíthatja minden ügyfélkapcsolat. Az időbélyeg a közvetítésben lévő összes üzenethez, a csoporthoz való küldéshez és a kapcsolathoz való küldéshez van csatolva.
Több ezer egyidejű ügyfélkapcsolat szimulálásához több virtuális gép jön létre egy Azure-beli virtuális magánhálózaton. Ezek a virtuális gépek ugyanahhoz az Azure SignalR-szolgáltatáspéldányhoz csatlakoznak.
Az Azure SignalR Service alapértelmezett módjában az alkalmazáskiszolgáló virtuális gépek ugyanabban a virtuális magánhálózatban vannak üzembe helyezve, mint az ügyfél virtuális gépek. Az összes ügyfél- és alkalmazáskiszolgáló virtuális gép ugyanabban a régióban található hálózaton van üzembe helyezve, hogy elkerülje a régiók közötti késést.
Teljesítménytényezők
Az alábbi tényezők befolyásolják a SignalR teljesítményét.
- Termékváltozat szintje (CPU/memória)
- Kapcsolatok száma
- Üzenet mérete
- Üzenetküldési sebesség
- Átviteli típus (WebSocket, Server-Sent-Event vagy Long-Polling)
- Használati eset (útválasztási költség)
- Alkalmazáskiszolgálói és szolgáltatáskapcsolatok (kiszolgáló módban)
Számítógép-erőforrások
Az Azure SignalR szolgáltatás kapacitását elméletileg a számítási erőforrások korlátozzák: CPU, memória és hálózat. Például az Azure SignalR Service-hez való további kapcsolatok miatt a szolgáltatás több memóriát használ. Nagyobb üzenetforgalom esetén (például minden üzenet nagyobb, mint 2048 bájt), az Azure SignalR Szolgáltatásnak több processzorciklust kell fordítania a forgalom feldolgozásához. Eközben az Azure hálózati sávszélessége is korlátozza a maximális forgalmat.
Átviteli típus
Az átviteli típus egy másik tényező, amely befolyásolja a teljesítményt. A három típus a következő:
- WebSocket: A WebSocket kétirányú és teljes kétirányú kommunikációs protokoll egyetlen TCP-kapcsolaton keresztül.
- Server-Sent-Event: A Server-Sent-Event egy egyirányú protokoll, amely üzeneteket küld le a kiszolgálóról az ügyfélre.
- Hosszú lekérdezés: A hosszú lekérdezések megkövetelik, hogy az ügyfelek rendszeresen lekérdezik az adatokat a kiszolgálóról EGY HTTP-kérésen keresztül.
Ugyanahhoz az API-hoz azonos feltételek mellett a WebSocket a legjobb teljesítményt nyújtja, a Server-Sent-Event lassabb, a Long-Polling pedig a leglassabb. Az Azure SignalR Service alapértelmezés szerint a WebSocket használatát javasolja.
Üzenet-útválasztás költsége
Az üzenet-útválasztás költsége a teljesítményt is korlátozza. Az Azure SignalR Szolgáltatás üzenet útválasztóként játszik szerepet, amely az üzeneteket egy ügyfél- vagy kiszolgálókészletből más ügyfelekre vagy kiszolgálókra irányítja. Egy másik forgatókönyv vagy API eltérő útválasztási szabályzatot igényel.
Visszhang esetén az ügyfél üzenetet küld magának, és az útválasztási cél is maga. Ez a minta a legalacsonyabb útválasztási költséggel rendelkezik. A közvetítéshez, a csoportosításhoz és a kapcsolatra való küldéshez azonban az Azure SignalR Service-nek a belső elosztott adatstruktúrán keresztül kell megkeresnie a célkapcsolatokat. Ez az extra feldolgozás több processzort, memóriát és hálózati sávszélességet használ. Ennek eredményeképpen a teljesítmény lassabb.
Az alapértelmezett módban az alkalmazáskiszolgáló is szűk keresztmetszetté válhat bizonyos forgatókönyvek esetében. Az Azure SignalR SDK-nak meg kell hívnia a központot, miközben szívverési jeleken keresztül élő kapcsolatot tart fenn minden ügyféllel.
Kiszolgáló nélküli módban az ügyfél HTTP-bejegyzéssel küld üzenetet, amely nem olyan hatékony, mint a WebSocket.
Protokoll
Egy másik tényező a protokoll: JSON és MessagePack. A MessagePack mérete kisebb, és gyorsabban kézbesítve, mint a JSON. Előfordulhat azonban, hogy a MessagePack nem javítja a teljesítményt. Az Azure SignalR Szolgáltatás teljesítménye nem érzékeny a protokolloktól, mert nem dekódolja az üzenet hasznos adatait az ügyfelekről a kiszolgálókra történő üzenettovábbítás során, vagy fordítva.
Megfelelő termékváltozat megkeresése
Hogyan értékelheti ki a bejövő/kimenő kapacitást, vagy hogy melyik szint felel meg egy adott használati esetnek?
Tegyük fel, hogy az alkalmazáskiszolgáló elég hatékony, és nem a teljesítmény szűk keresztmetszete. Ezután ellenőrizze a maximális bejövő és kimenő sávszélességet minden szinten.
Gyors értékelés
Gyors kiértékeléshez adja meg a következő alapértelmezett beállításokat:
- Az átviteli típus a WebSocket.
- Az üzenet mérete 2048 bájt.
- A rendszer 1 másodpercenként küld üzenetet.
- Az Azure SignalR szolgáltatás az alapértelmezett módban van.
Minden réteg saját maximális bejövő sávszélességtel és kimenő sávszélességtel rendelkezik. A zökkenőmentes felhasználói élmény nem garantált, ha a bejövő vagy kimenő kapcsolat meghaladja a korlátot.
Az Echo maximális bejövő sávszélességet ad, mert a legalacsonyabb útválasztási költséggel rendelkezik. A szórás határozza meg a kimenő üzenetek maximális sávszélességét.
Ne lépje túl a kiemelt értékeket a következő két táblában.
| Echo | 1. egység | 2. egység | 10. egység | 50. egység | 100. egység | Egység 200 | 500- os egység | Egység 1000 |
|---|---|---|---|---|---|---|---|---|
| Connections | 1000 | 2,000 | 10,000. | 50 000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| Bejövő sávszélesség | 2 MBps | 4 MBps | 20 MBps | 100 MBps | 200 MBps | 400 MBps | 1000 MBps | 2000 MBps |
| Kimenő sávszélesség | 2 MBps | 4 MBps | 20 MBps | 100 MBps | 200 MBps | 400 MBps | 1000 MBps | 2000 MBps |
| Szórás | 1. egység | 2. egység | 10. egység | 50. egység | 100. egység | Egység 200 | 500- os egység | Egység 1000 |
|---|---|---|---|---|---|---|---|---|
| Connections | 1000 | 2,000 | 10,000. | 50 000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| Bejövő sávszélesség | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps |
| Kimenő sávszélesség | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 400 MBps | 800 MBps | 2000 MBps | 4000 MBps |
A bejövő sávszélesség és a kimenő sávszélesség az üzenet másodpercenkénti teljes mérete. A képletek a következők:
inboundBandwidth = inboundConnections * messageSize / sendInterval
outboundBandwidth = outboundConnections * messageSize / sendInterval
bejövő Csatlakozás ions: Az üzenetet küldő kapcsolatok száma.
kimenő Csatlakozás ions: Az üzenetet fogadó kapcsolatok száma.
messageSize: Egyetlen üzenet mérete (átlagos érték). Az 1024 bájtnál kisebb kis méretű üzenetek teljesítménybeli hatása hasonló az 1024 bájtos üzenethez.
sendInterval: Egy üzenet elküldésének időpontja. Általában üzenetenként 1 másodperc, ami azt jelenti, hogy másodpercenként egy üzenetet küld. A kisebb időköz azt jelenti, hogy több üzenetet küld egy adott időszakban. Például az üzenetenként 0,5 másodperc azt jelenti, hogy másodpercenként két üzenetet küld.
Csatlakozás ions: Az Azure SignalR Service véglegesített maximális küszöbértéke minden szinten. Ha a kapcsolat száma tovább nő, akkor a kapcsolat szabályozása is megesik.
Megjegyzés:
A 100-nál nagyobb egységmérethez fel kell skáláznia a termékváltozatra Premium_P2 .
Komplex használati esetek kiértékelése
Nagyobb üzenetméret vagy eltérő küldési sebesség
A valódi használati eset bonyolultabb. 2048 bájtnál nagyobb üzenetet küldhet, vagy az üzenetküldés sebessége nem másodpercenként egy üzenet. Vegyük példaként a Unit 100 közvetítését a teljesítmény kiértékeléséhez.
Az alábbi táblázat egy valós szórási esetet mutat be. Az üzenet mérete, a kapcsolatok száma és az üzenetküldés sebessége azonban eltér az előző szakaszban feltételezetttől. A kérdés az, hogyan következtethetünk ezekre az elemekre (üzenetméret, kapcsolatszám vagy üzenetküldési sebesség), ha csak kettőt ismerünk.
| Szórás | Üzenet mérete | Egyidejű bejövő üzenetek | Connections | Időközök küldése |
|---|---|---|---|---|
| 1 | 20 KB | 1 | 100,000 | 5 másodperc |
| 2 | 256 KB | 1 | 8,000 | 5 másodperc |
Az alábbi képlet könnyen következtethető az előző képlet alapján:
outboundConnections = outboundBandwidth * sendInterval / messageSize
A Unit 100 esetében a kimenő sávszélesség maximális mérete 400 MB az előző táblától. 20 KB-os üzenetméret esetén a kimenő kapcsolatok maximális száma 400 MB * 5 /20 KB = 100 000, amely megfelel a valós értéknek.
Vegyes használati esetek
A valós használati eset általában összekeveri a négy alapszintű használati esetet: echo, szórás, küldés csoportra, és küldés a kapcsolatra. A kapacitás értékeléséhez használt módszertan a következő:
- Ossza fel a vegyes használati eseteket négy alapszintű használati esetre.
- Számítsa ki a bejövő és kimenő üzenetek maximális sávszélességét az előző képletek külön-külön használatával.
- Összegzi a sávszélesség-számításokat a maximális bejövő/kimenő sávszélesség lekéréséhez.
Ezután vegye fel a megfelelő szintet a maximális bejövő/kimenő sávszélességtáblákból.
Megjegyzés:
Ha több száz vagy több ezer kis csoportnak vagy több ezer ügyfélnek küld üzenetet, az útválasztási költség lesz domináns. Vegye figyelembe ezt a hatást.
Ha üzenetet küld az ügyfeleknek, győződjön meg arról, hogy az alkalmazáskiszolgáló nem szűk keresztmetszet. Az alábbi "Esettanulmány" szakasz útmutatást nyújt arról, hogy hány alkalmazáskiszolgálóra van szüksége, és hány kiszolgálókapcsolatot kell konfigurálnia.
Esettanulmány
A következő szakaszok a WebSocket átvitelének négy tipikus használati esetét ismertetik: echo, szórás, küldés csoportra és küldés a kapcsolatra. Minden forgatókönyv esetében a szakasz az Azure SignalR Szolgáltatás aktuális bejövő és kimenő kapacitását sorolja fel. Emellett a teljesítményt befolyásoló fő tényezőket is ismerteti.
Az alapértelmezett módban az alkalmazáskiszolgáló öt kiszolgálókapcsolatot hoz létre az Azure SignalR Service-vel. Az alkalmazáskiszolgáló alapértelmezés szerint az Azure SignalR Service SDK-t használja. A következő teljesítményteszt eredményeiben a kiszolgálókapcsolatok száma 15-re nő (vagy több a nagy csoportnak való közvetítéshez és üzenetküldéshez).
A különböző használati esetek eltérő követelményeket támasztanak az alkalmazáskiszolgálókra vonatkozóan. A közvetítéshez kis számú alkalmazáskiszolgáló szükséges. Az echo vagy a küldés a kapcsolatra számos alkalmazáskiszolgálót igényel.
Minden használati esetben az alapértelmezett üzenetméret 2048 bájt, az üzenetküldési időköz pedig 1 másodperc.
Alapértelmezett mód
Az ügyfelek, webalkalmazás-kiszolgálók és az Azure SignalR Service az alapértelmezett módban vannak. Minden ügyfél egyetlen kapcsolatot jelent.
Echo
Először is egy webalkalmazás csatlakozik az Azure SignalR Service-hez. Másodszor, sok ügyfél csatlakozik a webalkalmazáshoz, amely átirányítja az ügyfeleket az Azure SignalR Szolgáltatásba a hozzáférési jogkivonattal és a végponttal. Ezután az ügyfelek WebSocket-kapcsolatokat létesítenek az Azure SignalR Service-vel.
Miután minden ügyfél kapcsolatot létesített, másodpercenként egy időbélyeget tartalmazó üzenetet kezd küldeni az adott központnak. A központ visszakozza az üzenetet az eredeti ügyfélnek. Minden ügyfél kiszámítja a késést, amikor visszakapja az echo-üzenetet.
Az alábbi ábrán 5–8 (piros kiemelésű forgalom) ciklusban van. A hurok egy alapértelmezett időtartamig (5 percig) fut, és lekéri az összes üzenet késésének statisztikáját.
Az echo viselkedése azt határozza meg, hogy a maximális bejövő sávszélesség egyenlő-e a maximális kimenő sávszélességével. További részletekért tekintse meg az alábbi táblázatot.
| Echo | 1. egység | 2. egység | 10. egység | 50. egység | 100. egység | Egység 200 | 500- os egység | Egység 1000 |
|---|---|---|---|---|---|---|---|---|
| Connections | 1000 | 2,000 | 10,000. | 50 000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| Bejövő/kimenő üzenetek másodpercenként | 1000 | 2,000 | 10,000. | 50 000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| Bejövő/kimenő sávszélesség | 2 MBps | 4 MBps | 20 MBps | 100 MBps | 200 MBps | 400 MBps | 1000 MBps | 2000 MBps |
Ebben a használati esetben minden ügyfél meghívja az alkalmazáskiszolgálón definiált központot. A központ csak az eredeti ügyféloldalon definiált metódust hívja meg. Ez a központ az echo leggyönyrösebb központja.
public void Echo(IDictionary<string, object> data)
{
Clients.Client(Context.ConnectionId).SendAsync("RecordLatency", data);
}
Még ennél az egyszerű központnál is az alkalmazáskiszolgálóra nehezedő forgalomterhelés a visszhangos bejövő üzenetek terhelésének növekedésével szembetűnő. Ez a forgalmi nyomás sok alkalmazáskiszolgálót igényel a nagy termékváltozat-szintekhez. Az alábbi táblázat az alkalmazáskiszolgálók számát sorolja fel minden szinten.
| Echo | 1. egység | 2. egység | 10. egység | 50. egység | 100. egység | Egység 200 | 500- os egység | Egység 1000 |
|---|---|---|---|---|---|---|---|---|
| Connections | 1000 | 2,000 | 10,000. | 50 000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| Alkalmazáskiszolgálók száma | 0 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Megjegyzés:
Az alkalmazáskiszolgáló ügyfélkapcsolati száma, üzenetmérete, üzenetküldési sebessége, termékváltozatszintje és PROCESSZOR-/memóriája befolyásolja a visszhang általános teljesítményét.
Szórás
A közvetítéshez, amikor a webalkalmazás megkapja az üzenetet, az minden ügyfélnek továbbítva lesz. Minél több ügyfelet szeretne közvetíteni, annál több üzenetforgalom irányítja az összes ügyfelet. Lásd az alábbi diagramot.
Kis számú ügyfél sugároz. A bejövő üzenetek sávszélessége kicsi, de a kimenő sávszélesség hatalmas. A kimenő üzenetek sávszélessége az ügyfélkapcsolat vagy a szórási sebesség növekedésével növekszik.
Az alábbi táblázat összefoglalja az ügyfélkapcsolatok maximális számát, a bejövő/kimenő üzenetek számát és a sávszélességet.
| Szórás | 1. egység | 2. egység | 10. egység | 50. egység | 100. egység | Egység 200 | 500- os egység | Egység 1000 |
|---|---|---|---|---|---|---|---|---|
| Connections | 1000 | 2,000 | 10,000. | 50 000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| Bejövő üzenetek másodpercenként | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| Kimenő üzenetek másodpercenként | 2,000 | 4 000 | 20,000 | 100,000 | 200,000 | 400,000 | 1,000,000 | 2,000,000 |
| Bejövő sávszélesség | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps |
| Kimenő sávszélesség | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 400 MBps | 800 MBps | 2000 MBps | 4000 MBps |
Az üzeneteket közzétenő műsorszolgáltató ügyfelek legfeljebb négyen vannak. Kevesebb alkalmazáskiszolgálóra van szükségük az echo-hoz képest, mert a bejövő üzenetek mennyisége kicsi. Két alkalmazáskiszolgáló elegendő mind az SLA, mind a teljesítmény szempontjából. Az 50-nél nagyobb egység esetében azonban növelnie kell az alapértelmezett kiszolgálókapcsolatokat.
| Szórás | 1. egység | 2. egység | 10. egység | 50. egység | 100. egység | Egység 200 | 500- os egység | Egység 1000 |
|---|---|---|---|---|---|---|---|---|
| Connections | 1000 | 2,000 | 10,000. | 50 000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| Alkalmazáskiszolgálók száma | 0 | 1 | 0 | 2 | 2 | 4 | 10 | 20 |
Megjegyzés:
Növelje az alapértelmezett kiszolgálókapcsolatokat 5-ről 40-re minden alkalmazáskiszolgálón, hogy elkerülje az Azure SignalR Service-hez való esetleges kiegyensúlyozatlan kiszolgálókapcsolatokat.
Az ügyfélkapcsolat száma, az üzenet mérete, az üzenetküldés sebessége és a termékváltozat szintje befolyásolja a közvetítés általános teljesítményét.
Küldés csoportra
A küldés csoportnak használati esete hasonló forgalmi mintával rendelkezik, amelyet továbbítani szeretne. A különbség az, hogy miután az ügyfelek WebSocket-kapcsolatokat létesítenek az Azure SignalR Szolgáltatással, csatlakozniuk kell a csoportokhoz, mielőtt üzenetet küldhetnének egy adott csoportnak. Az alábbi ábra a forgalmi folyamatot szemlélteti.
A csoporttagság és a csoportszám két tényező, amelyek befolyásolják a teljesítményt. Az elemzés egyszerűsítése érdekében kétféle csoportot határozunk meg:
Kis csoport: Minden csoportnak 10 kapcsolata van. A csoport száma egyenlő (maximális kapcsolatszám) / 10. Például az 1. egység esetében, ha 1000 kapcsolatszám van, akkor 1000 / 10 = 100 csoportunk van.
Nagy csoport: A csoport száma mindig 10. A csoporttagok száma egyenlő (maximális kapcsolatszám) / 10. Például az 1. egység esetében, ha 1000 kapcsolatszám van, akkor minden csoportnak 1000/10 = 100 tagja van.
A Küldés csoporthoz útválasztási költséggel jár az Azure SignalR Service-nek, mert elosztott adatstruktúrán keresztül kell megtalálnia a célkapcsolatokat. A küldési kapcsolatok növekedésével a költségek növekednek.
Kis csoport
Az útválasztási költség jelentős, ha sok kis csoportnak küld üzenetet. Az Azure SignalR Szolgáltatás implementációja jelenleg az 50. egységnél éri el az útválasztási költségkorlátot. A processzor és a memória további hozzáadása nem segít, ezért a Unit 100 nem tud tovább fejlődni a tervezéssel. Ha több bejövő sávszélességre van szüksége, forduljon az ügyfélszolgálathoz.
| Küldés kis csoportnak | 1. egység | 2. egység | 10. egység | 50. egység | 100. egység | Egység 200 | 500- os egység | Egység 1000 |
|---|---|---|---|---|---|---|---|---|
| Connections | 1000 | 2,000 | 10,000. | 50 000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| Csoporttagok száma | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| Csoportszám | 100 | 200 | 1000 | 5000 | 10,000. | 20,000 | 50 000 | 100,000 |
| Bejövő üzenetek másodpercenként | 200 | 400 | 2,000 | 10,000. | 10,000. | 20,000 | 50 000 | 100,000 |
| Bejövő sávszélesség | 400 KBps | 800 KBps | 4 MBps | 20 MBps | 20 MBps | 40 MBps | 100 MBps | 200 MBps |
| Kimenő üzenetek másodpercenként | 2,000 | 4 000 | 20,000 | 100,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| Kimenő sávszélesség | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 200 MBps | 400 MBps | 1000 MBps | 2000 MBps |
Számos ügyfélkapcsolat hívja meg a központot, így az alkalmazáskiszolgáló száma is kritikus fontosságú a teljesítmény szempontjából. Az alábbi táblázat a javasolt alkalmazáskiszolgálók számát sorolja fel.
| Küldés kis csoportnak | 1. egység | 2. egység | 10. egység | 50. egység | 100. egység | Egység 200 | 500- os egység | Egység 1000 |
|---|---|---|---|---|---|---|---|---|
| Connections | 1000 | 2,000 | 10,000. | 50 000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| Alkalmazáskiszolgálók száma | 0 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Megjegyzés:
Az alkalmazáskiszolgáló ügyfélkapcsolati száma, üzenetmérete, üzenetküldési sebessége, útválasztási költsége, termékváltozatszintje és CPU/memóriája befolyásolja a kis csoportoknak történő küldés általános teljesítményét.
A táblázatban felsorolt csoportszám és csoporttagok száma nem szigorú korlát. Ezek a paraméterértékek egy stabil teljesítményteszt-forgatókönyv létrehozásához vannak kiválasztva. Az egyes connecitonokat például egy külön csoporthoz kell rendelni. Ebben a konfigurációban a teljesítmény közel áll a kapcsolathoz való küldéshez.
Nagy csoport
A nagy csoportnak való küldésnél a kimenő sávszélesség szűk keresztmetszetté válik, mielőtt eléri az útválasztási költségkorlátot. Az alábbi táblázat a maximális kimenő sávszélességet sorolja fel, ami majdnem megegyezik a szóráshoz használt sávszélességével.
| Küldés nagy csoportnak | 1. egység | 2. egység | 10. egység | 50. egység | 100. egység | Egység 200 | 500- os egység | Egység 1000 |
|---|---|---|---|---|---|---|---|---|
| Connections | 1000 | 2,000 | 10,000. | 50 000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| Csoporttagok száma | 100 | 200 | 500 | 1000 | 2,000 | 5000 | 10,000. | 20,000 |
| Csoportszám | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| Bejövő üzenetek másodpercenként | 20 | 20 | 20 | 20 | 20 | 20 | 20 | 20 |
| Bejövő sávszélesség | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps |
| Kimenő üzenetek másodpercenként | 2,000 | 4 000 | 20,000 | 100,000 | 200,000 | 400,000 | 1,000,000 | 2,000,000 |
| Kimenő sávszélesség | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 400 MBps | 800 MBps | 2000 MBps | 4000 MBps |
A küldési kapcsolatok száma legfeljebb 40 lehet. Az alkalmazáskiszolgáló terhelése kicsi, ezért a javasolt webalkalmazások száma kicsi.
| Küldés nagy csoportnak | 1. egység | 2. egység | 10. egység | 50. egység | 100. egység | Egység 200 | 500- os egység | Egység 1000 |
|---|---|---|---|---|---|---|---|---|
| Connections | 1000 | 2,000 | 10,000. | 50 000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| Alkalmazáskiszolgálók száma | 0 | 0 | 2 | 2 | 2 | 4 | 10 | 20 |
Megjegyzés:
Növelje az alapértelmezett kiszolgálókapcsolatokat 5-ről 40-re minden alkalmazáskiszolgálón, hogy elkerülje az Azure SignalR Service-hez való esetleges kiegyensúlyozatlan kiszolgálókapcsolatokat.
Az ügyfélkapcsolat száma, az üzenet mérete, az üzenetküldés sebessége, az útválasztási költség és az termékváltozat szintje befolyásolja a nagy csoportnak történő küldés általános teljesítményét.
Küldés a kapcsolatra
Amikor az ügyfelek kapcsolatot létesítenek az Azure SignalR Szolgáltatással, a küldés a kapcsolat használatára vonatkozó esetben minden ügyfél egy speciális központot hív meg a saját kapcsolatazonosítójuk lekéréséhez. A teljesítménymutató összegyűjti az összes kapcsolati azonosítót, elkeveri őket, és elküldi őket az összes ügyfélnek küldő célként. Az ügyfelek addig küldik az üzenetet a célkapcsolatnak, amíg a teljesítményteszt be nem fejeződik.
A kapcsolatra történő küldés útválasztási költsége hasonló a kis csoportokba történő küldés költségeihez.
A kapcsolatok számának növekedésével az útválasztás költsége kritikus tényezővé válik, ami korlátozza a teljes teljesítményt. Nevezetesen a 20. egység jelzi azt a küszöbértéket, ahol a szolgáltatás eléri az útválasztás szűk keresztmetszetét. Az egységszám további növekedése nem eredményez teljesítménybeli javulást, hacsak nem vált át a Premium_P2(egység >=100), amely javítja az útválasztási képességeket.
Az alábbi táblázat egy statisztikai összegzés, miután a küldés a kapcsolati teljesítménytesztet számos fordulóban futtatta.
| Küldés a kapcsolatra | 1. egység | 2. egység | 20. egység | 50. egység | 100. egység | Egység 200 | 500- os egység | Egység 1000 |
|---|---|---|---|---|---|---|---|---|
| Connections | 1000 | 2,000 | 20,000 | 50 000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| Bejövő/kimenő üzenetek másodpercenként | 1000 | 2,000 | 20,000 | 20,000 | 20,000 | 40 000 | 100,000 | 200,000 |
| Bejövő/kimenő sávszélesség | 2 MBps | 4 MBps | 40 MBps | 40 MBps | 40 MBps | 80 MBps | 200 MBps | 400 MBps |
Megjegyzés:
Annak ellenére, hogy a 20. egység után másodpercenként stagnál a bejövő/kimenő üzenetek száma, a további kapcsolatok kapacitása tovább nő. Valós üzleti forgatókönyvekben gyakran a kapcsolatok száma, nem pedig az egyidejű üzenetküldési tevékenységük képezi a szűk keresztmetszetet. Nem gyakori, hogy minden kapcsolat aktívan küld üzeneteket olyan magas frekvencián, mint a teljesítményteszt.
Ez a használati eset nagy terhelést igényel az alkalmazáskiszolgáló oldalán. Tekintse meg a javasolt alkalmazáskiszolgálók számát az alábbi táblázatban.
| Küldés a kapcsolatra | 1. egység | 2. egység | 10. egység | 50. egység | 100. egység | Egység 200 | 500- os egység | Egység 1000 |
|---|---|---|---|---|---|---|---|---|
| Connections | 1000 | 2,000 | 10,000. | 50 000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| Alkalmazáskiszolgálók száma | 0 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Megjegyzés:
Az alkalmazáskiszolgáló ügyfélkapcsolati száma, üzenetmérete, üzenetküldési sebessége, útválasztási költsége, termékváltozatszintje és CPU-ja/memóriája hatással van a kapcsolatra történő küldés általános teljesítményére.
ASP.NET SignalR
Az Azure SignalR szolgáltatás ugyanazt a teljesítménykapacitást biztosítja ASP.NET SignalR-hez.
Serverless mode
Az ügyfelek és az Azure SignalR Szolgáltatás kiszolgáló nélküli módban vannak. Minden ügyfél egyetlen kapcsolatot jelent. Az ügyfél üzeneteket küld a REST API-on keresztül egy másik ügyfélnek, vagy üzeneteket küld mindenkinek.
A nagy sűrűségű üzenetek REST API-val történő küldése nem olyan hatékony, mint a WebSocket használata. Minden alkalommal új HTTP-kapcsolatot kell létrehoznia, ami kiszolgáló nélküli módban extra költség.
Szórás REST API-val
Minden ügyfél WebSocket-kapcsolatokat létesít az Azure SignalR Szolgáltatással. Ezután néhány ügyfél a REST API-n keresztül kezdi a közvetítést. Az üzenetküldés (bejövő) a HTTP Poston keresztül történik, ami a WebSockethez képest nem hatékony.
| Szórás REST API-val | 1. egység | 2. egység | 10. egység | 50. egység | 100. egység | Egység 200 | 500- os egység | Egység 1000 |
|---|---|---|---|---|---|---|---|---|
| Connections | 1000 | 2,000 | 10,000. | 50 000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| Bejövő üzenetek másodpercenként | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| Kimenő üzenetek másodpercenként | 2,000 | 4 000 | 20,000 | 100,000 | 200,000 | 400,000 | 1,000,000 | 2,000,000 |
| Bejövő sávszélesség | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps |
| Kimenő sávszélesség | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 400 MBps | 800 MBps | 2000 MBps | 4000 MBps |
Küldés a felhasználónak a REST API-val
A teljesítményteszt felhasználóneveket rendel az összes ügyfélhez, mielőtt elkezdenének csatlakozni az Azure SignalR Service-hez. Miután az ügyfelek WebSocket-kapcsolatokat létesítettek az Azure SignalR Szolgáltatással, elkezdenek üzeneteket küldeni másoknak a HTTP Poston keresztül.
| Küldés a felhasználónak a REST API-val | 1. egység | 2. egység | 10. egység | 50. egység | 100. egység | Egység 200 | 500- os egység | Egység 1000 |
|---|---|---|---|---|---|---|---|---|
| Connections | 1000 | 2,000 | 10,000. | 50 000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| Bejövő/kimenő üzenetek másodpercenként | 200 | 400 | 2,000 | 10,000. | 20,000 | 40 000 | 100,000 | 200,000 |
| Bejövő/kimenő sávszélesség | 400 KBps | 800 KBps | 4 MBps | 20 MBps | 40 MBps | 80 MBps | 200 MBps | 400 MBps |
Teljesítménytesztelési környezetek
A fent felsorolt összes használati eset esetében elvégeztük a teljesítményteszteket egy Azure-környezetben. Legfeljebb 200 ügyfél virtuális gépet és 100 alkalmazáskiszolgáló virtuális gépet használtunk. Íme néhány részlet:
Ügyfél virtuális gép mérete: StandardDS2V2 (2 vCPU, 7G memória)
Alkalmazáskiszolgáló virtuális gép mérete: StandardF4sV2 (4 vCPU, 8G memória)
Azure SignalR SDK-kiszolgálókapcsolatok: 15
Teljesítményeszközök
Az Azure SignalR Service teljesítményeszközöket a GitHubon talál.
További lépések
Ebben a cikkben áttekintést kaphat az Azure SignalR Szolgáltatás teljesítményéről a tipikus használati helyzetekben.
A szolgáltatás belső elemeiről és a skálázásról az alábbi útmutatókban tájékozódhat: