Indagine sui colli di bottiglia

Questo argomento descrive un processo consigliato per indagare i colli di bottiglia.

Qual è la fonte del problema?

La causa del collo di bottiglia potrebbe essere legata all'hardware o al software. Quando le risorse sono sottoutilizzate, è in genere un'indicazione di un collo di bottiglia. I colli di bottiglia possono essere causati da limitazioni hardware, da configurazioni software inefficienti o da entrambi.

L'identificazione dei colli di bottiglia è un processo incrementale, in cui l'attenuazione di un collo di bottiglia può portare all'individuazione di quello successivo. La scienza dell'identificazione e dell'attenuazione di questi colli di bottiglia è l'obiettivo di questo argomento. È possibile che un sistema esegua a picchi per brevi periodi di tempo. Tuttavia, per un throughput sostenibile, un sistema può elaborare solo alla velocità del suo componente con prestazioni più lente.

Uso di un approccio iterativo per il test

I punti di congestione possono verificarsi presso le estremità (ingresso/uscita) del sistema o nel mezzo (orchestrazione/database). Dopo che il collo di bottiglia è stato isolato, si usa un approccio strutturato per identificare l'origine. Dopo che il collo di bottiglia è stato risolto, è importante misurare di nuovo le prestazioni per garantire che un nuovo collo di bottiglia non sia stato introdotto altrove nel sistema.

Il processo di individuazione e correzione dei colli di bottiglia andrebbe eseguito in modo iterativo. Variare un solo parametro alla volta, ripetere esattamente gli stessi passaggi durante ogni esecuzione di test e quindi misurare le prestazioni per verificare l'impatto della singola modifica. La variazione di più parametri alla volta potrebbe nascondere l'effetto della modifica.

Ad esempio, la modifica del parametro 1 potrebbe migliorare le prestazioni. Tuttavia, la modifica del parametro 2 in combinazione con la modifica del parametro 1 potrebbe avere un effetto dannoso e negare i vantaggi della modifica del parametro 1. Ciò porta a un effetto netto zero e restituisce un falso negativo sull'effetto del parametro 1 variabile e un falso positivo sull'effetto di variabile parametro 2.

Test della coerenza

La misurazione delle caratteristiche delle prestazioni dopo la modifica delle impostazioni deve essere eseguita per convalidare l'effetto della modifica.

• Hardware- Usare hardware coerente perché la variabile hardware può causare comportamenti incoerenti e produrre risultati fuorvianti. Ad esempio, non si userebbe un portatile per testare le prestazioni di una soluzione BizTalk.

• Durata esecuzione test - Misurare le prestazioni per un periodo minimo fisso per garantire che i risultati siano sostenibili. L'esecuzione di test per periodi più lunghi garantisce inoltre che il sistema abbia superato il periodo iniziale di riscaldamento e accelerazione, durante il quale tutte le cache vengono popolate, le tabelle del database raggiungono i conteggi previsti e la regolazione del flusso abbia tempo sufficiente per adattare la portata quando vengono raggiunte le soglie predefinite. Questo approccio consentirà di individuare una velocità effettiva sostenibile ottimale.

• Parametri di test – Non variare i parametri di test tra le varie esecuzioni del test. Ad esempio, la complessità della mappa e/o le dimensioni dei documenti possono produrre risultati di velocità effettiva e latenza diversi.

• Stato pulito - Al termine di un test, assicurarsi che lo stato dell'ambiente di test sia pulito prima di eseguire il test successivo. Ad esempio, i dati cronologici possono accumularsi nel database, influendo sulle prestazioni durante l'esecuzione. Il riciclo delle istanze del servizio consente di rilasciare risorse memorizzate nella cache, ad esempio memoria, connessioni di database e thread. Nell'ambiente di test può essere necessario creare ed eseguire la stored procedure bts_CleanupMsgbox come descritto in Come eliminare manualmente i dati dal database MessageBox in un ambiente di test (https://go.microsoft.com/fwlink/?LinkId=158064). Questo script è progettato per restituire l'ambiente di test di BizTalk Server a uno stato aggiornato per quanto riguarda la finestra di messaggio tra le esecuzioni. Lo script elimina tutte le istanze in esecuzione e tutte le informazioni su tali istanze, inclusi lo stato, i messaggi e le sottoscrizioni, ma lascia tutte le sottoscrizioni di attivazione in modo da non dover reinsezionare le orchestrazioni o le porte di trasmissione. Si noti che questo strumento non è supportato nei sistemi di produzione.

• Test e ottimizzazione delle prestazioni - L'obiettivo di questa categoria di test è ottimizzare le prestazioni e la velocità effettiva dell'applicazione e trovare la velocità effettiva massima sostenibile (MST) del sistema. Per altre informazioni sulla pianificazione e la misurazione delle prestazioni massime sostenibili, vedere Pianificazione delle prestazioni sostenute (https://go.microsoft.com/fwlink/?LinkId=158065) e Informazioni sulle prestazioni sostenibili? (https://go.microsoft.com/fwlink/?LinkId=132304).

  L'MST è il carico più elevato del traffico di messaggi che un sistema può gestire in un ambiente di produzione a tempo indeterminato. Prima di passare all'ambiente di produzione, è necessario testare tutte le applicazioni BizTalk per ottenere prestazioni e velocità effettiva. È necessario eseguire almeno un set rappresentativo di test case che rappresentano gli scenari di utilizzo più comuni. È consigliabile eseguire test su carichi previsti e carichi di picco in un ambiente separato che corrisponda alle caratteristiche dell'ambiente di produzione. Questo ambiente deve avere tutti i servizi standard aziendali installati e in esecuzione, ad esempio agenti di monitoraggio e software antivirus.

• È anche consigliabile testare le nuove applicazioni BizTalk nello stesso hardware in produzione insieme alle altre applicazioni BizTalk in esecuzione. Queste altre applicazioni BizTalk caricano un carico aggiuntivo in BizTalk Server, SQL Server, I/O di rete e I/O su disco. Inoltre, un'applicazione BizTalk potrebbe causare un'altra limitazione (quando la profondità dello spool diventa troppo grande, ad esempio). Tutte le applicazioni BizTalk devono essere sottoposte a test di prestazioni/stress prima di passare all'ambiente di produzione. Inoltre, è necessario determinare per quanto tempo il sistema deve recuperare dai carichi di picco. Se il sistema non viene completamente ripristinato da un carico di picco prima che si verifichi il carico massimo successivo, si è verificato un problema. Il sistema si porterà sempre più indietro e non sarà mai in grado di recuperare completamente.

Aspettative: velocità effettiva e latenza

È possibile prevedere una certa quantità di velocità effettiva e/o latenza dal sistema distribuito. Il tentativo di ottenere velocità effettiva elevata e bassa latenza comporta simultaneamente richieste opposte al sistema. È possibile prevedere una velocità effettiva ottimale con una latenza ragionevole. Man mano che la velocità effettiva migliora, lo stress (ad esempio, un consumo di CPU superiore, una contesa di I/O su disco superiore, una pressione di memoria e una contesa di blocco maggiore) nel sistema aumenta. Questa situazione può avere un impatto negativo sulla latenza. Per individuare una capacità ottimale di un sistema, è consigliabile identificare e ridurre al minimo eventuali colli di bottiglia.

Le istanze completate che risiedono nel database possono causare strozzature. Quando si verificano colli di bottiglia, le prestazioni possono peggiorare. Dare al sistema tempo sufficiente per svuotare può aiutare a risolvere il problema. Individuare la causa dell'accumulo del backlog e contribuire a risolvere il problema è importante.

Per individuare la causa del backlog, è possibile analizzare i dati cronologici e monitorare i contatori delle prestazioni (per individuare i modelli di utilizzo e diagnosticare l'origine del backlog). In genere, i backlog possono verificarsi quando grandi volumi di dati vengono elaborati in batch in modo notturno. Può risultare utile individuare la capacità del sistema e la sua capacità di recupero dallo smaltimento di arretrati. Queste informazioni consentono di stimare i requisiti hardware per la gestione degli scenari di overdrive e la quantità di spazio buffer da gestire all'interno di un sistema per gestire picchi imprevisti di velocità effettiva.

Il monitoraggio dei contatori delle prestazioni può aiutare a individuare potenziali colli di bottiglia che potrebbero verificarsi in fase di esecuzione. Tuttavia, quando si sospetta che il collo di bottiglia della CPU o della memoria sia uno dei componenti personalizzati che compongono la soluzione, raccomandiamo vivamente di usare strumenti di profiling come il Profiler di Visual Studio o ANTS Performance Profiler durante un test di prestazioni per localizzare con precisione e individuare con certezza la classe che genera il problema. Ovviamente, la profilatura di un'applicazione interferisce con le prestazioni. Di conseguenza, questi test devono essere incentrati sull'individuazione di tali componenti che causano l'utilizzo della memoria, l'utilizzo della CPU o la latenza e le cifre raccolte durante questi test devono essere eliminate.

L'ottimizzazione del sistema per una velocità effettiva sostenibile ottimale richiede una conoscenza approfondita dell'applicazione distribuita, dei punti di forza e dei punti deboli del sistema e dei modelli di utilizzo dello scenario specifico. L'unico modo per individuare colli di bottiglia e prevedere un throughput sostenibile ottimale con certezza consiste nell'eseguire test approfonditi su una topologia che corrisponde strettamente a ciò che verrà usato nell'ambiente di produzione. Quando si eseguono test di carico e stress su un determinato caso d'uso, l'isolamento di singoli artefatti (posizioni di ricezione, porte di trasmissione, orchestrazioni) in istanze host separate e l'impostazione dei contatori corretti all'interno dello strumento di monitoraggio delle prestazioni è fondamentale per limitare la causa di un collo di bottiglia.

Altri argomenti di questa sezione illustrano il processo di definizione di tale topologia e forniscono indicazioni su come ridurre ed evitare colli di bottiglia.

Scalabilità

I colli di bottiglia possono verificarsi in varie fasi di una topologia implementata. Alcuni colli di bottiglia possono essere risolti espandendo o ridimensionando l'ambiente. L'incremento delle prestazioni è il processo di aggiornamento del sistema esistente. Ad esempio, è possibile aggiornare un computer BizTalk Server da un computer a quattro processori a un computer a otto processori, nonché sostituire le CPU esistenti e aggiungere più RAM. In questo modo, è possibile accelerare le attività a elevato utilizzo di risorse, ad esempio l'analisi e il mapping dei documenti. La scalabilità orizzontale è il processo di aggiunta di server all'implementazione. La decisione di aumentare o ridurre le prestazioni dipende dal tipo di collo di bottiglia e dall'applicazione configurata. Un'applicazione deve essere costruita da zero per poter sfruttare la scalabilità verso l'alto o verso l'esterno. Le indicazioni seguenti illustrano come modificare le topologie di implementazione dell'hardware in base ai colli di bottiglia incontrati.

L'aumento delle prestazioni implica l'esecuzione di una soluzione BizTalk nell'hardware aggiornato( ad esempio, l'aggiunta di CPU e memoria). Dovresti considerare il potenziamento quando 1) scalare orizzontalmente è troppo costoso o 2) non aiuterà a risolvere un collo di bottiglia. Ad esempio, è possibile ridurre significativamente il tempo impiegato per trasformare ed elaborare un messaggio di grandi dimensioni se si esegue l'attività in un computer più veloce.

La scalabilità orizzontale della piattaforma dell'applicazione consiste nell'aggiungere nodi BizTalk al gruppo bizTalk Server e usarli per eseguire una o più parti della soluzione. È consigliabile esaminare l'aumento del numero di istanze quando 1) è necessario isolare l'invio, la ricezione, l'elaborazione, gli host di rilevamento o 2) quando la memoria, le risorse di I/O o di rete sono massime per un singolo server. Il carico può essere distribuito tra più server; Tuttavia, l'aggiunta di nuovi nodi al gruppo bizTalk Server può aumentare la contesa di blocco nel database MessageBox.

È quindi consigliabile scalare verticalmente o scalare orizzontalmente? La scalabilità verticale della piattaforma può ridurre la latenza di una soluzione BizTalk perché rende più veloci le singole attività, ad esempio il mapping dei messaggi. Scalare può migliorare la massima capacità sostenibile e la scalabilità della tua soluzione BizTalk perché permette di distribuire il carico di lavoro su più macchine.

Vedere anche

Ricerca ed eliminazione di colli di bottiglia