Guida alle prestazioni per il servizio Web PubSub di Azure

Uno dei vantaggi principali dell'uso del servizio Web PubSub di Azure è la facilità di ridimensionamento. In uno scenario su larga scala, le prestazioni sono un fattore importante.

In questa guida vengono presentati i fattori che influiscono sulle prestazioni del servizio Web PubSub. Vengono descritte le prestazioni tipiche in scenari di casi d'uso diversi.

Valutazione rapida con le metriche

Prima di esaminare i fattori che influiscono sulle prestazioni, è possibile introdurre un modo semplice per monitorare la pressione del servizio. Nel portale è presente una metrica denominata Carico server.

Screenshot della metrica Caricamento server di Pubblicazione Web di Azure nel portale. La metrica indica che il carico del server è a circa l'8% di utilizzo.

Mostra la pressione di calcolo del servizio Web PubSub di Azure. È possibile testare uno scenario personalizzato e controllare questa metrica per decidere se aumentare le prestazioni. La latenza all'interno del servizio Web PubSub di Azure rimane bassa se il carico del server è inferiore al 70%.

Nota

Se si usa l'unità 50 o superiore e lo scenario viene inviato principalmente a gruppi di piccole dimensioni (dimensioni <del gruppo 20), è necessario controllare l'invio a un gruppo di piccole dimensioni per riferimento. In questi scenari è previsto un costo di routing elevato che non è incluso nel carico del server.

Di seguito sono riportati i concetti dettagliati per la valutazione delle prestazioni.

Definizioni dei termini

In ingresso: messaggio in ingresso al servizio PubSub Web di Azure.

In uscita: messaggio in uscita dal servizio PubSub Web di Azure.

Larghezza di banda: dimensioni totali di tutti i messaggi in 1 secondo.

Panoramica

Questa guida risponde alle domande seguenti:

  • Qual è la tipica prestazioni del servizio Web PubSub di Azure per ogni dimensione di unità?

  • Il servizio Web PubSub di Azure 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 le dimensioni dell'unità appropriate?

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 i casi d'uso tipici: inviare a gruppi tramite sottoprotocolo PubSub Web, upstream e api rest .

