Ottimizzazione della velocità di trsmissione del flusso di messaggi

Ogni flusso di messaggi progettato deve fornire una serie completa di elaborazioni per i messaggi ricevuti da una certa origine. Questo, tuttavia, può portare a flussi di messaggi molto complessi che includono un numero elevato di nodi e causano un rallentamento delle prestazioni e potenziali colli di bottiglia. Aumentando il numero di flussi di messaggi che elaborano i messaggi si offre l'opportunità di un'elaborazione parallela e quindi una maggior velocità.

Si può anche considerare la modalità di commit delle azioni intraprese dal flusso di messaggi e l'ordine in cui i messaggi vengono elaborati.

Considerare le seguenti opzioni per l'ottimizzazione della velocità di trasmissione del flusso di messaggi:

Più thread che elaborano messaggi in un singolo flusso di messaggi
Quando si distribuisce un flusso di messaggi, il broker avvia automaticamente un'istanza del flusso di messaggi per ogni nodo di input in esso contenuto. Questo è il funzionamento predefinito. Tuttavia, se si ha un flusso di messaggi che gestisce un numero molto elevato di messaggi, l'origine input (ad esempio, una coda WebSphere MQ) può diventare un collo di bottiglia.

E' possibile aggiornare, nel file bar, la proprietà Istanze aggiuntive del flusso di messaggi distribuito: il broker avvia copie aggiuntive del flusso di messaggi su thread separati, fornendo un'elaborazione parallela. Questo è il metodo più efficace per gestire questa situazione, se l'ordine in cui i messaggi vengono elaborati non è rilevante.

Se il flusso di messaggi riceve messaggi da una coda WebSphere MQ, è possibile influenzare in parte l'ordine in cui i messaggi vengono elaborati impostando la proprietà Modalità ordine del nodo MQInput:

  • Se si imposta Modalità ordine su Per ID utente, il nodo assicura che i messaggi provenienti da un utente specifico (identificato dal campo UserIdentifier in MQMD) sono elaborati in un ordine garantito. Un secondo messaggio da un utente non è elaborato da un'istanza del flusso di messaggi se un messaggio precedente da questo utente viene attualmente elaborato da un'altra istanza del flusso di messaggi.
  • Se si imposta Modalità ordine su Per ordine coda, il nodo elabora un messaggio alla volta per conservare l'ordine in cui i messaggi vengono letti dalla coda. Questo nodo, quindi, si comporta come se la proprietà Istanze aggiuntive del flusso di messaggi fosse impostata su zero.

Per le applicazioni pubblicazione/sottoscrizione che comunicano con il broker su qualsiasi protocollo supportato, i messaggi per qualsiasi argomento sono pubblicati dai broker nello stesso ordine in cui vengono ricevuti dagli autori (publisher) (soggetti a riordino in base alla priorità del messaggio, se applicabile). Questo significa in genere che ogni sottoscrittore riceve messaggi da un particolare broker, su un particolare argomento, da un autore particolare, nell'ordine in cui vengono pubblicati da quell'autore.

Tuttavia, a volte, è possibile che i messaggi vengano consegnati senza rispettare l'ordine. Questo può verificarsi, ad esempio, se un link nella rete ha esito negativo e i messaggi successivi vengono instradati da un altro link.

Se è necessario garantire l'ordine in cui si ricevono i messaggi, è possibile utilizzare il parametro SeqNum (numero sequenza) o PubTime (data/ora pubblicazione) sul comando Publish per ogni messaggio pubblicato, per calcolare l'ordine di pubblicazione.

Per ulteriori informazioni sulle tecniche consigliate per tutti gli utenti MQI e AMI, consultare il manuale WebSphere MQ Application Programming Guide per i programmi scritti nell'MQI, e WebSphere MQ Application Messaging Interface (disponibile come SupportPac MA0F dalla pagina Web dei SupportPac di WebSphere MQ) per i programmi scritti nell'AMI.

Le applicazioni WebSphere MQ Everyplace e SCADA utilizzano un metodo di ordinamento dei messaggi differente, come descritto rispettivamente in WebSphere MQ Mobile Transport e WebSphere MQ Telemetry Transport. Il broker non fornisce l'ordinamento dei messaggi ricevuti su WebSphere MQ Web Services Transport, WebSphere MQ Real-time Transport o WebSphere MQ Multicast Transport.

Più copie del flusso di messaggi in un broker
E' possibile distribuire anche diverse copie dello stesso flusso di messaggi a gruppi di esecuzione differenti nello stesso broker. Questo ha un effetto simile all'aumento del numero di thread di elaborazione in un singolo flusso di messaggi, sebbene in genere fornisca dei vantaggi meno evidenti.

