Identificazione dei colli di bottiglia nel livello BizTalk

Il livello BizTalk può essere suddiviso nelle aree funzionali seguenti:

• Ricezione

• Elaborazione

• Trasmissione

• Rilevamento

• Altro

  Relativamente a queste aree, se le risorse di sistema (CPU, memoria e disco) risultano sature, aggiornare il server mediante la scalabilità verticale. Se le risorse di sistema non sono sature, eseguire le procedure descritte in questa sezione.

Colli di bottiglia nell'indirizzo di ricezione

Se il numero di messaggi nell'indirizzo di ricezione inizia ad aumentare (ad esempio nel caso in cui le dimensioni della cartella di ricezione dei file diventano eccessive o la coda dei messaggi in uscita non viene svuotata in modo sufficientemente veloce), significa che il sistema non è in grado di assorbire i dati a una velocità sufficiente a soddisfare il carico in ingresso a causa della limitazione delle richieste interne (BizTalk riduce la velocità di ricezione se i sottoscrittori non sono in grado di elaborare i dati in modo sufficientemente veloce, causando un backlog nelle tabelle del database). Se il collo di bottiglia è dovuto a limitazioni hardware, provare a eseguire la scalabilità verticale. È inoltre possibile eseguire la scalabilità orizzontale aggiungendo un'istanza host (server) all'host mappato al gestore di ricezione. Utilizzare Perfmon per monitorare l'utilizzo delle risorse nel sistema. È importante verificare che l'indirizzo di ricezione esterno non sia la causa del collo di bottiglia. Verificare, ad esempio, se la condivisione di file remota è satura a causa di un numero elevato di operazioni di I/O su disco o che il server che ospita la coda in uscita remota non sia saturo o che il client utilizzato per generare il carico HTTP/SOAP non richieda ulteriori thread.

Colli di bottiglia nell'elaborazione

Se il valore di Coda host - Lunghezza (vedere il contatore Perfmon nella tabella riportata sotto) aumenta progressivamente, significa che le orchestrazioni non vengono completate in modo sufficientemente veloce. Questa condizione può dipendere da memoria insufficiente o dalla saturazione della CPU.

Se il collo di bottiglia è rappresentato dai server di orchestrazione, utilizzare Perfmon per identificare l'origine.

Se il server è CPU bound, considerare quanto segue:

• Se il flusso di lavoro è complesso, provare a dividere l'orchestrazione in più orchestrazioni di dimensioni inferiori.

  Nota

  La divisione di un'orchestrazione in più flussi di lavoro può causare un'ulteriore latenza e aumentare la complessità.

• Se si utilizzano mappe complesse, valutare se sia possibile rimuoverle dalle porte di ricezione/trasmissione (verificare quali porte hanno una larghezza di banda aggiuntiva).

• Provare a eseguire la scalabilità verticale dell'hardware o, se possibile, la scalabilità orizzontale configurando un server di elaborazione aggiuntivo.

Colli di bottiglia nella trasmissione

Se le risorse del server di trasmissione (disco, memoria o CPU) sono sature, provare a eseguire la scalabilità verticale del server o, se possibile, la scalabilità orizzontale aggiungendo ulteriori server host di trasmissione. Il livello di trasmissione può diventare il collo di bottiglia se la destinazione (esterna a BizTalk) non è in grado di ricevere i dati in modo sufficientemente veloce. Ciò causerà l'aumento dei messaggi nel database MessageBox (coda SendHostQ dell'applicazione).

Se tutti gli endpoint si trovano entro l'ambito della topologia, provare a isolare la causa nella destinazione. Verificare, ad esempio, se l'indirizzo HTTP/SOAP è configurato in modo ottimale per la ricezione di carico o se potrebbe invece essere scalato orizzontalmente. Verificare se l'aumento delle dimensioni della destinazione è dovuto a un numero eccessivo di messaggi di output consegnati da BizTalk. In caso affermativo, provare ad attuare un piano di manutenzione per archiviare ed eliminare i messaggi nella destinazione. Un numero elevato di file in una cartella di destinazione, ad esempio, può compromettere la capacità del servizio BizTalk di eseguire il commit dei dati nell'unità disco.

Colli di bottiglia nel rilevamento

L'istanza dell'host di rilevamento è responsabile dello spostamento dei dati relativi alle istanze del servizio e agli eventi messaggio rilevati e BAM dal database MessageBox (tabella TrackingData) al database BizTalkDTADb e/o alle tabelle del database BAMPrimaryImport. Se sono configurati più database MessageBox, l'istanza host di rilevamento utilizza quattro thread per ogni database MessageBox.

È possibile che questa istanza host ottenga un processo CPU bound. In tal caso, provare a scalare verticalmente o orizzontalmente il server configurando un server aggiuntivo con il rilevamento host attivato. Le varie istanze host bilanceranno automaticamente il carico per i vari database MessageBox configurati.

Se la tabella TrackingData nel database MessageBox comincia a essere sottoposta a backup, ciò dipende in genere dal fatto che i processi di manutenzione dei dati nei database BizTalkDTADb e/o BAMPrimaryImport non vengono eseguiti come previsto, causando così la crescita delle dimensioni di uno o entrambi questi database. Se le dimensioni del database crescono eccessivamente, ciò può avere un impatto negativo sulla capacità dell'host di rilevamento di inserire i dati in queste tabelle, causando il backup dei dati rilevati nelle tabelle del database MessageBox. La crescita della tabella MessageBox-TrackingData> causerà la limitazione dell'avvio.

Altro

Configurare la topologia di distribuzione in modo tale che funzionalità differenti vengano eseguite in istanze host isolate dedicate. In questo modo ogni istanza host ottiene il proprio set di risorse (in un sistema a 32 bit, 2GB di spazio degli indirizzi di memoria virtuale, handle, thread). Se il server è sufficientemente potente (spazio CPU disponibile e memoria sufficienti) per ospitare più istanze host, queste possono essere configurate tutte per l'esecuzione nello stesso computer fisico. In caso contrario, sarà più facile eseguire la scalabilità orizzontale spostando le funzionalità su server dedicati. L'esecuzione delle stesse funzionalità su più server consente inoltre di fornire una configurazione a elevata disponibilità.

Contatori delle prestazioni di sistema BizTalk

Conflitto CPU

Se il processore è saturo, provare a frammentare l'applicazione separando la ricezione dalla trasmissione e dall'orchestrazione. A tale scopo, creare host separati, eseguendone il mapping a funzionalità specifiche (Ricezione/Trasmissione /Orchestrazioni/Rilevamento) e aggiungendovi server dedicati. Le funzionalità di orchestrazione richiedono in genere un utilizzo intensivo della CPU. Di conseguenza, la configurazione del sistema che prevede l'esecuzione delle orchestrazioni in un server dedicato contribuisce a migliorare la velocità effettiva del sistema.

Se vengono distribuite più orchestrazioni, è possibile integrarle in differenti host di orchestrazione dedicati. Il mapping di server fisici differenti agli host di orchestrazione dedicati garantisce che le diverse orchestrazioni siano isolate e non entrino in conflitto per le risorse condivise nello stesso spazio di indirizzi fisici o nello stesso server.

Mancanza di memoria

Gli scenari caratterizzati da una velocità effettiva elevata possono richiedere una maggiore quantità di memoria di sistema. Poiché un processo a 32 bit è limitato dalla quantità di memoria che può consumare, è consigliabile separare le funzionalità di ricezione, elaborazione e trasmissione in più istanze host in modo tale che ogni host riceva 2GB di spazio degli indirizzi. Inoltre, se più istanze host vengono eseguite nello stesso server fisico, può essere utile eseguire l'aggiornamento a 4/8GB di memoria per evitare lo scambio dei dati su disco dalla memoria reale. Le orchestrazioni a esecuzione prolungata possono contenere la memoria allocata più a lungo causando il bloat della memoria e quindi la limitazione dell'avvio. I messaggi di grandi dimensioni possono anche causare un consumo elevato di memoria.

È possibile superare questo problema di perdita di memoria quando vengono elaborati messaggi di grandi dimensioni riducendo le dimensioni della coda di messaggi interni e i messaggi in-process per ogni valore della CPU per l'host specifico.

Conflitto di dischi

