Guida alle prestazioni per il Servizio Azure SignalR
Uno dei vantaggi principali dell'uso di Servizio Azure SignalR è la facilità di ridimensionamento delle applicazioni SignalR. In uno scenario su larga scala, le prestazioni sono un fattore importante.
L'articolo illustra:
- Fattori che influiscono sulle prestazioni dell'applicazione SignalR.
- Prestazioni tipiche in scenari di casi d'uso diversi.
- Ambiente e strumenti che è possibile usare per generare un report sulle prestazioni.
Valutazione rapida con le metriche
È possibile monitorare facilmente il servizio nel portale di Azure. Nella pagina Metriche dell'istanza di SignalR è possibile selezionare le metriche di caricamento del server per visualizzare la "pressione" del servizio.
Il grafico mostra la pressione di calcolo del servizio SignalR. È possibile testare lo scenario e controllare questa metrica per decidere se aumentare le prestazioni. La latenza all'interno del servizio SignalR rimane bassa se il carico del server è inferiore al 70%.
Nota
Se si usa l'unità 50 o superiore e lo scenario sta inviando principalmente a gruppi di piccole dimensioni (dimensioni <del gruppo 20) o a una singola connessione, è necessario controllare l'invio a un gruppo di piccole dimensioni o l'invio alla connessione per riferimento. In questi scenari è previsto un costo di routing elevato che non è incluso nel carico del server.
Definizioni dei termini
In ingresso: messaggio in arrivo da Servizio Azure SignalR.
In uscita: messaggio in uscita da Servizio Azure SignalR.
Larghezza di banda: dimensioni totali di tutti i messaggi in 1 secondo.
Modalità predefinita: modalità di lavoro predefinita quando viene creata un'istanza di Servizio Azure SignalR. Servizio Azure SignalR prevede che il server app stabilisca una connessione prima di accettare qualsiasi connessione client.
Modalità serverless: modalità in cui Servizio Azure SignalR accetta solo le connessioni client. Non è consentita alcuna connessione al server.
Panoramica
Servizio Azure SignalR definisce sette livelli Standard per capacità di prestazioni diverse. Questa guida risponde alle domande seguenti:
Qual è la tipica Servizio Azure SignalR prestazioni per ogni livello (unità)?
Servizio Azure SignalR soddisfa i requisiti per la velocità effettiva dei messaggi, ad esempio l'invio di 100.000 messaggi al secondo?
Per lo scenario specifico, come è possibile selezionare il livello appropriato?
Quale tipo di server app (dimensioni macchina virtuale) è adatto per l'utente corrente? Quanti di essi è necessario distribuire?
Per rispondere a queste domande, questa guida fornisce prima una spiegazione generale dei fattori che influiscono sulle prestazioni. Illustra quindi il numero massimo di messaggi in ingresso e in uscita per ogni livello per i casi d'uso tipici: echo, broadcast, send to group e send to connection (peer-to-peer chatting).
Questa guida non può trattare tutti gli scenari (e casi d'uso diversi, dimensioni dei messaggi, modelli di invio di messaggi e così via). Ma fornisce alcuni metodi per aiutarti:
- Valutare il requisito approssimativo per i messaggi in ingresso o in uscita.
- Trovare i livelli appropriati controllando la tabella delle prestazioni.
Informazioni dettagliate sulle prestazioni
Questa sezione descrive le metodologie di valutazione delle prestazioni e quindi elenca tutti i fattori che influiscono sulle prestazioni. Alla fine, fornisce metodi che consentono di valutare i requisiti di prestazioni.
Metodologia
La velocità effettiva e la latenza sono due aspetti tipici del controllo delle prestazioni. Per Servizio Azure SignalR, ogni livello SKU ha i propri criteri di limitazione della velocità effettiva. Il criterio definisce la velocità effettiva massima consentita (larghezza di banda in ingresso e in uscita) come velocità effettiva massima ottenuta quando il 99% dei messaggi ha una latenza inferiore a 1 secondo.
La latenza è l'intervallo di tempo dalla connessione che invia il messaggio alla ricezione del messaggio di risposta da Servizio Azure SignalR. Prendiamo eco come esempio. Ogni connessione client aggiunge un timestamp nel messaggio. L'hub del server app invia di nuovo il messaggio originale al client. Il ritardo di propagazione viene quindi calcolato facilmente da ogni connessione client. Il timestamp viene allegato per ogni messaggio in trasmissione, invia al gruppo e invia alla connessione.
Per simulare migliaia di connessioni client simultanee, vengono create più macchine virtuali in una rete privata virtuale in Azure. Tutte queste macchine virtuali si connettono alla stessa istanza di Servizio Azure SignalR.
Nella modalità predefinita di Servizio Azure SignalR, le macchine virtuali del server app vengono distribuite nella stessa rete privata virtuale delle macchine virtuali client. Tutte le macchine virtuali client e le macchine virtuali del server app vengono distribuite nella stessa rete della stessa area per evitare la latenza tra aree.
Fattori relativi alle prestazioni
I fattori seguenti influiscono sulle prestazioni di SignalR.
- Livello SKU (CPU/memoria)
- Numero di connessioni
- Dimensione del messaggio
- Frequenza di invio dei messaggi
- Tipo di trasporto (WebSocket, Server-Sent-Event o Long-Polling)
- Scenario del caso d'uso (costo di routing)
- Connessioni al server app e al servizio (in modalità server)
Risorse computer
Teoricamente, Servizio Azure SignalR capacità è limitata dalle risorse di calcolo: CPU, memoria e rete. Ad esempio, più connessioni a Servizio Azure SignalR fanno sì che il servizio usi più memoria. Per un traffico di messaggi di dimensioni maggiori(ad esempio, ogni messaggio è maggiore di 2.048 byte), Servizio Azure SignalR deve spendere più cicli di CPU per elaborare il traffico. Nel frattempo, la larghezza di banda di rete di Azure impone anche un limite per il traffico massimo.
Tipo di trasporto
Il tipo di trasporto è un altro fattore che influisce sulle prestazioni. I tre tipi sono:
- WebSocket: WebSocket è un protocollo di comunicazione bidirezionale e full-duplex su una singola connessione TCP.
- Server-Sent-Event: Server-Sent-Event è un protocollo unidirezionale per eseguire il push dei messaggi dal server al client.
- Polling lungo: il polling lungo richiede che i client eseguano periodicamente il polling delle informazioni dal server tramite una richiesta HTTP.
Per la stessa API con le stesse condizioni, WebSocket offre prestazioni ottimali, Server-Sent-Event è più lento e Long-Polling è il più lento. Servizio Azure SignalR consiglia WebSocket per impostazione predefinita.
Costo del routing dei messaggi
Il costo del routing dei messaggi limita anche le prestazioni. Servizio Azure SignalR svolge un ruolo come router di messaggi, che indirizza il messaggio da un set di client o server ad altri client o server. Uno scenario o un'API diversa richiede criteri di routing diversi.
Per echo, il client invia un messaggio a se stesso e anche la destinazione di routing è stessa. Questo modello ha il costo di routing più basso. Tuttavia, per la trasmissione, l'invio al gruppo e l'invio alla connessione, Servizio Azure SignalR deve cercare le connessioni di destinazione tramite la struttura interna dei dati distribuiti. Questa elaborazione aggiuntiva usa più CPU, memoria e larghezza di banda di rete. Di conseguenza, le prestazioni sono più lente.
Nella modalità predefinita, il server app potrebbe anche diventare un collo di bottiglia per determinati scenari. Azure SignalR SDK deve richiamare l'hub, mentre mantiene una connessione dinamica con ogni client tramite segnali heartbeat.
In modalità serverless, il client invia un messaggio tramite post HTTP, che non è così efficiente come WebSocket.
Protocollo
Un altro fattore è il protocollo: JSON e MessagePack. MessagePack è più piccolo di dimensioni e viene recapitato più velocemente rispetto a JSON. MessagePack potrebbe tuttavia non migliorare le prestazioni. Le prestazioni di Servizio Azure SignalR non sono sensibili ai protocolli perché non decodificano il payload del messaggio durante l'inoltro dei messaggi dai client ai server o viceversa.
Ricerca di uno SKU appropriato
Come è possibile valutare la capacità in ingresso/in uscita o trovare quale livello è adatto per un caso d'uso specifico?
Si supponga che il server app sia abbastanza potente e non sia il collo di bottiglia delle prestazioni. Controllare quindi la larghezza di banda in ingresso e in uscita massima per ogni livello.
Valutazione rapida
Per una valutazione rapida, presupporre le impostazioni predefinite seguenti:
- Il tipo di trasporto è WebSocket.
- La dimensione del messaggio è di 2.048 byte.
- Un messaggio viene inviato ogni 1 secondo.
- Servizio Azure SignalR è in modalità predefinita.
Ogni livello ha la propria larghezza di banda in ingresso massima e la larghezza di banda in uscita. Un'esperienza utente senza problemi non è garantita dopo che la connessione in ingresso o in uscita supera il limite.
Echo offre la larghezza di banda in ingresso massima perché ha il costo di routing più basso. Broadcast definisce la larghezza di banda massima dei messaggi in uscita.
Non superare i valori evidenziati nelle due tabelle seguenti.
| Echo | Unità 1 | Unità 2 | Unità 10 | Unità 50 | Unità 100 | Unità 200 | Unità 500 | Unità 1000 |
|---|---|---|---|---|---|---|---|---|
| Connessioni | 1.000 | 2.000 | 10,000 | 50,000 | 100,000 | 200.000 | 500,000 | 1\.000.000 |
| Larghezza di banda in ingresso | 2 MBps | 4 MBps | 20 MBps | 100 MBps | 200 MBps | 400 MBps | 1.000 MBps | 2.000 MBps |
| Larghezza di banda in uscita | 2 MBps | 4 MBps | 20 MBps | 100 MBps | 200 MBps | 400 MBps | 1.000 MBps | 2.000 MBps |
| Broadcast | Unità 1 | Unità 2 | Unità 10 | Unità 50 | Unità 100 | Unità 200 | Unità 500 | Unità 1000 |
|---|---|---|---|---|---|---|---|---|
| Connessioni | 1.000 | 2.000 | 10,000 | 50,000 | 100,000 | 200.000 | 500,000 | 1\.000.000 |
| Larghezza di banda in ingresso | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps |
| Larghezza di banda in uscita | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 400 MBps | 800 MBps | 2.000 MBps | 4.000 MBps |
La larghezza di banda in ingresso e la larghezza di banda in uscita sono le dimensioni totali del messaggio al secondo. Di seguito sono riportate le formule seguenti:
inboundBandwidth = inboundConnections * messageSize / sendInterval
outboundBandwidth = outboundConnections * messageSize / sendInterval
in ingresso Connessione ions: numero di connessioni che inviano il messaggio.
outbound Connessione ions: numero di connessioni che ricevono il messaggio.
messageSize: dimensioni di un singolo messaggio (valore medio). Un piccolo messaggio minore di 1.024 byte ha un impatto sulle prestazioni simile a un messaggio a 1.024 byte.
sendInterval: ora di invio di un messaggio. In genere è 1 secondo per messaggio, ovvero l'invio di un messaggio ogni secondo. Un intervallo più piccolo significa inviare più messaggi in un periodo di tempo. Ad esempio, 0,5 secondi per messaggio significa inviare due messaggi ogni secondo.
Connessione ions: soglia massima di commit per Servizio Azure SignalR per ogni livello. Se il numero di connessione viene aumentato ulteriormente, si verifica una limitazione della connessione.
Nota
È necessario aumentare le prestazioni fino allo SKU Premium_P2 per avere dimensioni di unità superiori a 100.
Valutazione per casi d'uso complessi
Dimensioni maggiori dei messaggi o frequenza di invio diversa
Il caso d'uso reale è più complicato. Potrebbe inviare un messaggio maggiore di 2.048 byte oppure la frequenza di invio dei messaggi non è un messaggio al secondo. Prendiamo come esempio la trasmissione dell'Unità 100 per scoprire come valutarne le prestazioni.
Nella tabella seguente viene illustrato un caso d'uso reale della trasmissione. Tuttavia, le dimensioni del messaggio, il numero di connessioni e la frequenza di invio dei messaggi sono diversi da quanto si presuppone nella sezione precedente. La domanda è come si può dedurre uno qualsiasi di questi elementi (dimensione del messaggio, numero di connessioni o frequenza di invio di messaggi) se ne conoscono solo due.
| Broadcast | Dimensione del messaggio | Messaggi in ingresso simultanei | Connessioni | Intervalli di invio |
|---|---|---|---|---|
| 1 | 20 KB | 1 | 100,000 | 5 Secondi |
| 2 | 256 kB | 1 | 8.000 | 5 Secondi |
La formula seguente è facile da dedurre in base alla formula precedente:
outboundConnections = outboundBandwidth * sendInterval / messageSize
Per l'unità 100, la larghezza di banda in uscita massima è di 400 MB rispetto alla tabella precedente. Per una dimensione del messaggio di 20 KB, le connessioni in uscita massime devono essere pari a 400 MB * 5 / 20 KB = 100.000, che corrisponde al valore reale.
Casi d'uso misti
Il caso d'uso reale combina in genere i quattro casi d'uso di base: echo, broadcast, send to group e send to connection. La metodologia usata per valutare la capacità consiste nel:
- Dividere i casi d'uso misti in quattro casi d'uso di base.
- Calcolare la larghezza di banda massima dei messaggi in ingresso e in uscita usando le formule precedenti separatamente.
- Sommare i calcoli della larghezza di banda per ottenere la larghezza di banda massima massima in ingresso/in uscita.
Selezionare quindi il livello appropriato dalle tabelle della larghezza di banda in ingresso/in uscita massima.
Nota
Per inviare un messaggio a centinaia o migliaia di piccoli gruppi o per migliaia di client che inviano un messaggio l'uno all'altro, il costo di routing diventerà dominante. Prendere in considerazione questo impatto.
Per il caso d'uso dell'invio di un messaggio ai client, assicurarsi che il server app non sia il collo di bottiglia. La sezione "Case study" seguente fornisce linee guida sul numero di server app necessari e sul numero di connessioni server da configurare.
Case study
Le sezioni seguenti illustrano quattro casi d'uso tipici per il trasporto WebSocket: echo, broadcast, send to group e send to connection. Per ogni scenario, la sezione elenca la capacità in ingresso e in uscita corrente per Servizio Azure SignalR. Vengono inoltre illustrati i fattori principali che influiscono sulle prestazioni.
Nella modalità predefinita, il server app crea cinque connessioni server con Servizio Azure SignalR. Il server app usa Servizio Azure SignalR SDK per impostazione predefinita. Nei risultati del test delle prestazioni seguenti, le connessioni server vengono aumentate a 15 (o più per la trasmissione e l'invio di un messaggio a un gruppo di grandi dimensioni).
Casi d'uso diversi hanno requisiti diversi per i server app. Broadcast richiede un numero ridotto di server app. Echo o send to connection richiede molti server app.
In tutti i casi d'uso, la dimensione predefinita del messaggio è di 2.048 byte e l'intervallo di invio del messaggio è di 1 secondo.
Modalità predefinita
I client, i server app Web e Servizio Azure SignalR sono coinvolti nella modalità predefinita. Ogni client è l'acronimo di una singola connessione.
Echo
Prima di tutto, un'app Web si connette a Servizio Azure SignalR. In secondo luogo, molti client si connettono all'app Web, che reindirizza i client a Servizio Azure SignalR con il token di accesso e l'endpoint. I client stabiliscono quindi connessioni WebSocket con Servizio Azure SignalR.
Dopo che tutti i client stabiliscono le connessioni, iniziano a inviare un messaggio che contiene un timestamp all'hub specifico ogni secondo. L'hub restituisce il messaggio al client originale. Ogni client calcola la latenza quando riceve di nuovo il messaggio echo.
Nel diagramma seguente, da 5 a 8 (traffico evidenziato in rosso) si trovano in un ciclo. Il ciclo viene eseguito per una durata predefinita (5 minuti) e ottiene la statistica di tutta la latenza del messaggio.
Il comportamento di echo determina che la larghezza di banda in ingresso massima è uguale alla larghezza di banda in uscita massima. Per informazioni dettagliate, vedere la tabella seguente.
| Echo | Unità 1 | Unità 2 | Unità 10 | Unità 50 | Unità 100 | Unità 200 | Unità 500 | Unità 1000 |
|---|---|---|---|---|---|---|---|---|
| Connessioni | 1.000 | 2.000 | 10,000 | 50,000 | 100,000 | 200.000 | 500,000 | 1\.000.000 |
| Messaggi in ingresso/in uscita al secondo | 1.000 | 2.000 | 10,000 | 50,000 | 100,000 | 200.000 | 500,000 | 1\.000.000 |
| Larghezza di banda in ingresso/in uscita | 2 MBps | 4 MBps | 20 MBps | 100 MBps | 200 MBps | 400 MBps | 1.000 MBps | 2.000 MBps |
In questo caso d'uso, ogni client richiama l'hub definito nel server app. L'hub chiama semplicemente il metodo definito sul lato client originale. Questo hub è l'hub più leggero per echo.
public void Echo(IDictionary<string, object> data)
{
Clients.Client(Context.ConnectionId).SendAsync("RecordLatency", data);
}
Anche per questo hub semplice, la pressione del traffico sul server app è importante quando il carico dei messaggi in ingresso echo aumenta. Questa pressione del traffico richiede molti server app per livelli SKU di grandi dimensioni. La tabella seguente elenca il numero di server app per ogni livello.
| Echo | Unità 1 | Unità 2 | Unità 10 | Unità 50 | Unità 100 | Unità 200 | Unità 500 | Unità 1000 |
|---|---|---|---|---|---|---|---|---|
| Connessioni | 1.000 | 2.000 | 10,000 | 50,000 | 100,000 | 200.000 | 500,000 | 1\.000.000 |
| Numero di server app | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Nota
Il numero di connessione client, le dimensioni dei messaggi, la frequenza di invio dei messaggi, il livello SKU e la CPU/memoria del server app influiscono sulle prestazioni complessive dell'eco.
Broadcast
Per la trasmissione, quando l'app Web riceve il messaggio, trasmette a tutti i client. Maggiore è il numero di client da trasmettere, maggiore è il traffico di messaggi a tutti i client. Vedere il diagramma seguente.
Un numero ridotto di client sta trasmettendo. La larghezza di banda dei messaggi in ingresso è ridotta, ma la larghezza di banda in uscita è enorme. La larghezza di banda dei messaggi in uscita aumenta con l'aumento della velocità di trasmissione o della connessione client.
La tabella seguente riepiloga le connessioni client massime, il numero di messaggi in ingresso/in uscita e la larghezza di banda.
| Broadcast | Unità 1 | Unità 2 | Unità 10 | Unità 50 | Unità 100 | Unità 200 | Unità 500 | Unità 1000 |
|---|---|---|---|---|---|---|---|---|
| Connessioni | 1.000 | 2.000 | 10,000 | 50,000 | 100,000 | 200.000 | 500,000 | 1\.000.000 |
| Messaggi in ingresso al secondo | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| Messaggi in uscita al secondo | 2.000 | 4.000 | 20.000 | 100,000 | 200.000 | 400.000 | 1\.000.000 | 2,000,000 |
| Larghezza di banda in ingresso | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps |
| Larghezza di banda in uscita | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 400 MBps | 800 MBps | 2.000 MBps | 4.000 MBps |
I client di trasmissione che pubblicano messaggi non sono più di quattro. Hanno bisogno di meno server app rispetto a echo perché la quantità di messaggi in ingresso è piccola. Due server app sono sufficienti sia per il contratto di servizio che per le prestazioni. È tuttavia consigliabile aumentare le connessioni server predefinite per evitare squilibri, in particolare per Unità maggiore di 50.
| Broadcast | Unità 1 | Unità 2 | Unità 10 | Unità 50 | Unità 100 | Unità 200 | Unità 500 | Unità 1000 |
|---|---|---|---|---|---|---|---|---|
| Connessioni | 1.000 | 2.000 | 10,000 | 50,000 | 100,000 | 200.000 | 500,000 | 1\.000.000 |
| Numero di server app | 1 | 1 | 1 | 2 | 2 | 4 | 10 | 20 |
Nota
Aumentare le connessioni server predefinite da 5 a 40 in ogni server app per evitare possibili connessioni server sbilanciate a Servizio Azure SignalR.
Il numero di connessione client, le dimensioni dei messaggi, la frequenza di invio dei messaggi e il livello SKU influiscono sulle prestazioni complessive per la trasmissione.
Invia al gruppo
Il caso d'uso di send to group ha un modello di traffico simile da trasmettere. La differenza è che, dopo che i client stabiliscono connessioni WebSocket con Servizio Azure SignalR, devono partecipare ai gruppi prima di poter inviare un messaggio a un gruppo specifico. Il diagramma seguente illustra il flusso del traffico.
I membri del gruppo e il conteggio dei gruppi sono due fattori che influiscono sulle prestazioni. Per semplificare l'analisi, vengono definiti due tipi di gruppi:
Gruppo piccolo: ogni gruppo ha 10 connessioni. Il numero di gruppo è uguale a (numero massimo di connessioni) / 10. Ad esempio, per l'unità 1, se sono presenti 1.000 conteggi di connessioni, sono presenti 1000 / 10 = 100 gruppi.
Gruppo grande: il numero di gruppo è sempre 10. Il conteggio dei membri del gruppo è uguale a (numero massimo di connessioni) / 10. Ad esempio, per l'unità 1, se sono presenti 1.000 conteggi di connessioni, ogni gruppo ha 1000 / 10 = 100 membri.
L'invio al gruppo comporta un costo di routing per Servizio Azure SignalR perché deve trovare le connessioni di destinazione tramite una struttura di dati distribuita. Con l'aumento delle connessioni di invio, il costo aumenta.
Piccolo gruppo
Il costo del routing è significativo per l'invio di messaggi a molti piccoli gruppi. Attualmente, l'implementazione Servizio Azure SignalR raggiunge il limite dei costi di routing a Unità 50. L'aggiunta di più CPU e memoria non è utile, quindi l'unità 100 non può migliorare ulteriormente in base alla progettazione. Se è necessaria una maggiore larghezza di banda in ingresso, contattare il supporto tecnico.
| Invia a un gruppo di piccole dimensioni | Unità 1 | Unità 2 | Unità 10 | Unità 50 | Unità 100 | Unità 200 | Unità 500 | Unità 1000 |
|---|---|---|---|---|---|---|---|---|
| Connessioni | 1.000 | 2.000 | 10,000 | 50,000 | 100,000 | 200.000 | 500,000 | 1\.000.000 |
| Conteggio dei membri del gruppo | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| Conteggio gruppi | 100 | 200 | 1.000 | 5.000 | 10,000 | 20.000 | 50,000 | 100,000 |
| Messaggi in ingresso al secondo | 200 | 400 | 2.000 | 10,000 | 10,000 | 20.000 | 50,000 | 100,000 |
| Larghezza di banda in ingresso | 400 KBps | 800 KBps | 4 MBps | 20 MBps | 20 MBps | 40 MBps | 100 MBps | 200 MBps |
| Messaggi in uscita al secondo | 2.000 | 4.000 | 20.000 | 100,000 | 100,000 | 200.000 | 500,000 | 1\.000.000 |
| Larghezza di banda in uscita | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 200 MBps | 400 MBps | 1.000 MBps | 2.000 MBps |
Molte connessioni client chiamano l'hub, quindi anche il numero del server app è fondamentale per le prestazioni. Nella tabella seguente sono elencati i conteggi dei server app suggeriti.
| Invia a un gruppo di piccole dimensioni | Unità 1 | Unità 2 | Unità 10 | Unità 50 | Unità 100 | Unità 200 | Unità 500 | Unità 1000 |
|---|---|---|---|---|---|---|---|---|
| Connessioni | 1.000 | 2.000 | 10,000 | 50,000 | 100,000 | 200.000 | 500,000 | 1\.000.000 |
| Numero di server app | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Nota
Il numero di connessione client, le dimensioni dei messaggi, la frequenza di invio dei messaggi, il costo di routing, il livello SKU e la CPU/memoria del server app influiscono sulle prestazioni complessive dell'invio a un gruppo ridotto.
Il numero di gruppi, il numero di membri del gruppo elencati nella tabella non sono limiti rigidi. Questi valori di parametro sono selezionati per stabilire uno scenario di benchmark stabile. Ad esempio, è OK assegnare ogni conneciton a un gruppo distinto. In questa configurazione, le prestazioni sono vicine all'invio alla connessione.
Gruppo grande
Per l'invio a un gruppo di grandi dimensioni, la larghezza di banda in uscita diventa il collo di bottiglia prima di raggiungere il limite dei costi di routing. La tabella seguente elenca la larghezza di banda in uscita massima, quasi identica a quella per la trasmissione.
| Invia a un gruppo di grandi dimensioni | Unità 1 | Unità 2 | Unità 10 | Unità 50 | Unità 100 | Unità 200 | Unità 500 | Unità 1000 |
|---|---|---|---|---|---|---|---|---|
| Connessioni | 1.000 | 2.000 | 10,000 | 50,000 | 100,000 | 200.000 | 500,000 | 1\.000.000 |
| Conteggio dei membri del gruppo | 100 | 200 | 500 | 1.000 | 2.000 | 5,000 | 10,000 | 20.000 |
| Conteggio gruppi | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| Messaggi in ingresso al secondo | 20 | 20 | 20 | 20 | 20 | 20 | 20 | 20 |
| Larghezza di banda in ingresso | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps |
| Messaggi in uscita al secondo | 2.000 | 4.000 | 20.000 | 100,000 | 200.000 | 400.000 | 1\.000.000 | 2,000,000 |
| Larghezza di banda in uscita | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 400 MBps | 800 MBps | 2.000 MBps | 4.000 MBps |
Il numero di connessioni di invio non è superiore a 40. Il carico sul server app è ridotto, quindi il numero suggerito di app Web è ridotto.
| Invia a un gruppo di grandi dimensioni | Unità 1 | Unità 2 | Unità 10 | Unità 50 | Unità 100 | Unità 200 | Unità 500 | Unità 1000 |
|---|---|---|---|---|---|---|---|---|
| Connessioni | 1.000 | 2.000 | 10,000 | 50,000 | 100,000 | 200.000 | 500,000 | 1\.000.000 |
| Numero di server app | 1 | 1 | 2 | 2 | 2 | 4 | 10 | 20 |
Nota
Aumentare le connessioni server predefinite da 5 a 40 in ogni server app per evitare possibili connessioni server sbilanciate a Servizio Azure SignalR.
Il numero di connessione client, le dimensioni dei messaggi, la frequenza di invio dei messaggi, il costo di routing e il livello SKU influiscono sulle prestazioni complessive dell'invio a un gruppo di grandi dimensioni.
Invia alla connessione
Nel caso d'uso dell'invio alla connessione, quando i client stabiliscono le connessioni a Servizio Azure SignalR, ogni client chiama un hub speciale per ottenere il proprio ID connessione. Il benchmark delle prestazioni raccoglie tutti gli ID di connessione, li riassegna e li riassegna a tutti i client come destinazione di invio. I client continuano a inviare il messaggio alla connessione di destinazione fino al termine del test delle prestazioni.
Il costo di routing per l'invio alla connessione è simile al costo per l'invio a un gruppo di piccole dimensioni.
Man mano che aumenta il numero di connessioni, il costo del routing diventa un fattore critico che limita le prestazioni complessive. In particolare, l'unità 20 contrassegna la soglia in cui il servizio raggiunge il collo di bottiglia del routing. Ulteriori aumenti del numero di unità non producono miglioramenti delle prestazioni, a meno che non si verifichi un passaggio a Premium_P2(unità >=100), che migliora le funzionalità di routing.
La tabella seguente è un riepilogo statistico dopo molti round di esecuzione dell'invio al benchmark di connessione .
| Invia alla connessione | Unità 1 | Unità 2 | Unità 20 | Unità 50 | Unità 100 | Unità 200 | Unità 500 | Unità 1000 |
|---|---|---|---|---|---|---|---|---|
| Connessioni | 1.000 | 2.000 | 20.000 | 50,000 | 100,000 | 200.000 | 500,000 | 1\.000.000 |
| Messaggi in ingresso/in uscita al secondo | 1.000 | 2.000 | 20.000 | 20.000 | 20.000 | 40.000 | 100,000 | 200.000 |
| Larghezza di banda in ingresso/in uscita | 2 MBps | 4 MBps | 40 MBps | 40 MBps | 40 MBps | 80 MBps | 200 MBps | 400 MBps |
Nota
Nonostante la stagnazione dei messaggi in ingresso/in uscita al secondo dopo l'unità 20, la capacità per più connessioni continua a crescere. Negli scenari aziendali reali, spesso si tratta del numero di connessioni, non delle attività simultanee di invio di messaggi, che costituisce il collo di bottiglia. Non è raro che tutte le connessioni inviino attivamente messaggi a frequenze così elevate come il test di benchmark.
Questo caso d'uso richiede un carico elevato sul lato server dell'app. Vedere il conteggio dei server app suggeriti nella tabella seguente.
| Invia alla connessione | Unità 1 | Unità 2 | Unità 10 | Unità 50 | Unità 100 | Unità 200 | Unità 500 | Unità 1000 |
|---|---|---|---|---|---|---|---|---|
| Connessioni | 1.000 | 2.000 | 10,000 | 50,000 | 100,000 | 200.000 | 500,000 | 1\.000.000 |
| Numero di server app | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Nota
Il numero di connessione client, le dimensioni dei messaggi, la frequenza di invio dei messaggi, il costo di routing, il livello SKU e la CPU/memoria per il server app influiscono sulle prestazioni complessive dell'invio alla connessione.
ASP.NET SignalR
Servizio Azure SignalR offre la stessa capacità di prestazioni per ASP.NET SignalR.
Modalità Serverless
I client e le Servizio Azure SignalR sono coinvolti in modalità serverless. Ogni client è l'acronimo di una singola connessione. Il client invia messaggi tramite l'API REST a un altro client o trasmette messaggi a tutti.
L'invio di messaggi ad alta densità tramite l'API REST non è efficiente quanto l'uso di WebSocket. È necessario creare una nuova connessione HTTP ogni volta ed è un costo aggiuntivo in modalità serverless.
Trasmettere tramite l'API REST
Tutti i client stabiliscono connessioni WebSocket con Servizio Azure SignalR. Alcuni client avviano quindi la trasmissione tramite l'API REST. Il messaggio di invio (in ingresso) è tutto tramite HTTP Post, che non è efficiente rispetto a WebSocket.
| Trasmettere tramite l'API REST | Unità 1 | Unità 2 | Unità 10 | Unità 50 | Unità 100 | Unità 200 | Unità 500 | Unità 1000 |
|---|---|---|---|---|---|---|---|---|
| Connessioni | 1.000 | 2.000 | 10,000 | 50,000 | 100,000 | 200.000 | 500,000 | 1\.000.000 |
| Messaggi in ingresso al secondo | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| Messaggi in uscita al secondo | 2.000 | 4.000 | 20.000 | 100,000 | 200.000 | 400.000 | 1\.000.000 | 2,000,000 |
| Larghezza di banda in ingresso | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps |
| Larghezza di banda in uscita | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 400 MBps | 800 MBps | 2.000 MBps | 4.000 MBps |
Inviare all'utente tramite l'API REST
Il benchmark assegna nomi utente a tutti i client prima di iniziare la connessione a Servizio Azure SignalR. Dopo che i client stabiliscono connessioni WebSocket con Servizio Azure SignalR, iniziano a inviare messaggi ad altri utenti tramite HTTP Post.
| Inviare all'utente tramite l'API REST | Unità 1 | Unità 2 | Unità 10 | Unità 50 | Unità 100 | Unità 200 | Unità 500 | Unità 1000 |
|---|---|---|---|---|---|---|---|---|
| Connessioni | 1.000 | 2.000 | 10,000 | 50,000 | 100,000 | 200.000 | 500,000 | 1\.000.000 |
| Messaggi in ingresso/in uscita al secondo | 200 | 400 | 2.000 | 10,000 | 20.000 | 40.000 | 100,000 | 200.000 |
| Larghezza di banda in ingresso/in uscita | 400 KBps | 800 KBps | 4 MBps | 20 MBps | 40 MBps | 80 MBps | 200 MBps | 400 MBps |
Ambienti di test delle prestazioni
Per tutti i casi d'uso elencati in precedenza, sono stati eseguiti i test delle prestazioni in un ambiente Azure. Al massimo sono stati usati 200 macchine virtuali client e 100 macchine virtuali server app. Ecco alcuni dettagli:
Dimensioni della macchina virtuale client: StandardDS2V2 (2 vCPU, memoria 7G)
Dimensioni della macchina virtuale del server app: StandardF4sV2 (4 vCPU, memoria 8G)
Connessioni server azure SignalR SDK: 15
Strumenti per le prestazioni
È possibile trovare strumenti per le prestazioni per Servizio Azure SignalR in GitHub.
Passaggi successivi
In questo articolo è disponibile una panoramica delle prestazioni Servizio Azure SignalR in scenari tipici del caso d'uso.
Per ottenere informazioni dettagliate sugli elementi interni del servizio e sul ridimensionamento, leggere le guide seguenti: