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:
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:
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.
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.
I due esempi esempi mostrano quando potrebbe convenire suddividere un flusso di 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.
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.
Le seguenti proprietà controllano la frequenza con cui il flusso di messaggi esegue il commit delle transazioni: