Benefici di Mule 4 - Parte I

La versione 4 del runtime di Mule è ormai da due anni con noi. Questo anno, come abbiamo visto in un altro post sul Mule Migration Assistant, è l'anno chiave per migrare da Mule 3. Mule 4 è la migliore versione del runtime al momento con tanti miglioramenti rispetto alla versione precedente. Per quelli che ancora non sono convinti, in questa serie di posts vedremo le principali novità di Mule 4. In questo primo post vedremo i cambiamenti fatti sulla struttura dei eventi Mule, la gestione dei threads e le caratteristiche non-blocking e self-tuning di Mule 4.

Struttura dell’Evento Mule

La prima cosa che si è semplificata nella versione 4 è la struttura del messaggio Mule, ovvero l’evento Mule. Un’evento Mule è l’unita di informazione, sulla quale lavora il runtime. Ogni messaggio inviato ad una applicazione Mule, sia un messaggio di tipo HTTP, JMS, MQ che in qualsiasi altro protocollo o formato è convertito a questo formato di evento, e poi ogni trasformazione o ulteriore elaborazione si fa su questa struttura.
Questo evento di Mule serve come container di dati e metadati.

• Il payload contiene il body del messaggio, ad esempio, il record dal database, oppure il body di un post request di HTTP
• Gli attributes contengono i metadati di questo payload, ad esempio i query parameters di un get request HTTP
• L’ultima cosa che include l’evento Mule sono le variabili che possiamo definire nel contesto del nostro flusso o applicazione.

Mule 4 è non-blocking e self-tuning

Il nuovo motore di mule è self tuning e non-blocking. Vediamo che significa questo in dettaglio.
Una applicazione di mule è composta da uno o più flussi. Ogni flusso è l’insieme di una serie di event processors che prendono il messaggio o evento mule, fanno qualche trasformazione o elaborazione con quell’evento e poi lo consegnano al successivo event processor.
In ogni flusso c’è un Event source, che è quel componente che reagisce al trigger di quel flow, prendendosi i dati di ingresso e creando la struttura di messaggio o evento mule. Ad esempio, quando il trigger è una chiamata HTTP questo event source trasforma il contenuto di un messaggio HTTP. Si prende il body e lo mette nel payload o si prende i parametri HTTP e li mette negli attributi dell’evento Mule
Si chiama flusso proprio per quello, perchè l’evento o messaggio ricevuto scorre, fluisce attraverso tutti gli event processors.

 

Mule 4, è un runtime di tipo non-blocking. Non-blocking vuol dire che si incorpora un meccanismo di controllo di questo flusso. Questo meccanismo, chiamato di back pressure consente ad esempio ad un event processor di ridurre la velocità di ingresso di nuovi eventi. Quando il volume di eventi è troppo alto, l’event processor può inviare un segnale all’event processor precedente per ridurre la velocità e cosi evitare il collasso del flusso e di conseguenza della applicazione.

Dall’altra parte, self-tuning vuol dire che la gestione dei threads è automatica. La esecuzione di ogni event processor si fa nel contesto di un thread. Che succedeva con Mule 3? Mule 3 era un motore bloccante, quindi ad esempio quando arrivava una chiamata HTTP si assegnava un thread e quel thread rimaneva bloccato fino quando quel flusso finiva. Questo, quando piuttosto che una request abbiamo centinaia o miglaia di request è un problema, perchè significa che abbiamo praticamente il nostro runtime bloccato, fermo.
Questo ora, per fortuna è cambiato in Mule 4. Non tutto il flusso gira sullo stesso thread, il runtime consente di cambiare thread ad ogni step, ad ogni event processor. Questo però, attenzione, può essere sia un vantaggio che uno svantaggio.

• Cambiare di thread può essere un vantaggio quando le operazioni sono di tipo blocking, ovvero, operazioni che bloccano il thread di esecuzione senza fare nessun lavoro, solo aspettando la risposta di un’altro processo. Ad esempio quando facciamo una query su un database, il thread di questo event processor rimane la maggior parte del tempo aspettando la risposta del database senza fare un lavoro attivo. In questo caso, liberare il thread finquando abbiamo una risposta del database sarebbe un vantagio perche potremmo utilizzare quel thread per altri tasks.
• Dall’altra parte, cambiare di thread ad ogni step non è del tutto una buona idea. Il processo di liberare il thread momentaneamente e riprenderlo per finire il task di esecuzione implica aggiungere un sovraccarico per il nostro runtime.

Come possiamo trovare una via di mezzo? La strategia che propone Mule 4 è la creazione di thread pools, cioè gruppi di threads e raggrupparli in tre tipi di thread pools, in base al tipo di operazione da effettuare:

• Operazioni di tipo non-blocking: normalmente operazioni che si possono completare in meno di 10 ms
• Operazioni parzialmente bloccanti: sono operazioni che ci impiegano più di 10 ms però rimangono bloccate meno del 20% del tempo.
• Operazioni di tipo blocking: operazioni che chiaramente rimangono bloccate la maggior parte del tempo

 

In questo modo e di forma automatica il runtime fa un self tuning dinamico, cioè per ogni event processor, in base al tipo di operazione che fa quel event processor, sceglie di continuare con il thread esistente o di spostarsi da un’altro thread, e nel caso di spostarsi prendersi un thread del thread pool corrispondente al tipo di operazione.

Questa caratteristica è un grande vantaggio rispetto a Mule 3, perchè ora il runtime si adegua dinamicamente al tipo di workstream da eseguire e toglie la responsabilità di scegliere la strategia di processing allo sviluppatore, e sopratutto migliora notevolmente la performance del runtime.