Come progettare un adapter dalle prestazioni ottimali
Ai fini delle prestazioni è opportuno che tutti gli adapter supportino l'elaborazione batch, ovvero siano in grado di inviare batch di messaggi, di trasmettere batch e online di massima di eseguire operazioni in batch con i messaggi. È consigliabile che gli adapter espongano attributi modificabili relativi alle prestazioni, ad esempio le dimensioni dei batch o il numero dei byte di un batch, che sia possibile configurare nell'interfaccia utente dell'adapter disponibile in fase di progettazione.
Come indicato in precedenza, è necessario che gli adapter di trasmissione eseguano sempre trasmissioni non bloccanti per evitare la riduzione delle prestazioni dell'host di trasmissione. L'ulteriore blocco di API del motore di messaggistica non è consigliato.
La scrittura e la lettura del contesto del messaggio influenzano le prestazioni in fase di esecuzione. In generale è preferibile che gli adapter non leggano, scrivano e innalzino di livello un numero eccessivo di proprietà di contesto del messaggio. La promozione proprietà comporta infatti un'ulteriore riduzione delle prestazioni a causa della valutazione delle sottoscrizioni che si verifica per ogni proprietà innalzata di livello in fase di esecuzione. Perché le prestazioni vengano ridotte in modo rilevante è tuttavia necessario che venga innalzato il livello di un gran numero di proprietà. È buona norma, in ogni caso, innalzare di livello solo le proprietà per le quali tale operazione è realmente necessaria.
Limitazione delle richieste di trasmissione e ricezione
Quando il carico che grava sul motore BizTalk supera la soglia configurata, viene imposta una limitazione delle richieste ad adapter e orchestrazioni per garantire prestazioni ottimali. Sul lato ricezione, quando il carico di lavoro nel motore supera una determinata soglia, la chiamata dell'adattatore a IBTTransportBatch.Done viene bloccata fino a quando il carico non è diminuito sufficientemente. In tal modo l'invio di nuovo lavoro dall'adapter al motore riprende solo quando quest'ultimo è disponibile. Relativamente alla trasmissione, quando viene imposta una limitazione delle richieste agli adapter che inviano messaggi in uscita, il motore recapita nuovi messaggi da trasmettere solo quando il carico si è ridotto.
Per questi motivi non è necessario che l'adapter sia interessato dalla limitazione delle richieste a meno che non sia opportuno, ad esempio, limitare il numero di connessioni a un sistema back-end. Per scenari di questo tipo, né il motore né Adapter Framework forniscono supporto.
La possibilità di gestire la limitazione del numero di messaggi provenienti da un adapter di trasmissione personalizzato varia a seconda del controllo esercitato sul codice sorgente dell'adapter.
Miglioramento delle prestazioni determinato dalla limitazione delle richieste di trasmissione
Se si controlla il codice sorgente dell'adapter, è possibile determinare con sistemi euristici il numero massimo di messaggi desiderato nella coda di trasmissione in un momento qualsiasi. Quando il motore di messaggistica chiama il TransmitMessage metodo e passa l'adattatore di invio a un nuovo messaggio, è possibile scegliere di bloccare il thread o verificare se il numero di messaggi nella coda è maggiore del valore massimo determinato in precedenza. Se il numero massimo di messaggi è stato superato, è possibile usare il Resubmit metodo per inviare nuovamente il messaggio al motore di messaggistica. Si noti che, se l'adapter è di tipo sincrono, il messaggio sarebbe già bloccato.
Se non si controlla il codice sorgente per l'adapter, è possibile modificare il numero di messaggi in coda modificando il valore Highwatermark nella tabella Adm_serviceclass nel database di Gestione BizTalk. Il valore massimo per la proprietà Highwatermark è 200. È anche possibile modificare il valore per la proprietà Lowwatermark in un valore più piccolo.
Tenere presente che il valore della proprietà Highwatermark per gli adattatori asincroni account per il numero di messaggi che il motore di messaggistica ha assegnato all'adattatore. Il motore di messaggistica li passa all'adattatore tramite il TransmitMessage metodo, questi messaggi possono essere ancora in sospeso nella trasmissione, ad esempio se l'adapter non ha effettuato una chiamata corrispondente al DeleteMessagemetodo , ResubmitMoveToNextTransporto Microsoft.BizTalk.TransportProxy.Interop.BatchOperationType.MoveToSuspendQ. Per gli adattatori sincroni, la proprietà Highwatermark account solo il numero di messaggi che il motore di messaggistica ha passato all'adapter usando il metodo TransmitMessage perché questa chiamata elabora in modo sincrono, bloccando il thread del motore di messaggistica chiamante.
Se si scrive un adapter di trasmissione per un protocollo intrinsecamente lento, ad esempio HTTP, FTP o SOAP bidirezionale, tenere presente quanto segue:
Tale adapter potrebbe ricevere messaggi dal motore di messaggistica BizTalk più velocemente della propria capacità di trasmetterli. Questa discrepanza provoca problemi a vari livelli. I messaggi da trasmettere restano in memoria occupando memoria virtuale e rallentando l'intero sistema.
L'adapter potrebbe assorbire risorse specifiche di protocollo. Potrebbe ad esempio aprire troppe connessioni contemporanee con il server, compromettendo le prestazioni del server remoto.
L'adapter potrebbe influire su altri adapter. Se ad esempio vengono accodati troppi messaggi per un adapter in particolare, il motore di messaggistica non emette più richieste ad altri adapter di trasmissione dello stesso processo.
Una possibile soluzione consiste nell'inserire adapter lenti e veloci in host BizTalk separati e di controllare il numero di messaggi utilizzando le impostazioni relative al numero massimo e al numero minimo.
Miglioramento delle prestazioni determinato dalla limitazione delle richieste di ricezione
Vi sono varie situazioni in cui un adapter di ricezione riceve i messaggi più velocemente rispetto alla velocità con cui vengono elaborati nel resto del sistema. In tali casi si verifica il backlog nel database MessageBox e le prestazioni dell'intero sistema peggiorano sensibilmente.
Se si verifica questa situazione, è possibile ricorrere a una delle tecniche seguenti per ridurre la velocità dell'adapter di ricezione:
Ridurre le dimensioni del pool di thread utilizzato nel motore di messaggistica. È possibile controllare il numero di thread utilizzato nel motore di messaggistica per pubblicare messaggi nel MessageBox. Con la riduzione del numero di thread si riduce la velocità con cui l'adapter di ricezione riceve i messaggi nel MessageBox. Questa impostazione è necessaria solo per l'host corrispondente al gestore di ricezione relativo all'adapter. È consigliabile ridurre il numero di thread per l'host corrispondente al gestore di trasmissione relativo all'adapter solo se si desidera rallentare anche l'adapter di trasmissione.
Ridurre la dimensione del batch dell'adapter. Molti adapter di ricezione veloci pubblicano i messaggi nel MessageBox in batch. La dimensione dei batch è solitamente configurabile nella pagina delle proprietà dell'indirizzo di ricezione. Se si diminuisce la dimensione del batch, è possibile diminuire la velocità effettiva globale dei messaggi in arrivo nel sistema.
Modificare altre impostazioni specifiche per adapter. Terminati i due passaggi precedenti, è possibile provare a regolare altri parametri dell'adapter per diminuire ulteriormente la velocità effettiva. Alcuni adapter espongono parametri interni che consentono di diminuire la velocità effettiva. L'adapter MQSeries, ad esempio, presenta l'impostazione per il "recapito ordinato" in base alla quale l'adapter pubblica un batch di messaggi, ne attende il completamento e passa a pubblicare il batch successivo. L'attivazione di questa impostazione consente in sostanza di rimuovere il parallelismo dall'adapter di ricezione. Viceversa, regolando i parametri nel senso opposto è possibile aumentare la velocità di un adapter di ricezione.
Un adapter è in grado di inviare il numero di batch necessario al proxy di trasporto. Quando il sistema è fortemente stressato, una chiamata al metodo Done dell'interfaccia IBTTransportBatch blocca il messaggio fino a quando non vengono rilasciate le risorse necessarie al sistema.
Pianificazione di ricezione e trasmissione asincrone
Nelle API di messaggistica di BizTalk Server è disponibile il supporto completo per la programmazione asincrona. Se si desidera scrivere un adapter scalabile, prendere in considerazione l'utilizzo del modello asincrono sin dall'inizio poiché la concorrenza fornita è migliore.
Sul lato ricezione, quando un adattatore invia un batch di messaggi al motore di messaggistica BizTalk (chiamando IBTTransportBatch::D one), il motore di messaggistica accoda il lavoro usando il pool di thread interno e restituisce immediatamente. Il motore elabora i messaggi in un thread separato, lasciando l'adapter libero di leggere altri messaggi dall'origine e di inviarli senza attendere il completamento dell'elaborazione del messaggio precedente.
Relativamente alla trasmissione, l'adapter può essere asincrono o sincrono. Se tuttavia il protocollo utilizzato supporta le operazioni asincrone, è consigliabile servirsi di tale supporto per scrivere un adapter scalabile. Gli adapter di trasmissione File e HTTP, ad esempio, sono completamente asincroni ed eseguono pochissime operazioni bloccanti/sincrone.
Le operazioni asincrone consentono al motore di messaggistica e all'adapter di continuare a eseguire il rispettivo lavoro parallelamente senza attendere che l'altra parte termini la normale elaborazione dei messaggi.
Utilizzo dei batch per migliorare le prestazioni
La creazione di batch è il punto di partenza migliore per scrivere un adapter scalabile, tanto per adapter di trasmissione quanto per adapter di ricezione. Ogni batch è soggetto a una transazione di database in BizTalk Server anche se l'adapter utilizzato non è transazionale. Poiché a ogni transazione è associato un periodo di tempo determinato, è consigliabile cercare di ridurre al minimo il numero di transazioni riunendo più operazioni in un unico batch.
Esaurimento delle risorse del pool di thread .NET
La scrittura di adapter BizTalk è un buon esercizio di scrittura di codice .NET della fase di esecuzione, codice che a sua volta equivale indubbiamente a un esercizio di programmazione asincrona.
L'esaurimento del pool di thread .NET è un rischio della programmazione asincrona in .NET ed è particolarmente importante che venga evitato dal programmatore di adapter BizTalk.
Il pool di thread .NET è una risorsa limitata ma ampiamente condivisa. È facile che si scriva codice che utilizza uno dei thread del pool di thread .NET e lo trattenga a lungo, bloccando l'esecuzione di altro lavoro.
Ogni volta che si usa BeginInvoke o si usa un timer, si usa un thread del pool di thread .NET. Se si hanno più parti di lavoro da eseguire (ad esempio copiando i messaggi fuori da MQSeries in BizTalk Server), è necessario eseguire un elemento di lavoro (un batch di messaggi in BizTalk Server) e quindi ripetere la sequenza nel pool di thread se è necessario eseguire più operazioni. Non sedersi mai in un while ciclo sul thread.
In termini concreti ciò significa sostituire while i cicli con chiamate ripetute a BeginInvoke. Questa semplice modifica è in grado di migliorare notevolmente la capacità di risposta e la scalabilità orizzontale dell'intera implementazione.
Scelta del valore corretto per la limitazione della dimensione del batch
Se si inviano i messaggi a BizTalk Server in batch, non limitare la dimensione dei batch solo sulla base del numero dei messaggi. Si consideri cosa accade quando un adattatore è stato configurato in batch solo in base al conteggio dei messaggi: se le dimensioni del batch sono due e l'adattatore ottiene quattro messaggi di dimensione 4 KB, 8 KB, 1 MB e 5 MB rispettivamente, il primo batch sarà di dimensioni 12 KB e il secondo batch sarà di dimensioni pari a 6 MB.
Poiché il motore di messaggistica BizTalk elabora in sequenza tutti i messaggi contenuti in un batch, il secondo batch dell'esempio verrà elaborato molto più lentamente del primo. La velocità effettiva risulta in tal modo ridotta. Una soluzione migliore consiste nel creare batch in base tanto al numero dei messaggi quanto ai byte totali, ovvero dimensione del batch in byte. Non esiste il numero perfetto di byte totali. In condizioni di elaborazione normali, tuttavia, se la dimensione del batch supera 1 MB, si potranno notare i primi segni di concorrenza e velocità effettiva mediocri.
Solitamente gli adapter sono "agnostici" rispetto ai messaggi, ovvero non sono a conoscenza della dimensione dei messaggi nell'ambiente di produzione. La dimensione dei messaggi in ingresso può variare notevolmente. Per tali motivi è consigliabile utilizzare sia il numero dei messaggi quanto i byte totali nella creazione dei batch.