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 del 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 del bus di servizio o un client di argomenti che invia messaggi a una coda del bus di servizio o a un argomento. Il termine "ricevitore" si riferisce a un client della coda del bus di servizio o a un client di sottoscrizione che riceve messaggi da una coda del bus di servizio o da una sottoscrizione.
Pianificazione delle risorse e considerazioni
Come per qualsiasi resourcing tecnico, la pianificazione prudente è fondamentale per garantire che il bus di servizio di Azure fornisca le prestazioni previste dall'applicazione. La configurazione o la topologia corretta per gli spazi dei nomi del 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à del bus di servizio.
Piano tariffario
Il bus di servizio offre vari 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 sono non sensibili alla limitazione.
Livello premium: adatto per gli ambienti di produzione con requisiti di velocità effettiva diversi in cui è necessaria una latenza e una velocità effettiva prevedibili. Inoltre, gli spazi dei nomi Premium del bus di servizio possono essere ridimensionati automaticamente e possono essere abilitati per supportare picchi di velocità effettiva.
Nota
Se il livello corretto non è selezionato, esiste il rischio di sovraccaricare lo spazio dei nomi del bus di servizio che può causare limitazione delle richieste.
La limitazione delle richieste non comporta la perdita di dati. Le applicazioni che usano l'SDK del bus di servizio possono usare i criteri di ripetizione dei tentativi predefiniti per assicurarsi che i dati vengano eventualmente accettati dal bus di servizio.
Calcolo della velocità effettiva per Premium
I dati inviati al bus di servizio vengono serializzati in formato binario e quindi deserializzati quando vengono ricevuti dal ricevitore. Pertanto, mentre le applicazioni considerano messaggi come unità atomica di lavoro, il 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 al bus di servizio (in ingresso) e i dati ricevuti dal bus di servizio (in 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 del bus di servizio. Nei test di benchmark è stato osservato 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
Il bus di servizio gestisce diversi processi in background che possono influire sull'utilizzo del calcolo. Questi includono, ma non sono limitati a timer, pianificazioni e metriche di emissione. Inoltre, l'uso di determinate funzionalità del bus di servizio richiede un utilizzo di calcolo che può ridurre la velocità effettiva prevista. Alcune di queste funzionalità sono:
- Sessioni.
- Esecuzione di più sottoscrizioni in un singolo argomento.
- Esecuzione di molti filtri in una singola sottoscrizione.
- Messaggi pianificati.
- Messaggi rinviati.
- Transazioni.
- Deduplicazione e intervallo di tempo da controllare.
- 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 l'aumento dello spazio dei nomi Premium del bus di servizio. È anche possibile usare Monitoraggio di Azure per ridimensionare automaticamente lo spazio dei nomi del bus di servizio. È consigliabile aumentare il numero di unità messaggio (MU) quando l'utilizzo della CPU supera il 70% per garantire prestazioni ottimali.
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. È dovuto ai dati interni del bus di servizio (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 diversi spazi dei nomi Premium del bus di servizio. È 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:
- Advanced Message Queuing Protocol (AMQP)
- Service Bus Messaging Protocol (SBMP)
- Hypertext Transfer Protocol (HTTP)
AMQP è il più efficiente, perché mantiene la connessione al bus di servizio. Implementa anche le operazioni di invio in batch e prelettura. Se non è indicato in modo esplicito, tutti i contenuti di questo articolo presuppongono l'uso di AMQP o SBMP.
Importante
Il protocollo SBMP è disponibile solo per .NET Framework. AMQP è l'impostazione predefinita per .NET Standard.
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 dell'SDK .NET del bus di servizio appropriato
Il pacchetto Azure.Messaging.ServiceBus è l'SDK .NET del bus di servizio di Azure più recente 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. Per informazioni dettagliate su come passare dagli SDK precedenti, vedere la guida alla migrazione.
| Pacchetto NuGet | Spazi dei nomi primario | Piattaforme minime | Protocolli |
|---|---|---|---|
| Azure.Messaging.ServiceBus (ultima versione) | Azure.Messaging.ServiceBusAzure.Messaging.ServiceBus.Administration |
.NET Core 2.0 .NET Framework 4.6.1 Mono 5.4 Piattaforma UWP (Universal Windows Platform) 10.0.16299 |
AMQP HTTP |
| Microsoft.Azure.ServiceBus | Microsoft.Azure.ServiceBusMicrosoft.Azure.ServiceBus.Management |
.NET Core 2.0 .NET Framework 4.6.1 Mono 5.4 Piattaforma UWP (Universal Windows Platform) 10.0.16299 |
AMQP HTTP |
Per altre informazioni sul supporto minimo della piattaforma .NET Standard, vedere Supporto dell'implementazione .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
I client del bus di servizio che interagiscono con il servizio, ad esempio ServiceBusClient, ServiceBusSender, ServiceBusReceivere ServiceBusProcessor, devono essere registrati per l'inserimento delle dipendenze come singleton (o creare un'istanza una volta e condividere). ServiceBusClient (factory) può essere registrato per l'inserimento delle dipendenze con ServiceBusClientBuilderExtensions.
È consigliabile non chiudere o eliminare questi client dopo l'invio o la ricezione di ogni messaggio. La chiusura o l'eliminazione degli oggetti specifici dell'entità (ServiceBusSender/Receiver/Processor) comporta l'eliminazione del collegamento al servizio del bus di servizio. L'eliminazione di ServiceBusClient comporta l'eliminazione della connessione al servizio del bus di servizio.
Queste linee guida non si applicano a ServiceBusSessionReceiver, perché la durata della sessione è identica a quella della sessione stessa. Per le applicazioni che usano ServiceBusSessionReceiver, è consigliabile usare un'istanza singleton di ServiceBusClient per accettare ogni sessione, che si estende su un nuovo ServiceBusSessionReceiver associato a tale sessione. Al termine dell'elaborazione della sessione, l'applicazione deve eliminare il ServiceBusSessionReceiver associato.
La nota seguente si applica a tutti gli SDK:
Nota
Stabilire una nuova connessione è un'operazione costosa che si può evitare riutilizzando la stessa factory o gli stessi oggetti client per più operazioni. È possibile usare gli oggetti del client per operazioni asincrone simultanee e da più thread.
Operazioni simultanee
Le operazioni come invio, ricezione, eliminazione e così via richiedono del tempo. Questo tempo include il tempo impiegato dal servizio del 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");
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();
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 opera nella modalità predefinita, il client invia una richiesta per la ricezione di un messaggio dal 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 un'unica 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.
Il bus di servizio non supporta le transazioni per le operazioni receive-and-delete. Inoltre, la semantica peek-lock (blocco di visualizzazione) è necessaria per qualsiasi scenario in cui il client vuole posticipare l'invio di un messaggio o inserirlo nella coda dei messaggi non recapitabili.
Prelettura
La prelettura consente al client di coda o sottoscrizione di caricare messaggi aggiuntivi dal servizio quando riceve messaggi. Il client archivia i messaggi in una cache locale. La dimensione della cache è determinata dalle proprietà ServiceBusReceiver.PrefetchCount. 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 recuperato dalla cache.
Quando un messaggio viene sottoposto a prelettura, il servizio lo blocca. Con il blocco, il messaggio non potrà essere ricevuto da un ricevitore diverso. Se il ricevitore non può 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 usa la copia scaduta memorizzata nella cache riceve un'eccezione quando prova a 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.
Se si usa l'impostazione predefinita di 60 secondi per la scadenza del blocco, è consigliabile impostare per PrefetchCount un valore pari a 20 volte la velocità massima di elaborazione 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à di durata (TTL) del messaggio al momento della ricezione. Il messaggio può essere ricevuto anche se la relativa durata (TTL) scade durante la memorizzazione nella cache da parte del client.
La prelettura non influisce sul numero di operazioni di messaggistica fatturabili ed è disponibile solo per il protocollo client del bus di servizio. Il protocollo HTTP non supporta la prelettura. Questa funzionalità è disponibile per le operazioni di ricezione sincrone e asincrone.
Per altre informazioni, vedere le proprietà PrefetchCount seguenti:
È possibile impostare i valori per queste proprietà in ServiceBusReceiverOptions o ServiceBusProcessorOptions.
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 e ReceiveMessagesAsync è un'operazione (con semantica di richiesta-risposta).
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 interessato, 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 che il bus di servizio distribuisce già 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 da tale 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 (MU) offrono prestazioni migliori su una singola partizione con unità MU 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.
- 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. Inoltre, usare inoltre factory diverse per creare client che inviano o ricevono da code diverse.
Coda a bassa latenza
Obiettivo: ridurre la latenza di una coda o di un argomento. Il numero di mittenti e ricevitori è limitato. La velocità effettiva della coda è ridotta o moderata.
- 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.
Il bus di servizio consente un massimo di 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 in base al numero massimo di connessioni simultanee per spazio dei nomi. Per le code, questo numero è condiviso tra mittenti e ricevitori. Se sono necessarie tutte e 1.000 le connessioni per i mittenti, 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 i messaggi al protocollo del bus di servizio tramite HTTP.
Per ottimizzare la velocità effettiva, seguire questa procedura:
- Se ogni mittente è in un processo diverso, usare solo una singola factory per processo.
- 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.
Il bus di servizio consente un massimo di 1.000 connessioni simultanee a un'entità. Se una coda richiede più di 1.000 ricevitori, sostituirla 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 è in un processo diverso, usare solo una singola factory per processo.
- 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: aumentare 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.
- 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:
- 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.