Procedure consigliate per il miglioramento delle prestazioni tramite la messaggistica del bus di servizio

Questo articolo descrive come usare il bus di servizio di Azure per ottimizzare le prestazioni durante lo scambio di messaggi negoziati. La prima parte di questo articolo descrive diversi meccanismi per migliorare le prestazioni. La seconda parte fornisce indicazioni sull'uso di bus di servizio in modo da offrire prestazioni ottimali in uno scenario specifico.

In questo articolo il termine "client" fa riferimento a qualsiasi entità che accede al bus di servizio. Un client può assumere il ruolo di mittente o di ricevitore. Il termine "mittente" viene usato per un client della coda bus di servizio o un client di argomenti che invia messaggi a una coda di bus di servizio o a un argomento. Il termine "ricevitore" si riferisce a un client o una sottoscrizione della coda bus di servizio che riceve messaggi da una coda bus di servizio o da una sottoscrizione.

Pianificazione delle risorse e considerazioni

Come per qualsiasi resourcing tecnico, la pianificazione prudente è fondamentale per garantire che bus di servizio di Azure fornisca le prestazioni previste dall'applicazione. La configurazione o la topologia corretta per gli spazi dei nomi bus di servizio dipende da una serie di fattori che coinvolgono l'architettura dell'applicazione e dal modo in cui vengono usate ognuna delle funzionalità bus di servizio.

Piano tariffario

bus di servizio offre diversi piani tariffari. È consigliabile scegliere il livello appropriato per i requisiti dell'applicazione.

• Livello Standard: adatto per ambienti di sviluppo/test o scenari a bassa velocità effettiva in cui le applicazioni non sono sensibili alla limitazione.

• Livello Premium: adatto per gli ambienti di produzione con requisiti di velocità effettiva diversi in cui è necessaria latenza e la velocità effettiva prevedibili. Inoltre, bus di servizio spazi dei nomi Premium possono essere ridimensionati automaticamente e possono essere abilitati per supportare picchi di velocità effettiva.

Calcolo della velocità effettiva per Premium

I dati inviati a bus di servizio vengono serializzati in binario e quindi deserializzati quando vengono ricevuti dal ricevitore. Pertanto, mentre le applicazioni considerano i messaggi come unità atomica di lavoro, bus di servizio misura la velocità effettiva in termini di byte (o megabyte).

Quando si calcola il requisito di velocità effettiva, prendere in considerazione i dati inviati a bus di servizio (ingresso) e i dati ricevuti da bus di servizio (uscita).

Come previsto, la velocità effettiva è superiore per i payload di messaggi più piccoli che possono essere raggruppati in batch.

Benchmark

Ecco un esempio di GitHub che è possibile eseguire per visualizzare la velocità effettiva prevista ricevuta per lo spazio dei nomi bus di servizio. Nei test di benchmark sono stati osservati circa 4 MB al secondo per unità di messaggistica (MU) di ingresso e uscita.

L'esempio di benchmarking non usa funzionalità avanzate, quindi la velocità effettiva osservata dalle applicazioni è diversa, in base agli scenari in uso.

Considerazioni sulle risorse di calcolo

L'uso di determinate funzionalità di bus di servizio richiede un utilizzo di calcolo che può ridurre la velocità effettiva prevista. Alcune di queste funzionalità sono:

1. Sessioni.
2. Esecuzione di più sottoscrizioni in un singolo argomento.
3. Esecuzione di molti filtri in una singola sottoscrizione.
4. Messaggi pianificati.
5. Messaggi posticipati.
6. Transazioni.
7. Deduplicazione e intervallo di tempo indietro.
8. Inoltrare a (inoltro da un'entità a un'altra).

Se l'applicazione usa una delle funzionalità precedenti e non si riceve la velocità effettiva prevista, è possibile esaminare le metriche di utilizzo della CPU e valutare la possibilità di aumentare le prestazioni dello spazio dei nomi bus di servizio Premium.

È anche possibile usare Monitoraggio di Azure per ridimensionare automaticamente lo spazio dei nomi bus di servizio.

Partizionamento orizzontale tra spazi dei nomi

Anche se il ridimensionamento delle unità di calcolo (unità di messaggistica) allocato allo spazio dei nomi è una soluzione più semplice, potrebbe non fornire un aumento lineare della velocità effettiva. A causa di bus di servizio interni (archiviazione, rete e così via), che potrebbero limitare la velocità effettiva.

In questo caso, la soluzione più pulita consiste nel partizionare le entità (code e argomenti) in spazi dei nomi bus di servizio Premium diversi. È anche possibile prendere in considerazione il partizionamento orizzontale tra spazi dei nomi diversi in aree di Azure diverse.

Protocolli

Il bus di servizio consente ai client di inviare e ricevere messaggi tramite uno dei tre protocolli:

1. Advanced Message Queuing Protocol (AMQP)
2. Service Bus Messaging Protocol (SBMP)
3. Hypertext Transfer Protocol (HTTP)

AMQP è il più efficiente, perché mantiene la connessione a bus di servizio. Implementa anche l'invio in batch e il prelettura. Se non è indicato in modo esplicito, tutti i contenuti di questo articolo presuppongono l'uso di AMQP o SBMP.

Il 30 settembre 2026 verrà ritirato il supporto del protocollo SBMP per il bus di servizio di Azure, quindi non sarà più possibile usare questo protocollo dopo il 30 settembre 2026. Eseguire la migrazione alle librerie più recenti dell'SDK del bus di servizio di Azure usando il protocollo AMQP che offre aggiornamenti critici della sicurezza e funzionalità migliorate, prima di tale data.

Per altre informazioni, vedere l'annuncio del ritiro del supporto.

Scelta del bus di servizio .NET SDK appropriato

Il Azure.Messaging.ServiceBus pacchetto è la versione più recente bus di servizio di Azure .NET SDK disponibile a partire da novembre 2020. Esistono due SDK .NET meno recenti che continueranno a ricevere correzioni di bug critiche fino al 30 settembre 2026, ma è consigliabile usare l'SDK più recente. Leggere la guida alla migrazione per informazioni dettagliate su come passare dagli SDK meno recenti.

Per altre informazioni sul supporto minimo della piattaforma .NET Standard, vedere Supporto per l'implementazione di .NET.

Il 30 settembre 2026 verranno ritirate le librerie dell'SDK del bus di servizio di Azure WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus e com.microsoft.azure.servicebus, che non sono conformi alle linee guida di Azure SDK. Verrà terminato anche il supporto del protocollo SBMP, quindi non sarà più possibile usare questo protocollo dopo il 30 settembre 2026. Eseguire la migrazione alle librerie più recenti di Azure SDK, che offrono aggiornamenti critici della sicurezza e funzionalità migliorate, prima di tale data.

Anche se le librerie precedenti possono ancora essere usate oltre il 30 settembre 2026, non riceveranno più il supporto e gli aggiornamenti ufficiali da Microsoft. Per altre informazioni, vedere l'annuncio del ritiro del supporto.

Riutilizzo di factory e client

La nota seguente si applica a tutti gli SDK:

Operazioni simultanee

Le operazioni come invio, ricezione, eliminazione e così via richiedono del tempo. Questo tempo include il tempo impiegato dal servizio bus di servizio per elaborare l'operazione e la latenza della richiesta e della risposta. Per aumentare il numero di operazioni per volta, è necessario eseguire le operazioni contemporaneamente.

Il client pianifica le operazioni simultanee eseguendo operazioni asincrone . La richiesta successiva viene avviata prima del completamento della richiesta precedente. Il frammento di codice seguente è un esempio di operazione di invio in modalità asincrona:

var messageOne = new ServiceBusMessage(body);
var messageTwo = new ServiceBusMessage(body);

var sendFirstMessageTask =
    sender.SendMessageAsync(messageOne).ContinueWith(_ =>
    {
        Console.WriteLine("Sent message #1");
    });
var sendSecondMessageTask =
    sender.SendMessageAsync(messageTwo).ContinueWith(_ =>
    {
        Console.WriteLine("Sent message #2");
    });

await Task.WhenAll(sendFirstMessageTask, sendSecondMessageTask);
Console.WriteLine("All messages sent");

var messageOne = new Message(body);
var messageTwo = new Message(body);

var sendFirstMessageTask =
    queueClient.SendAsync(messageOne).ContinueWith(_ =>
    {
        Console.WriteLine("Sent message #1");
    });
var sendSecondMessageTask =
    queueClient.SendAsync(messageTwo).ContinueWith(_ =>
    {
        Console.WriteLine("Sent message #2");
    });

await Task.WhenAll(sendFirstMessageTask, sendSecondMessageTask);
Console.WriteLine("All messages sent");

Il codice seguente è un esempio di operazione di ricezione in modalità asincrona.

var client = new ServiceBusClient(connectionString);
var options = new ServiceBusProcessorOptions 
{

      AutoCompleteMessages = false,
      MaxConcurrentCalls = 20
};
await using ServiceBusProcessor processor = client.CreateProcessor(queueName,options);
processor.ProcessMessageAsync += MessageHandler;
processor.ProcessErrorAsync += ErrorHandler;

static Task ErrorHandler(ProcessErrorEventArgs args)
{
    Console.WriteLine(args.Exception);
    return Task.CompletedTask;
};

static async Task MessageHandler(ProcessMessageEventArgs args)
{
    Console.WriteLine("Handle message");
    await args.CompleteMessageAsync(args.Message);
}

await processor.StartProcessingAsync();

var receiver = new MessageReceiver(connectionString, queueName, ReceiveMode.PeekLock);

static Task LogErrorAsync(Exception exception)
{
    Console.WriteLine(exception);
    return Task.CompletedTask;
};

receiver.RegisterMessageHandler(
    async (message, cancellationToken) =>
    {
        Console.WriteLine("Handle message");
        await receiver.CompleteAsync(message.SystemProperties.LockToken);
    },
    new MessageHandlerOptions(e => LogErrorAsync(e.Exception))
    {
        AutoComplete = false,
        MaxConcurrentCalls = 20
    });

Modalità di ricezione

Quando si crea un client di coda o sottoscrizione, è possibile specificare una modalità di ricezione: PeekLock o ReceiveAndDelete. La modalità di ricezione predefinita è PeekLock. Quando si usa la modalità predefinita, il client invia una richiesta per ricevere un messaggio da bus di servizio. Una volta che il client ha ricevuto il messaggio, invia una richiesta per il completamento del messaggio.

Quando si imposta la modalità di ricezione su ReceiveAndDelete, entrambi i passaggi vengono combinati in una singola richiesta. Questi passaggi consentono di ridurre il numero complessivo di operazioni e di migliorare la velocità effettiva dei messaggi. Questo miglioramento delle prestazioni tuttavia comporta il rischio di perdere alcuni messaggi.

bus di servizio non supporta le transazioni per le operazioni di ricezione ed eliminazione. Inoltre, la semantica peek-lock è necessaria per tutti gli scenari in cui il client vuole rinviare o inviare un messaggio non recapitabili .

Prelettura

La prelettura consente al client della coda o della sottoscrizione di caricare messaggi aggiuntivi dal servizio quando riceve messaggi. Il client archivia i messaggi in una cache locale. Le dimensioni della cache sono determinate dalle ServiceBusReceiver.PrefetchCount proprietà. Ogni client che abilita la prelettura mantiene la propria cache. Una cache non viene condivisa tra i client. Se il client avvia un'operazione di ricezione e la relativa cache è vuota, il servizio trasmette un batch di messaggi. Se il client avvia un'operazione di ricezione e la cache contiene un messaggio, il messaggio viene prelevato dalla cache.

Quando un messaggio viene sottoposto a prelettura, il servizio lo blocca. Con il blocco, il messaggio prelettura non può essere ricevuto da un ricevitore diverso. Se il ricevitore non riesce a completare il messaggio prima della scadenza del blocco, il messaggio diventa disponibile per altri ricevitori. La copia del messaggio sottoposta a prelettura resta nella cache. Il ricevitore che utilizza la copia memorizzata nella cache scaduta riceve un'eccezione quando tenta di completare il messaggio. Per impostazione predefinita, il blocco del messaggio scade dopo 60 secondi. Questo valore può essere esteso a 5 minuti. Per evitare l'utilizzo di messaggi scaduti, impostare le dimensioni della cache inferiori al numero di messaggi che un client può utilizzare entro l'intervallo di timeout di blocco.