Se i dischi sono saturi (ad esempio, i trasporti File/MSMQ) considerano l'aggiornamento a più spindles e striping dei dischi con RAID 1+0. Inoltre, ogni volta che si utilizza il trasporto FILE, è importante assicurarsi che le cartelle (ricezione e invio) non siano troppo grandi (>50.000 file).

La cartella di ricezione può raggiungere dimensioni elevate se BizTalk Server sceglie di limitare le richieste di dati in ingresso nel sistema per vari motivi descritti più avanti. È inoltre importante spostare i dati dalla cartella di trasmissione in modo tale che la crescita di questa cartella non influisca sulla capacità di BizTalk Server di scrivere ulteriori dati. Per le code MSMQ non transazionali, è consigliabile creare le code di ricezione in modalità remota per ridurre il conflitto di dischi nel server BizTalk.

La configurazione (code non transazionali remote) consente inoltre una disponibilità elevata in quanto il server remoto che ospita la coda può essere inserito in un cluster.

Conflitti di altre risorse di sistema

A seconda della natura del trasporto configurato, può essere necessario configurare le risorse di sistema come IIS per HTTP/SOAP (ad esempio, MaxIOThreads, MaxWorkerThreads).

Colli di bottiglia downstream

Se il sistema downstream non è in grado di ricevere dati da BizTalk a una velocità adeguata, questi dati di output verranno sottoposti a backup nei database BizTalk, determinando una crescita della memoria, impedendo la limitazione delle richieste, causando la riduzione della pipeline di ricezione e influendo quindi negativamente sulla velocità effettiva complessiva del sistema BizTalk. Una chiara indicazione di questo problema è la crescita dello spooler.

Impatto della limitazione di richieste

A un certo punto la limitazione delle richieste non è più in grado di impedire al sistema di raggiungere uno stato irreversibile. La limitazione delle richieste può quindi essere utilizzata come un indice del funzionamento del sistema e per rilevare l'origine del problema. Una volta identificata la causa del collo di bottiglia dallo stato della limitazione delle richieste, analizzare altri contatori delle prestazioni per acquisire informazioni dettagliate sull'origine del problema.

Un conflitto nel database MessageBox, ad esempio, potrebbe essere dovuto a un utilizzo intensivo della CPU, che potrebbe essere causato da un paging eccessivo su disco, che a sua volta potrebbe essere dovuto a memoria insufficiente. Un conflitto nel database MessageBox potrebbe inoltre essere dovuto a un conflitto di blocco, che a sua volta potrebbe essere dovuto a unità disco sature.

Contatori delle applicazioni BizTalk

Dove iniziare?

Il monitoraggio dello stato di limitazione del recapito dei messaggi e dello stato di limitazione della pubblicazione dei messaggi per ogni istanza host è in genere un buon punto di partenza. Se il valore di questi contatori è diverso da zero, significa che nel sistema BizTalk la limitazione delle richieste è attiva e che è possibile analizzare ulteriormente la causa del collo di bottiglia. Per le descrizioni sugli altri contatori delle prestazioni, vedere Identificazione dei colli di bottiglia delle prestazioni.

Generazione di backlog

Per uno scenario di distribuzione 1 a 1, dove a un messaggio ricevuto corrisponde un messaggio elaborato e trasmesso, se la velocità in uscita non equivale alla velocità in entrata, in qualche punto del sistema si sta verificando un backlog. Se si verifica una situazione di questo tipo, è possibile monitorare la dimensione dello spooler.

Se la dimensione dello spooler cresce in modo lineare, è possibile indagare ulteriormente verificando quale coda dell'applicazione è responsabile della crescita dello spooler.

Se nessuna delle code dell'applicazione sta crescendo e la dimensione dello spooler continua a crescere, è possibile che i processi di eliminazione non siano sufficientemente veloci perché l'agent non è in esecuzione o perché si verificano conflitti di risorse di sistema nel server SQL.

