Sdílet prostřednictvím

Zprávy a připojení ve službě Azure SignalR

  • Článek

Model fakturace služby Azure SignalR vychází z počtu připojení a počtu odchozích zpráv ze služby. Tento článek vysvětluje, jak se definují a započítávají zprávy a připojení pro fakturaci.

Formáty zpráv

Služba Azure SignalR podporuje stejné formáty jako ASP.NET Core SignalR: JSON a MessagePack.

Velikost zprávy

Pro zprávy služby Azure SignalR platí následující omezení:

  • Klientské zprávy:
    • U dlouhých událostí dotazování nebo na straně serveru nemůže klient odesílat zprávy větší než 1 MB.
    • Pro webSocket pro službu neexistuje žádné omezení velikosti.
    • Aplikační server může nastavit limit pro velikost zprávy klienta. Výchozí hodnota je 32 kB. Další informace najdete v tématu Aspekty zabezpečení v ASP.NET Core SignalR.
    • U bezserverové verze je velikost zprávy omezená upstreamovou implementací, ale doporučuje se méně než 1 MB.
  • Zprávy serveru:
    • Velikost zprávy serveru není nijak omezena, ale doporučuje se méně než 16 MB.
    • Aplikační server může nastavit limit pro velikost zprávy klienta. Výchozí hodnota je 32 kB. Další informace najdete v tématu Aspekty zabezpečení v ASP.NET Core SignalR.
    • Bezserverová služba:

U klientů WebSocket jsou velké zprávy rozděleny do menších zpráv, které nejsou větší než 2 kB a přenášeny samostatně. Sady SDK zpracovávají dělení zpráv a sestavení. Nejsou potřeba žádné vývojářské snahy.

Velké zprávy mají negativní vliv na výkon zasílání zpráv. Používejte menší zprávy, kdykoli je to možné, a otestujte optimální velikost zprávy pro každý scénář použití.

Jak se započítávají zprávy pro fakturaci

Zprávy odeslané do služby jsou příchozí zprávy a zprávy odeslané ze služby jsou odchozí zprávy. Pro fakturaci se počítají jenom odchozí zprávy ze služby Azure SignalR. Zprávy Ping mezi klientem a serverem se ignorují.

Zprávy větší než 2 kB se počítají jako více zpráv o 2 kB. Graf počtu zpráv na webu Azure Portal se aktualizuje každých 100 zpráv na centrum.

Představte si například, že máte jeden aplikační server a tři klienty:

  • Když aplikační server vysílá zprávu 1 kB všem připojeným klientům, považuje se zpráva ze aplikačního serveru do služby za bezplatnou příchozí zprávu. Tři zprávy odeslané ze služby do každého z klientů jsou odchozí zprávy a fakturují se.

  • Když klient A odešle klientovi B příchozí zprávu o 1 kB, aniž by procházel aplikačním serverem, je tato zpráva bezplatnou příchozí zprávou. Zpráva směrovaná ze služby do klienta B se účtuje jako odchozí zpráva.

  • Když jeden klient odešle zprávu o 4 kB pro všesměrové vysílání serveru všem klientům a existují tři klienty a jeden aplikační server, fakturovaná zpráva je osm:

    • Jedna zpráva ze služby na aplikační server.
    • Tři zprávy ze služby klientům. Každá zpráva se počítá jako dvě 2kB zprávy.

Jak se počítá připojení

Služba Azure SignalR vytvoří aplikační server a klientská připojení. Ve výchozím nastavení každý aplikační server začíná s pěti počátečními připojeními na centrum a každý klient má jedno klientské připojení.

Předpokládejme například, že máte dva aplikační servery a v kódu definujete pět center. Počet připojení k serveru je 50: (2 aplikační servery * 5 rozbočovačů * 5 připojení na rozbočovač).

Počet připojení zobrazený na webu Azure Portal zahrnuje připojení k serveru, klientovi, diagnostice a živému trasování. Typy připojení jsou definovány v následujícím seznamu:

  • Připojení k serveru: Připojí službu Azure SignalR a aplikační server.
  • Připojení klienta: Připojí službu Azure SignalR a klientskou aplikaci.
  • Diagnostické připojení: Speciální typ připojení klienta, který může vytvořit podrobnější protokol, který může ovlivnit výkon. Tento typ klienta je určený pro řešení potíží.
  • Živé připojení trasování: Připojuje se ke koncovému bodu živého trasování a přijímá živé trasování služby Azure SignalR.

Živé trasování připojení se nezapočítává jako připojení klienta ani jako připojení k serveru.

ASP.NET SignalR počítá připojení serveru jiným způsobem. Kromě rozbočovačů, které definujete, zahrnuje i jedno výchozí centrum. Ve výchozím nastavení každý aplikační server potřebuje pět dalších počátečních připojení k serveru. Počáteční počet připojení výchozího rozbočovače zůstává konzistentní s ostatními rozbočovači.

Služba a aplikační server neustále synchronizují stav připojení a upravují připojení k serveru, aby se zlepšil výkon a stabilita služeb. Může se tedy zobrazit změna počtu připojení serveru ve spuštěné službě.