Quando si usa la scadenza del blocco predefinita di 60 secondi, un valore valido per PrefetchCount è 20 volte le frequenze di elaborazione massime di tutti i ricevitori della factory. Ad esempio, una factory crea tre ricevitori e ogni ricevitore può elaborare al massimo 10 messaggi al secondo. Il numero di prelettura non deve superare 20 X 3 X 10 = 600. Per impostazione predefinita, PrefetchCount è impostato su 0, il che significa che non vengono recuperati messaggi aggiuntivi dal servizio.

La prelettura dei messaggi comporta un aumento della velocità effettiva globale per una coda o una sottoscrizione perché riduce il numero complessivo di operazioni sui messaggi, o round trip. Il recupero del primo messaggio, tuttavia, richiede più tempo (a causa dell'aumento delle dimensioni del messaggio). La ricezione di messaggi prelettura dalla cache è più veloce perché questi messaggi sono già stati scaricati dal client.

La proprietà di durata (TTL) di un messaggio viene controllata dal server nel momento in cui invia il messaggio al client. Il client non controlla la proprietà TTL del messaggio quando viene ricevuto il messaggio. Al contrario, il messaggio può essere ricevuto anche se il TTL del messaggio è passato mentre il messaggio è stato memorizzato nella cache dal client.

La prelettura non influisce sul numero di operazioni di messaggistica fatturabili ed è disponibile solo per il protocollo client bus di servizio. Il protocollo HTTP non supporta il prelettura. Questa funzionalità è disponibile per le operazioni di ricezione sincrone e asincrone.

Prelettura e ReceiveMessagesAsync

Anche se i concetti di prelettura di più messaggi insieme hanno una semantica simile all'elaborazione dei messaggi in un batch (ReceiveMessagesAsync), esistono alcune piccole differenze da tenere presenti quando si usano questi approcci insieme.

Il prelettura è una configurazione (o modalità) in ServiceBusReceiver ed ReceiveMessagesAsync è un'operazione con semantica request-response.

Quando si usano questi approcci insieme, prendere in considerazione i casi seguenti:

• La prelettura deve essere maggiore o uguale al numero di messaggi che si prevede di ricevere da ReceiveMessagesAsync.
• La prelettura può essere fino a n/3 volte il numero di messaggi elaborati al secondo, dove n è la durata del blocco predefinita.

Esistono alcune sfide con un approccio greedy, ovvero mantenere elevato il numero di prelettura, perché implica che il messaggio è bloccato a un determinato ricevitore. È consigliabile provare i valori di prelettura compresi tra le soglie indicate in precedenza e identificare le caratteristiche più adatte.

Più code o argomenti

Se una singola coda o un singolo argomento non è in grado di gestire il numero previsto di messaggi, usare più entità di messaggistica. Se si usano più entità, è consigliabile creare un client dedicato per ogni entità invece di usare lo stesso client per tutte.

Più code o argomenti indicano che sono disponibili più entità da gestire in fase di distribuzione. Dal punto di vista della scalabilità, in realtà non c'è molta differenza che si noterebbe come bus di servizio già distribuito il carico tra più log internamente, quindi se si usano sei code o argomenti o due code o argomenti non farà una differenza sostanziale.

Il livello di servizio usato influisce sulla prevedibilità delle prestazioni. Se si sceglie il livello Standard , la velocità effettiva e la latenza sono il massimo sforzo per un'infrastruttura multi-tenant condivisa. Altri tenant nello stesso cluster possono influire sulla velocità effettiva. Se si sceglie Premium, si ottengono risorse che offrono prestazioni prevedibili e più code o argomenti vengono elaborati dal pool di risorse. Per altre informazioni, vedere i piani tariffari.

Spazi dei nomi partizionati

Quando si usano spazi dei nomi di livello Premium partizionati, più partizioni con unità di messaggistica inferiori offrono prestazioni migliori rispetto a una singola partizione con unità di messaggistica più elevate.

Scenari

Le sezioni seguenti descrivono scenari di messaggistica tipici e indicano le impostazioni preferibili del bus di servizio. La velocità effettiva è classificata come bassa (minore di 1 messaggio al secondo), moderata (maggiore o uguale a 1 messaggio al secondo ma minore di 100 messaggi al secondo) ed elevata (maggiore o uguale a 100 messaggi al secondo). Il numero di client è classificato come basso (minore o uguale a 5), moderato (maggiore di 5 ma minore o uguale a 20) ed elevato (maggiore di 20).

Coda ad alta velocità effettiva

Obiettivo: aumentare la velocità effettiva di una singola coda. Il numero di mittenti e ricevitori è limitato.

• Per aumentare la velocità di invio globale nella coda, usare più factory di messaggistica per la creazione di mittenti. Per ogni mittente usare operazioni asincrone o più thread.
• Per aumentare la velocità di ricezione globale dalla coda, usare più factory di messaggistica per la creazione di ricevitori.
• Usare operazioni asincrone per sfruttare i vantaggi dell'invio in batch sul lato client.
• Lasciare abilitato l'accesso in batch all'archivio. Questo accesso aumenta la velocità complessiva per la scrittura dei messaggi nella coda.
• Impostare il conteggio prelettura su un valore pari a 20 volte la velocità di elaborazione massima di tutti i ricevitori di una factory. Questo conteggio riduce il numero di trasmissioni tramite il protocollo client del bus di servizio.

Code multiple ad alta velocità effettiva

Obiettivo: aumentare la velocità effettiva complessiva di più code. La velocità effettiva di una singola coda è moderata o elevata.

Per ottenere la velocità effettiva massima su più code, usare le impostazioni descritte per aumentare la velocità effettiva di una singola coda. Usare anche factory diverse per creare client che inviano o ricevono da code diverse.

Coda a bassa latenza

Obiettivo: ridurre al minimo la latenza di una coda o di un argomento. Il numero di mittenti e ricevitori è limitato. La velocità effettiva della coda è ridotta o moderata.

• Disabilitare l'invio in batch sul lato client. Il client invia immediatamente un messaggio.
• Disabilitare l'accesso in batch all'archivio. Il servizio scrive immediatamente il messaggio nell'archivio.
• Se si usa un singolo client, impostare il conteggio prelettura su un valore pari a 20 volte la velocità di elaborazione del ricevitore. Se più messaggi arrivano nella coda allo stesso tempo, il protocollo client del bus di servizio li trasmette tutti contemporaneamente. Quando il client riceve il messaggio successivo, questo è già presente nella cache locale. La cache deve essere di dimensioni ridotte.
• Se si usano più client, impostare il conteggio prelettura su 0. Impostando il conteggio, il secondo client può ricevere il secondo messaggio mentre il primo client sta ancora elaborando il primo.

Coda con un numero elevato di mittenti

Obiettivo: aumentare la velocità effettiva di una coda o di un argomento con un numero elevato di mittenti. Ogni mittente invia messaggi con una velocità moderata. Il numero di ricevitori è limitato.

bus di servizio consente fino a 1.000 connessioni simultanee a un'entità di messaggistica. Questo limite viene applicato a livello di spazio dei nomi e le code, gli argomenti o le sottoscrizioni sono limitate dal limite di connessioni simultanee per spazio dei nomi. Per le code, questo numero è condiviso tra mittenti e ricevitori. Se per i mittenti sono necessarie tutte le 1.000 connessioni, sostituire la coda con un argomento e una singola sottoscrizione. Un argomento accetta fino a 1.000 connessioni simultanee dai mittenti. La sottoscrizione accetta 1.000 connessioni simultanee aggiuntive dai ricevitori. Se sono necessari più di 1.000 mittenti simultanei, i mittenti devono inviare messaggi al protocollo bus di servizio tramite HTTP.

Per ottimizzare la velocità effettiva, seguire questa procedura:

• Se ogni mittente si trova in un processo diverso, usare solo una singola factory per processo.
• Usare operazioni asincrone per sfruttare i vantaggi dell'invio in batch sul lato client.
• Lasciare abilitato l'accesso in batch all'archivio. Questo accesso aumenta la velocità complessiva per la scrittura dei messaggi nella coda o nell'argomento.
• Impostare il conteggio prelettura su un valore pari a 20 volte la velocità di elaborazione massima di tutti i ricevitori di una factory. Questo conteggio riduce il numero di trasmissioni tramite il protocollo client del bus di servizio.

Coda con un numero elevato di ricevitori

Obiettivo: aumentare la velocità di ricezione di una coda o di una sottoscrizione con un numero elevato di ricevitori. Ogni ricevitore riceve messaggi a una velocità moderata. Il numero di mittenti è limitato.

bus di servizio consente fino a 1.000 connessioni simultanee a un'entità. Se una coda richiede più di 1.000 ricevitori, sostituire la coda con un argomento e più sottoscrizioni. Ogni sottoscrizione può supportare fino a 1.000 connessioni simultanee. In alternativa, i ricevitori possono accedere alla coda tramite il protocollo HTTP.

Per ottimizzare la velocità effettiva, seguire queste linee guida:

• Se ogni ricevitore si trova in un processo diverso, usare solo una singola factory per processo.
• I ricevitori possono usare operazioni sincrone o asincrone. Data la frequenza di ricezione moderata di un singolo ricevitore, l'invio in batch lato client di una richiesta completa non influisce sulla velocità effettiva del ricevitore.
• Lasciare abilitato l'accesso in batch all'archivio. Questo accesso riduce il carico complessivo dell'entità. Aumenta anche la frequenza complessiva con cui è possibile scrivere i messaggi nella coda o nell'argomento.
• Impostare il conteggio prelettura su un valore ridotto, ad esempio PrefetchCount = 10. Questo conteggio evita che i ricevitori rimangano inattivi mentre per altri è presente un numero elevato di messaggi memorizzati nella cache.

Argomento con alcune sottoscrizioni

Obiettivo: ottimizzare la velocità effettiva di un argomento con alcune sottoscrizioni. Poiché un messaggio viene ricevuto da molte sottoscrizioni, la velocità di ricezione combinata su tutte le sottoscrizioni è superiore alla velocità di invio. Il numero di mittenti è limitato. Il numero di ricevitori per sottoscrizione è limitato.

Per ottimizzare la velocità effettiva, seguire queste linee guida:

• Per aumentare la velocità di invio globale nell'argomento, usare più factory di messaggistica per la creazione di mittenti. Per ogni mittente usare operazioni asincrone o più thread.
• Per aumentare la velocità di ricezione globale di una sottoscrizione, usare più factory di messaggistica per la creazione di ricevitori. Per ogni ricevitore usare operazioni asincrone o più thread.
• Usare operazioni asincrone per sfruttare i vantaggi dell'invio in batch sul lato client.
• Lasciare abilitato l'accesso in batch all'archivio. Questo accesso aumenta la velocità complessiva per la scrittura dei messaggi nell'argomento.
• Impostare il conteggio prelettura su un valore pari a 20 volte la velocità di elaborazione massima di tutti i ricevitori di una factory. Questo conteggio riduce il numero di trasmissioni tramite il protocollo client del bus di servizio.

Argomento con un numero elevato di sottoscrizioni

Obiettivo: aumentare la velocità effettiva di un argomento con un numero elevato di sottoscrizioni. Poiché un messaggio viene ricevuto da molte sottoscrizioni, la velocità di ricezione combinata su tutte le sottoscrizioni è superiore alla velocità di invio. Il numero di mittenti è limitato. Il numero di ricevitori per sottoscrizione è limitato.

Gli argomenti con un numero elevato di sottoscrizioni in genere espongono una velocità effettiva globale ridotta se tutti i messaggi vengono instradati a tutte le sottoscrizioni. Perché ogni messaggio viene ricevuto più volte e tutti i messaggi in un argomento e tutte le relative sottoscrizioni vengono archiviate nello stesso archivio. Il presupposto è che il numero di mittenti e il numero di ricevitori per sottoscrizione sia ridotto. Il bus di servizio supporta fino a 2.000 sottoscrizioni per argomento.

Per ottimizzare la velocità effettiva, procedere come segue:

• Usare operazioni asincrone per sfruttare i vantaggi dell'invio in batch sul lato client.
• Lasciare abilitato l'accesso in batch all'archivio. Questo accesso aumenta la velocità complessiva per la scrittura dei messaggi nell'argomento.
• Impostare il numero di prelettura su 20 volte la frequenza prevista con cui vengono ricevuti i messaggi. Questo conteggio riduce il numero di trasmissioni tramite il protocollo client del bus di servizio.