Colli di bottiglia a livello di BizTalk Server

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

• Ricezione

• Elaborazione

• Trasmissione

• Rilevamento

• Altro

  Per queste aree, se le risorse di sistema (CPU, memoria e disco) sembrano essere sature, aggiornare il server ridimensionando o fuori la piattaforma in base alle caratteristiche dell'applicazione. Se le risorse di sistema non sono sature, eseguire le procedure descritte in questa sezione.

Colli di bottiglia nella posizione di ricezione

Se i messaggi vengono compilati nella posizione di ricezione (ad esempio, la cartella di ricezione file aumenta di grandi dimensioni), questo indica che il sistema non è in grado di assorbire i dati abbastanza velocemente per mantenere il carico in ingresso. Questo è dovuto alla limitazione interna. Vale a dire, BizTalk Server riduce la frequenza di ricezione se i sottoscrittori non sono in grado di elaborare i dati abbastanza velocemente causando la compilazione del backlog nelle tabelle di database. Se il collo di bottiglia è causato da limitazioni hardware, provare a aumentare. Per altre informazioni sul ridimensionamento, vedere gli argomenti seguenti nella documentazione di BizTalk Server 2010:

• Ridimensionamento del livello di BizTalk Server (https://go.microsoft.com/fwlink/?LinkId=158073).

• Ridimensionamento del livello di SQL Server (https://go.microsoft.com/fwlink/?LinkId=158077).

  È anche possibile aumentare il numero di istanze dell'host aggiungendo un'istanza host (server) all'host mappato al gestore di ricezione. Per altre informazioni sulla scalabilità orizzontale, vedere gli argomenti seguenti nella documentazione di BizTalk Server 2010:

• Ridimensionamento del livello di BizTalk Server (https://go.microsoft.com/fwlink/?LinkId=158076).

• Ridimensionamento del livello di SQL Server (https://go.microsoft.com/fwlink/?LinkId=158075).

  Usare Perfmon per monitorare l'uso della risorsa nel sistema. È importante verificare che l'indirizzo di ricezione esterno non sia la causa del collo di bottiglia. Ad esempio, verificare se la condivisione file remota è saturazione a causa dell'I/O del disco elevato, il server che ospita la coda in uscita remota non è saturazione o il client usato per generare il carico HTTP non viene bloccato nei thread.

Elaborazione di colli di bottiglia

Se il contatore delle prestazioni della coda host - Lunghezza si sta scalando, indica che le orchestrazioni non vengono completate abbastanza velocemente. Per altre informazioni, vedere la tabella contatore Perfmon in questo argomento. 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, valutare la suddivisione dell'orchestrazione in più orchestrazioni più piccole

  Nota

  La divisione di un'orchestrazione in più flussi di lavoro può causare un'ulteriore latenza e aumentare la complessità. Più flussi di lavoro possono anche causare un aumento del numero di messaggi pubblicati e utilizzati da BizTalkMsgBoxDb, mettendo ulteriore pressione sul database.

• Se si usano mappe complesse, valutare se possono essere spostate nelle porte di ricezione/invio. Assicurarsi di verificare quali porte hanno una larghezza di banda aggiuntiva.

• Valutare la scalabilità dell'hardware o il ridimensionamento configurando un server di elaborazione aggiuntivo.

Trasmissione di colli di bottiglia

Se il server che ospita le schede di invio è saturazione sulle risorse ,ad esempio disco, memoria o CPU, valutare la scalabilità del server o il ridimensionamento in server host aggiuntivi. 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 nell'ambito della topologia, isolare la causa nella destinazione. Ad esempio, determinare se la posizione HTTP è configurata in modo ottimale per ricevere il carico. In caso contrario, valutare la scalabilità orizzontale. Determinare anche se la destinazione è in crescita a causa di messaggi di output eccessivi recapitati da BizTalk. In caso affermativo, potrebbe essere necessario un piano di manutenzione per archiviare ed eliminare i messaggi di destinazione. Un numero elevato di file in una cartella di destinazione può influire notevolmente sulla capacità del servizio BizTalk di eseguire il commit dei dati nell'unità disco.

Tenere traccia dei colli di bottiglia

L'istanza host di rilevamento è responsabile dello spostamento dei dati BAM (Business Activity Monitoring) e Health and Activity Tracking (HAT) dal database MessageBox (tabella TrackingData) alle tabelle del database BizTalk Tracking e/o BAM Primary Import. Se sono configurati più database MessageBox, l'istanza host di rilevamento usa quattro thread per database MessageBox.

È possibile che l'istanza host di rilevamento sia associata alla CPU. In caso affermativo, prendere in considerazione il ridimensionamento del server o la scalabilità orizzontale configurando un server aggiuntivo con rilevamento host abilitato. Le istanze host multiple eseguiranno automaticamente il bilanciamento del carico per più database MessageBox configurati. Per altre informazioni sulla scalabilità, vedere l'argomento Ridimensionamento delle soluzioni (https://go.microsoft.com/fwlink/?LinkId=158078).

Se la tabella TrackingData nel database MessageBox aumenta di grandi dimensioni, in genere i processi di manutenzione dei dati nel database Di rilevamento BizTalk e/o BAM Primary Import non vengono eseguiti come configurati, causando la crescita dei database di rilevamento BizTalk e/o BAM Primary Import. Dopo che questi database aumentano troppo grandi, può avere un impatto negativo sulla possibilità dell'host di rilevamento di inserire i dati nella tabella TrackingData. Ciò causa il backup dei dati rilevati nelle tabelle di database MessageBox. La crescita della tabella TrackingData causa l'avvio della limitazione.

È consigliabile abilitare solo il rilevamento minimo richiesto per l'applicazione, in quanto ridurrà la quantità di dati registrati e ridurre il rischio di tenere traccia dei colli di bottiglia. Per informazioni sulla disabilitazione delle impostazioni di rilevamento per singoli elementi, ad esempio orchestrazioni e porte di invio/ricezione, vedere How to Disable Tracking (https://go.microsoft.com/fwlink/?LinkId=160064).

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 un proprio set di risorse, ad esempio in un sistema a 32 bit, uno spazio di indirizzi di memoria virtuale a 2 GB, handle, thread. Se il server dispone di una cpu sufficiente e memoria per ospitare più istanze host, è possibile configurarli per l'esecuzione nello stesso computer fisico. In caso contrario, valutare la scalabilità orizzontale spostando la funzionalità in server dedicati. L'esecuzione delle stesse funzionalità su più server consente inoltre di fornire una configurazione a elevata disponibilità.

Contatori delle prestazioni del sistema BizTalk

Contesa della CPU

Se il processore è saturo, è possibile frammentare l'applicazione separando la ricezione dall'invio e dall'orchestrazione. A tale scopo, creare host separati, eseguire il mapping degli host a funzionalità specifiche (ricezione/invio/orchestrazione/rilevamento) e aggiungere server dedicati a questi host separati. La funzionalità di orchestrazione è spesso a elevato utilizzo di CPU. Se si configura il sistema in modo che le orchestrazioni vengono eseguite in un server dedicato separato, ciò può contribuire a migliorare la velocità effettiva complessiva del sistema.

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

Arrestare le istanze host inutilizzate. Le istanze host inutilizzate possono competere per le risorse cpu e memoria controllando regolarmente messageBox per l'elaborazione dei messaggi. Inoltre, arrestare le posizioni di ricezione inutilizzate, le porte di trasmissione e le orchestrazioni.

Aumento della tabella Spool

I colli di bottiglia downstream e/o la contesa delle risorse possono causare l'avvio eccessivo dello spooling e la riduzione delle prestazioni complessive. Per altre informazioni, vedere "Spool Table Growth" in How to Identify Bottlenecks in The MessageBox Database1.

Fame 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ò utilizzare, è consigliabile separare la funzionalità di ricezione/elaborazione/invio in istanze host separate in modo che ogni host riceva il proprio spazio indirizzi da 2 GB. Inoltre, se più istanze host sono in esecuzione nello stesso server fisico, è possibile eseguire l'aggiornamento alla memoria di 4/8 GB per evitare lo scambio di dati su disco dalla memoria reale. Le orchestrazioni a esecuzione prolungata possono contenere la memoria allocata più a lungo. Ciò può causare l'avvio di un bloat e la limitazione della memoria. I messaggi di grandi dimensioni possono anche causare un utilizzo elevato della memoria.

È possibile semplificare il problema relativo alla memoria che si verifica quando vengono elaborati messaggi di grandi dimensioni riducendo le dimensioni interne della coda deimessaggi e i messaggi in-process per ogni valore cpu per l'host specifico.

Contesa del disco

Se i dischi sono saturi (ad esempio, con un numero elevato di trasporti FILE/MSMQ), prendere in considerazione l'aggiornamento a più spindles e lo striping dei dischi con RAID 10. Inoltre, ogni volta che si utilizza il trasporto FILE, è importante assicurarsi che le cartelle di ricezione e invio non aumentano di oltre 50.000 file.

La cartella di ricezione può aumentare le dimensioni se BizTalk Server limita i dati in ingresso nel sistema. È importante spostare i dati dalla cartella di invio in modo che l'aumento di questa cartella non influisca sulla capacità di BizTalk Server di scrivere dati aggiuntivi. Per le code MSMQ non transazionali, è consigliabile creare in remoto le code di ricezione in modo che la contesa su disco venga ridotta nella BizTalk Server.

La configurazione remota della coda non transazionale offre anche disponibilità elevata perché il server remoto che ospita la coda può essere raggruppato.

Contesa di altre risorse di sistema

A seconda del tipo di trasporto, potrebbe essere necessario configurare risorse di sistema come IIS per HTTP , ad esempio MaxIOThreads, MaxWorkerThreads.

Con ASP.NET 2.0 e ASP.Net 4, l'impostazione <processModel autoConfig="true"> nel file machine.config configurerà automaticamente le impostazioni seguenti per ottenere prestazioni ottimali:

• Numero massimo di thread di lavoro

• Numero massimo di thread di I/O

• attributo minFreeThreads dell'elemento httpRuntime

• attributo minLocalRequestFreeThreads dell'elemento httpRuntime

• attributo maxConnection dell'elemento <connectionManagement> (Impostazioni di rete)

  Per altre informazioni sulla configurazione dei parametri che influiscono sulle prestazioni dell'adattatore, vedere ASP.NET Impostazioni di configurazione per l'elemento processModel (https://go.microsoft.com/fwlink/?LinkId=158080).

  Per altre informazioni sulle impostazioni di configurazione che possono influire sulle schede BizTalk Server, vedere Parametri di configurazione che influiscono sulle prestazioni dell'adattatore (https://go.microsoft.com/fwlink/?LinkID=154200).

  Oltre a ottimizzare le applicazioni BizTalk Server, altre applicazioni ASP.NET in esecuzione nello stesso server possono influire sulle prestazioni complessive. È importante ottimizzare tutte le applicazioni ASP.NET per ridurre la domanda sulle risorse di sistema. Per altre informazioni, vedere ASP.NET Performance (https://go.microsoft.com/fwlink/?LinkId=158081).

  Quando si configura per ottenere prestazioni ottimali, è consigliabile ottimizzare altri sistemi esterni, ad esempio motori di messaggistica (Accodamento messaggi, MQSeries), applicazioni, database, Active Directory e così via, che fanno parte della soluzione BizTalk complessiva. I colli di bottiglia delle prestazioni in uno qualsiasi di questi altri sistemi esterni possono avere un effetto negativo sulla soluzione BizTalk.

Colli di bottiglia downstream

Se il sistema downstream non è in grado di ricevere dati abbastanza velocemente da BizTalk, questi dati di output verranno sufficienti nei database BizTalk. Ciò comporta un aumento delle richieste, causa l'avvio della limitazione, la compattazione della pipe di ricezione e influisce sulla velocità effettiva complessiva del sistema BizTalk. Un'indicazione diretta di questo è la crescita della tabella Spool. Per altre informazioni sui colli di bottiglia e sulla tabella Spool, vedere How to Identify Bottlenecks in the MessageBox Database1.For more information about bottlenecks and the Spool table, see How to Identify Bottlenecks in the MessageBox Database1.

Impatto sulla limitazione

La limitazione inizierà a proteggere il sistema dal raggiungimento di uno stato irreversibile. È quindi possibile usare la limitazione per verificare se il sistema funziona normalmente e individuare l'origine del problema. Dopo aver identificato la causa del collo di bottiglia dallo stato di limitazione, analizzare gli altri contatori delle prestazioni per determinare l'origine del problema. Ad esempio, una contesa elevata nel database MessageBox potrebbe essere dovuta a un utilizzo elevato della CPU, causato da un paging eccessivo su disco causato da condizioni di memoria insufficiente. Un elevato conflitto nel database MessageBox potrebbe anche essere causato da un elevato conflitto di blocco a causa di unità disco sature. Anche se la limitazione occasionale non rappresenta una minaccia significativa per le prestazioni, la limitazione persistente può indicare un problema sottostante più significativo. Per altre informazioni sulle condizioni in cui BizTalk Server userà la limitazione delle richieste, vedere How BizTalk Server Implements Host Throttling (https://go.microsoft.com/fwlink/?LinkID=155286).

Per altre informazioni su come BizTalk Server la limitazione può aiutare a gestire l'uso delle risorse disponibili e ridurre al minimo la contesa delle risorse, vedere Ottimizzazione dell'utilizzo delle risorse tramite la limitazione dell'host (https://go.microsoft.com/fwlink/?LinkID=155770).

Contatori dell'applicazione BizTalk

Dove iniziare?

Monitorare lo stato di limitazione del recapito dei messaggi e lo stato di limitazione della pubblicazione dei messaggi per ogni istanza host è un buon punto di partenza. Se il valore di questi contatori non è zero, questo indica la limitazione nel sistema BizTalk e è possibile analizzare ulteriormente la causa del collo di bottiglia. Per le descrizioni sugli altri contatori delle prestazioni, vedere Colli di bottiglia nel livello di database.

Contatori delle prestazioni del motore di orchestrazione

È consigliabile ottimizzare le impostazioni di runtime di orchestrazione perché la disidratazione dell'orchestrazione continua e i punti di persistenza possono avere un impatto grave sulle prestazioni complessive. È necessario usare i contatori seguenti durante il test di orchestrazioni complesse che possono contenere più punti di persistenza e ambiti transazionali.

Compilazione del backlog

Per uno scenario di distribuzione 1-1 in cui 1 messaggio ricevuto genera 1 messaggio elaborato e trasmesso, se la frequenza in uscita non corrisponde alla frequenza in ingresso, nel sistema è presente un backlog. In questa situazione è possibile monitorare le dimensioni della proprietà Spool. Quando si determina la causa dei colli di bottiglia nella frequenza in uscita, eseguire uno scenario a caso d'uso singolo alla volta. Isolare orchestrazioni, posizioni di ricezione e inviare posizioni a host separati.

Aggiungere i contatori BizTalk:Message Box:Host al log Monitor prestazioni per monitorare un host. La coda host - Lunghezza: contatore tiene traccia del numero totale di messaggi in una determinata coda host. Se uno o più di questi contatori continuano a crescere nel tempo, prestare particolare attenzione agli artefatti eseguiti da tali host.

Se la Spool cresce in modo lineare, determinare quale coda di applicazioni è responsabile della crescita di Spool.

Se nessuno delle code dell'applicazione sta aumentando e il Spool continua a crescere, potrebbe significare che i processi di eliminazione non sono in grado di mantenere. Ciò si verifica se l'agente non è in esecuzione o è presente un'altra contesa della risorsa di sistema nella SQL Server.

Se una delle code di applicazioni è in crescita, diagnosticare la causa di questa crescita. Monitorare le risorse di sistema nel sistema che non è in grado di svuotare la coda di applicazioni specifica(ad esempio, l'host di orchestrazione-Q è in crescita a causa della starvazione della CPU nel server). Verificare inoltre i valori del contatore di limitazione per l'istanza host specifica.

Se i contatori delle prestazioni bizTalk:Message Agent Message Message Delivery Limitazione stato e pubblicazione messaggi non sono zero, controllare il valore per confermare il motivo della limitazione (ad esempio, soglia di memoria superata, numero di messaggi in anteprima troppo alto e così via).

Stand-Alone Profiler

È possibile usare i contatori delle prestazioni per rilevare la posizione del collo di bottiglia a un livello elevato. Tuttavia, una volta ristretto, potrebbe essere necessario esaminare il codice più strettamente per facilitare il problema. Il Stand-Alone Profiler fornito con Visual Studio 2010 può essere uno strumento molto utile per diagnosticare dove il codice sta spendendo la maggior parte dei cicli. Per ulteriori informazioni, vedere

Cache L2/L3

Dal punto di vista hardware, è possibile ottenere i maggiori vantaggi usando la cache della CPU di onboarding. 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 a 64 bit

Le prestazioni nei sistemi a 64 bit possono risultare inferiori rispetto a quelle ottenute nei sistemi a 32 bit. Questo è possibile per alcuni motivi, il più importante è essere la memoria.

Misurare le prestazioni in un sistema a 32 bit con 2 GB di memoria e confrontare i risultati con un sistema a 64 bit simile con 2 GB di memoria non confronta la stessa cosa. Il sistema a 64 bit sembra essere associato a disco-I/O (tempo di inattività disco basso & lunghezza elevata della coda disco) e associato alla CPU (max CPU e cambio di contesto elevato). Tuttavia, questo non è perché l'esecuzione di I/O file in un sistema a 64 bit è più costoso.

Il sistema a 64 bit è più intensivo di memoria (indirizzamento a 64 bit) che comporta l'utilizzo della maggior parte della memoria disponibile di 2 GB. In questo caso, la maggior parte delle altre operazioni causa il paging su disco che sottolinea il sottosistema di file. Pertanto, il sistema spende cicli CPU paging in/out di memoria sia dati che codice ed è influenzato dal costo elevato della latenza del disco. Questa condizione si manifesta sia con un maggiore conflitto di dischi che con un maggiore consumo della CPU.

Il modo per risolvere questo problema consiste nel ridimensionare il server aggiornando la memoria. La scalabilità fino a 8 GB è idea, tuttavia, l'aggiunta di più memoria non aiuterà a migliorare la velocità effettiva a meno che l'origine del problema non sia la starva della CPU a causa di condizioni di memoria ridotta.

Uso di BAM per identificare i colli di bottiglia e i problemi di latenza elevata

Quando la bassa latenza è importante, è possibile usare BAM per misurare il tempo necessario per completare ogni fase all'interno del sistema BizTalk Server. Anche se è possibile usare HAT 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 tramite il flusso di messaggi. Creando un profilo di rilevamento BAM che definisce un'attività con continuazioni, è possibile misurare la latenza tra parti diverse del sistema per tenere traccia delle fasi più costose all'interno del processo del flusso di lavoro.

È possibile usare Orchestration Debugger in HAT per eseguire query su un'istanza sospesa, riprendere l'istanza in modalità di debug e aggiungere punti di interruzione appropriati usando la visualizzazione Dettagli tecnici. In questo modo sarà possibile tenere traccia delle attività ed eseguire il debug dei messaggi in modo progressivo.

È possibile impostare punti di interruzione per rilevare i seguenti eventi:

• L'inizio e la fine di un'orchestrazione

• L'inizio e la fine di una forma

• L'invio o la ricezione di un messaggio

• Eccezioni

  In corrispondenza di ogni punto di interruzione, è possibile esaminare informazioni sulle variabili locali, sui messaggi e le relative proprietà e sui collegamenti ruolo.

Vedere anche

Individuazione ed eliminazione dei colli di bottiglia