Se si verifica la crescita di una delle code dell'applicazione, è importante diagnosticare la causa di tale crescita. Monitorare le risorse del sistema nel sistema che non è in grado di svuotare la coda specifica dell'applicazione (ad esempio, la coda dell'host di orchestrazione sta crescendo a causa di mancanza di CPU nel server). Verificare inoltre i valori del contatore della limitazione delle richieste per l'istanza host specifica.

Se lo stato di pubblicazione/recapito è diverso da zero, controllare il valore per confermare il motivo della limitazione delle richieste di recapito/pubblicazione (ad esempio, superamento della soglia di memoria, numero eccessivo di messaggi in elaborazione e così via).

F1 Profiler

Utilizzando i contatori delle prestazioni è possibile rilevare rapidamente la posizione del collo di bottiglia a un livello elevato. Una volta individuato il collo di bottiglia, per cercare di risolvere il problema può essere tuttavia necessario eseguire un ulteriore drill-down del codice. F1 Profiler, fornito con Visual Studio, può risultare uno strumento particolarmente utile per diagnosticare il punto in cui viene eseguita la maggior parte dei cicli nel codice.

I simboli contribuiscono a creare uno stack più significativo, soprattutto nel caso di codice gestito. F1-Profiler, ad esempio, può contribuire a individuare il numero di chiamate e la quantità di tempo che impiega una chiamata API per restituire un valore. Eseguendo un ulteriore drill-down dello stack, può essere possibile rilevare la causa sottostante dell'elevata latenza. La causa potrebbe essere una chiamata di blocco a una query su database o semplicemente una chiamata per l'attesa di un evento.

Cache L2/L3

Dal punto di vista dell'hardware, i maggiori vantaggi possono essere ottenuti utilizzando la cache della CPU onboard. Una cache CPU di maggiori dimensioni contribuisce ad aumentare la percentuale di riscontri nella cache, consentendo così al sistema di ridurre il paging dei dati in entrata nella memoria e in uscita dalla memoria sul disco.

Colli di bottiglia delle prestazioni nei sistemi a 64 bit

Le prestazioni nei sistemi a 64 bit possono risultare inferiori rispetto a quelle ottenute nei sistemi a 32 bit. Ciò può dipendere da varie cause, ma la più importante è indubbiamente la memoria.

La misurazione delle prestazioni in un sistema a 32 bit con 2GB di memoria e il confronto dei risultati con le prestazioni ottenibili in un sistema a 64 bit simile con 2GB di memoria non è un confronto reale. Il sistema a 64 bit risulterà I/O bound (percentuale ridotta di tempo di inattività del disco e lunghezza elevata della coda del disco) e CPU bound (utilizzo massimo della CPU e numero elevato di passaggi di contesto). Ciò non dipende tuttavia dal fatto che l'esecuzione dell'I/O file in un sistema a 64 bit richieda un maggiore utilizzo di risorse.

Poiché il sistema a 64 bit richiede un maggiore utilizzo di memoria (indirizzamento a 64 bit), la maggior parte dei 2GB di memoria disponibile vengono utilizzati dal sistema operativo. Quando si verifica questa situazione, la maggior parte delle altre operazioni causa il paging su disco, determinando un aumento delle dimensioni del file subsystem. In questo caso, il sistema non solo impiega cicli della CPU per eseguire il paging di dati e di codice nella memoria e dalla memoria su disco, ma subisce inoltre l'impatto dell'elevato tempo di latenza del disco. Questa condizione si manifesta sia con un maggiore conflitto di dischi che con un maggiore consumo della CPU.

Per cercare di risolvere il problema, è possibile scalare verticalmente il server aggiornando la memoria (preferibilmente a 8GB). L'aggiunta di altra memoria non contribuirà tuttavia a migliorare la velocità effettiva, a meno che l'origine del problema non dipenda dalla scarsità di CPU a causa di condizioni di memoria insufficiente.

Utilizzo di BAM per identificare colli di bottiglia e problemi di latenza elevata

In situazioni in cui è importante garantire una latenza ridotta, è possibile utilizzare BAM per misurare la quantità di tempo necessaria al sistema per completare ogni fase all'interno del sistema BizTalk. Sebbene sia possibile usare i dati dell'evento e dell'istanza del servizio rilevati per eseguire il debug dello stato dei messaggi e diagnosticare l'origine dei problemi nei messaggi di routing, È possibile usare BAM per tenere traccia di vari punti attraverso il flusso del messaggio. Creando un profilo di rilevamento BAM (mediante la definizione di un'attività con continuazioni), è possibile misurare la latenza tra differenti parti del sistema per consentire il rilevamento delle fasi che richiedono un maggiore utilizzo di risorse nel processo del flusso di lavoro.