Questa opzione inoltre rimuove la capacità di stabilire l'ordine in cui vengono elaborati i messaggi. Questo perché, se esiste più di una copia del flusso di messaggi attiva nel broker, ogni copia può elaborare un messaggio contemporaneamente, dalla stessa coda. Il tempo impiegato per elaborare un messaggio può variare e quindi più flussi di messaggi che accedono alla stessa coda potrebbero leggere i messaggi dall'origine input in ordine casuale. L'ordine dei messaggi prodotto dai flussi di messaggi potrebbe non corrispondere all'ordine dei messaggi originali.

Accertarsi che le applicazioni che ricevono un messaggio da questi flussi di messaggi possano tollerare messaggi che non rispettano l'ordine.

Copie del flusso di messaggi in più broker
E' possibile distribuire diverse copie dello stesso flusso di messaggi a broker differenti. Questa soluzione richiede delle modifiche alla configurazione, perché ci si deve assicurare che le applicazioni che forniscono messaggi al flusso di messaggi possano inserire i messaggi sulla porta o coda di input giusta. Spesso è possibile effettuare queste modifiche quando si distribuisce il flusso di messaggi, impostando le proprietà del flusso di messaggi che si possono configurare.
Ambito del flusso di messaggi
In alcune circostanze, potrebbe essere possibile suddividere un singolo flusso di messaggi in molti flussi diversi per ridurre l'ambito del lavoro svolto da ogni flusso di messaggi. Così facendo, tenere presente che non è possibile eseguire flussi di messaggi separati nella stessa unità di lavoro e, se esistono aspetti transazionali per il flusso di messaggi (ad esempio, l'aggiornamento di più database), questa opzione non rappresenta una soluzione adatta.

I due esempi esempi mostrano quando potrebbe convenire suddividere un flusso di messaggi:

  1. In un flusso di messaggi che utilizza RouteToLabel, la coda di input è diventata un collo di bottiglia. Si potrebbe utilizzare una copia del flusso di messaggi in un secondo gruppo di esecuzione, ma non sarebbe appropriato se si desidera che tutti i messaggi siano gestiti nell'ordine in cui compaiono nella coda. Si potrebbe allora considerare la divisione di ogni ramo del flusso di messaggi che inizia con un nodo Label fornendo una coda di input e un nodo di input per ogni ramo. Questa soluzione potrebbe essere appropriata, poiché quando il messaggio viene instradato dal nodo RouteToLabel al relativo nodo Label, dispone di un certo grado di indipendenza da tutti gli altri messaggi.

    Potrebbe essere necessario anche fornire un'altra coda e un altro nodo di input per completare qualsiasi elaborazione comune, a cui i rami di Label si connettono quando viene effettuata un'elaborazione univoca.

  2. Se si dispone di un flusso di messaggi che elabora messaggi di dimensioni molto grandi, che richiedono molto tempo per essere elaborati, si potrebbe:
    1. Creare altre copie del flusso di messaggi che utilizzano una coda di input diversa (si può impostare questa coda nel flusso di messaggi stesso o si può aggiornare questa proprietà quando si distribuisce il flusso di messaggi).
    2. Impostare gli alias della coda WebSphere MQ per reindirizzare i messaggi da alcune applicazioni alla coda e al flusso di messaggi alternativi.

    E' possibile anche creare un nuovo flusso di messaggi che replica la funzione del flusso di messaggi originale (ma elabora solo messaggi di grandi dimensioni che gli vengono immediatamente trasmessi dal flusso di messaggi originale), che era stato modificato per verificare le dimensioni del messaggio di input e reindirizzare i messaggi di grandi dimensioni.

Frequenza dei commit
Se un flusso di messaggi riceve messaggi di input in una coda WebSphere MQ, è possibile migliorarne la velocità di trasmissione per alcuni scenari del flusso di messaggi modificandone le proprietà predefinite dopo che è stato aggiunto ad un file bar. (Queste opzioni non sono disponibili se i messaggi di input sono ricevuti da altri nodi input; in tali flussi di messaggi i commit vengono eseguiti per ogni messaggio.)

Le seguenti proprietà controllano la frequenza con cui il flusso di messaggi esegue il commit delle transazioni:

  • Numero di commit. Rappresenta il numero di messaggi elaborati dalla coda input prima dell'emissione di MQCMIT.
  • Intervallo di commit. Rappresenta l'intervallo di tempo che intercorre prima del richiamo di MQCMIT.
Concetti correlati
Panoramica dei flussi di messaggi
Panoramica della distribuzione
Attività correlate
Ottimizzazione dei tempi di riposta del flusso di messaggi
Creazione di un flusso di messaggi
Definizione del contenuto del flusso di messaggi
Modifica delle proprietà configurabili
Riferimenti correlati
Nodi integrati
Proprietà del flusso di messaggi configurabili
Informazioni particolari | Marchi | Download | Libreria | Supporto | Commenti
Copyright IBM Corporation 1999, 2006 Ultimo aggiornamento: ago 17, 2006
ac00350_