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.
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.
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.
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.
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:
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per