Questa guida non può trattare tutti gli scenari (e casi d'uso diversi, dimensioni dei messaggi, modelli di invio di messaggi e così via). Fornisce tuttavia alcune informazioni di base per comprendere la limitazione 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. La velocità effettiva massima (larghezza di banda in ingresso e in uscita) viene definita come velocità effettiva massima raggiunta quando il 99% dei messaggi ha una latenza inferiore a 1 secondo. Non è un limite rigido.

Fattori relativi alle prestazioni

Teoricamente, la capacità del servizio Web PubSub di Azure è limitata dalle risorse di calcolo: CPU, memoria e rete. Ad esempio, più connessioni al servizio Web PubSub di Azure fanno sì che il servizio usi più memoria. Per un traffico di messaggi di dimensioni maggiori(ad esempio, ogni messaggio supera i 2.048 byte), il servizio Web PubSub di Azure deve spendere più cicli di CPU per elaborare il traffico.

Il costo del routing dei messaggi limita anche le prestazioni. Il servizio Web PubSub di Azure svolge un ruolo come broker di messaggi, che instrada il messaggio tra un set di client. Uno scenario o un'API diversa richiede criteri di routing diversi.

Per l'eco, il client invia un messaggio all'upstream e l'upstream restituisce il messaggio al client. Questo modello ha il costo di routing più basso. Tuttavia, per la trasmissione, l'invio al gruppo e l'invio alla connessione, il servizio Web PubSub di Azure 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.

In sintesi, i fattori seguenti influiscono sulla capacità in ingresso e in uscita:

  • Dimensioni unità (CPU/memoria)

  • Numero di connessioni

  • Dimensione del messaggio

  • Frequenza di invio dei messaggi

  • Scenario del caso d'uso (costo di routing)

Ricerca di una dimensione di unità appropriata

In che modo è possibile valutare la capacità in ingresso/in uscita o individuare le dimensioni delle unità adatte a un caso d'uso specifico?

Ogni dimensione di unità 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 il traffico in ingresso o in uscita supera la soglia.

  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: intervallo per l'invio di messaggi. Ad esempio, 1 secondo significa inviare un messaggio ogni secondo. Un intervallo più piccolo significa inviare più messaggi in un periodo di tempo. Ad esempio, 0,5 secondi significa inviare due messaggi ogni secondo.
  • Connessione ions: soglia massima di commit per il servizio Web PubSub di Azure per ogni dimensione di unità. Connessione ions che superano la soglia vengono limitate.

Si supponga che l'upstream 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 dimensione di unità.

Case study

Le sezioni seguenti illustrano tre casi d'uso tipici: inviare a gruppi tramite sottoprotocolo Web PubSub, attivare CloudEvent, chiamare l'API REST. Per ogni scenario, la sezione elenca la capacità in ingresso e in uscita corrente per il servizio Web PubSub di Azure. Vengono inoltre illustrati i fattori principali che influiscono sulle prestazioni.

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.

Inviare a gruppi tramite sottoprotocolo Web PubSub

Il servizio supporta un sottoprotocolo specifico denominato json.webpubsub.azure.v1, che consente ai client di eseguire direttamente la pubblicazione/sottoscrizione anziché un round trip al server upstream. Questo scenario è efficiente perché non viene coinvolto alcun server e tutto il traffico passa attraverso la connessione WebSocket del servizio client.

Diagramma che mostra il flusso di lavoro di invio al gruppo.

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 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.
  • 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.

L'invio al gruppo comporta un costo di routing al servizio Web PubSub di Azure perché deve trovare le connessioni di destinazione tramite una struttura di dati distribuita. Con l'aumento delle connessioni di invio, il costo aumenta.

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.

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 1.000 5.000 10,000 5.000 10,000 20.000
Conteggio gruppi 10 10 10 10 10 10 10 10
Messaggi in ingresso al secondo 30 30 30 30 30 30 30 30
Larghezza di banda in ingresso 60 KBps 60 KBps 60 KBps 60 KBps 60 KBps 60 KBps 60 KBps 60 KBps
Messaggi in uscita al secondo 3,000 6.000 30.000 150.000 300.000 600,000 1,500,000 3,000,000
Larghezza di banda in uscita 6 MBps 12 MBps 60 MBps 300 MBps 600 MBps 1.200 MBps 3.000 MBps 6.000 MBps
Piccolo gruppo

Il costo del routing è significativo per l'invio di messaggi a molti piccoli gruppi. Attualmente, l'implementazione del servizio Web PubSub di Azure raggiunge il limite di costo 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, è necessario aumentare le prestazioni per usare Premium_P2(unità >100).

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

Nota

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.

Attivazione dell'evento cloud

Il servizio recapita gli eventi client al webhook upstream usando il protocollo HTTP CloudEvents.

The Upstream Webhook

Per ogni evento, formula una richiesta HTTP POST all'upstream registrato e prevede una risposta HTTP.

Nota

Web PubSub supporta anche HTTP 2.0 per la distribuzione di eventi upstream. Il risultato seguente viene testato usando HTTP 1.1. Se il server app supporta HTTP 2.0, le prestazioni saranno migliori.

Echo

In questo caso, il server app scrive nuovamente il messaggio originale nella risposta HTTP. 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 500 1.000 5.000 25,000 50,000 100,000 250.000 500,000
Larghezza di banda in ingresso/in uscita 1 MBps 2 MBps 10 MBps 50 MBps 100 MBps 200 MBps 500 MBps 1.000 MBps

REST API

Web PubSub di Azure offre API avanzate per gestire i client e recapitare messaggi in tempo reale.

Diagramma che mostra il flusso di lavoro complessivo del servizio Web PubSub usando le API REST.

Inviare all'utente tramite l'API REST

Il benchmark assegna nomi utente a tutti i client prima di iniziare la connessione al servizio Web PubSub di Azure.

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 180 360 1.800 9,000 18.000 36.000 90.000 180,000
Larghezza di banda in ingresso/in uscita 360 KBps 720 KBps 3,6 MBps 18 MBps 36 MBps 72 MBps 180 MBps 360 MBps

Trasmettere tramite l'API REST

La larghezza di banda è identica a quella per l'invio a un gruppo di grandi dimensioni.

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 3 3 3 3 3 3 3 3
Messaggi in uscita al secondo 3,000 6.000 30.000 150.000 300.000 600,000 1,500,000 3,000,000
Larghezza di banda in ingresso 6 KBps 6 KBps 6 KBps 6 KBps 6 KBps 6 KBps 6 KBps 6 KBps
Larghezza di banda in uscita 6 MBps 12 MBps 60 MBps 300 MBps 600 MBps 1.200 MBps 3.000 MB 6.000 MB

Passaggi successivi

Usare queste risorse per iniziare a creare un'applicazione personalizzata: