Ricerca della causa dei colli di bottiglia
Questo argomento descrive un processo consigliato per l'analisi dei colli di bottiglia.
Qual è la fonte del problema?
L'origine del collo di bottiglia potrebbe essere relativa all'hardware o al software. Quando le risorse sono sottouse, 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 costituisce un processo incrementale in cui la risoluzione di un collo di bottiglia può portare all'individuazione di quello successivo. Le tecniche per la loro identificazione e risoluzione sono l'obiettivo di questo argomento. È possibile che un sistema funzioni in condizioni di picco per brevi periodi di tempo. Tuttavia, in termini di velocità effettiva sostenibile, le elaborazioni possono avvenire solo alla velocità del componente con le prestazioni più lente.
Uso di un approccio iterativo per il test
I colli di bottiglia possono verificarsi agli endpoint (ingresso/uscita) del sistema o al centro (orchestrazione/database). Dopo aver isolato il collo di bottiglia, usare un approccio strutturato per identificare l'origine. Dopo aver risolto il collo di bottiglia, è importante misurare di nuovo le prestazioni per garantire che un nuovo collo di bottiglia non sia stato introdotto altrove nel sistema.
Il processo di identificazione e correzione dei colli di bottiglia deve essere eseguito in modo iterativo. Variare solo un parametro alla volta, ripetere esattamente gli stessi passaggi durante ogni esecuzione del test e quindi misurare le prestazioni per verificare l'impatto della singola modifica. Se si varia più di un parametro alla volta, l'effetto della modifica potrebbe risultare nascosto.
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 comporta un falso negativo sull'effetto del parametro 1 variabile e un falso positivo sull'effetto del parametro 2 variabile.
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/rampa in cui vengono popolate tutte le cache, le tabelle di database hanno raggiunto i conteggi previsti e la limitazione è data un tempo sufficiente per regolare la velocità effettiva dopo che vengono superate le soglie predefinite. L'applicazione di questo approccio consentirà di individuare la velocità effettiva sostenibile ottimale.
Parametri di test : Non variare i parametri di test dall'esecuzione del test all'esecuzione del test. Ad esempio, variando la complessità di una mappa e/o le dimensioni di un documento, si possono produrre risultati di velocità effettiva e di latenza differenti.
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 essere compilati nel database che influiscono sulla velocità effettiva in fase di esecuzione. Il riciclo delle istanze del servizio consente di rilasciare risorse memorizzate nella cache, ad esempio memoria, connessioni alle banche dati e thread. Nell'ambiente di test è possibile creare ed eseguire la stored procedure di bts_CleanupMsgbox come descritto in How to Manually Purge Data from the MessageBox Database in a Test Environment (https://go.microsoft.com/fwlink/?LinkId=158064). Questo script è destinato a restituire l'ambiente di test BizTalk Server a uno stato nuovo rispetto alla finestra di messaggio tra le esecuzioni. Lo script elimina tutte le istanze in esecuzione e tutte le informazioni su tali istanze, tra cui stato, messaggi e sottoscrizioni, ma lascia tutte le sottoscrizioni di attivazione in modo da non dover rieseguare le orchestrazioni o le porte di invio. 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 del sistema. Per altre informazioni sulla pianificazione e sulla misurazione delle prestazioni massime sostenibili, vedere Pianificazione delle prestazioni sostenute (https://go.microsoft.com/fwlink/?LinkId=158065) e prestazioni sostenibili? (https://go.microsoft.com/fwlink/?LinkId=132304).
MST è il carico più alto del traffico di messaggi che un sistema può gestire in modo indefinito in un ambiente di produzione. Tutte le applicazioni BizTalk devono essere testate per prestazioni e velocità effettiva prima di passare all'ambiente di produzione. È necessario eseguire almeno un set rappresentativo di test case che rappresentano gli scenari di utilizzo più comuni. È consigliabile testare i carichi previsti e i carichi di picco in un ambiente separato che corrisponde alle caratteristiche dell'ambiente di produzione. Questo ambiente deve avere tutti i servizi standard aziendali installati ed in esecuzione, ad esempio agenti di monitoraggio e software antivirus.
È anche consigliabile testare nuove applicazioni BizTalk nello stesso hardware in produzione insieme alle altre applicazioni BizTalk in esecuzione. Queste altre applicazioni BizTalk inserisce un carico aggiuntivo nei 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à di 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 quanto tempo richiede il ripristino del sistema dai carichi di picco. Se il sistema non viene completamente ripristinato da un carico di picco prima che si verifichi il carico di picco successivo, si è verificato un problema. Il sistema sarà più avanti e più indietro e non sarà mai in grado di recuperare completamente.
Aspettative: velocità effettiva e latenza
È possibile prevedere una determinata quantità di velocità effettiva e/o latenza dal sistema distribuito. Il tentativo di ottenere velocità effettiva elevata e bassa latenza pone simultaneamente richieste opposte al sistema. È possibile prevedere una velocità effettiva ottimale con latenza ragionevole. Man mano che la velocità effettiva migliora, lo stress (ad esempio, un consumo di CPU più elevato, una contesa di I/O più su disco, pressione di memoria e maggiore contesa di blocco) 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 colli di bottiglia. Quando si verificano colli di bottiglia, le prestazioni possono degradare. Dare al sistema tempo sufficiente per svuotare può aiutare a risolvere il problema. L'individuazione della causa della compilazione del backlog e la correzione del 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 vengono elaborati grandi volumi di dati in modo batch in modo in batch in base alla notte. Potrebbe risultare utile individuare la capacità del sistema e la sua capacità di recuperare da un backlog. Queste informazioni consentono di stimare i requisiti hardware per la gestione degli scenari overdrive e la quantità di spazio di buffer da gestire in un sistema per gestire picchi imprevisti nella velocità effettiva.
I contatori delle prestazioni di monitoraggio possono aiutare a individuare potenziali colli di bottiglia che potrebbero verificarsi in fase di esecuzione. Tuttavia, quando si sospetta che il colpevole della CPU o del collo di bottiglia della memoria possa essere uno dei componenti personalizzati che compongono la soluzione, è consigliabile usare strumenti di profilatura come Visual Studio Profiler o ANTS Performance Profiler durante un test delle prestazioni per restringere e individuare con certezza la classe che genera il problema. Ovviamente, la profilatura di un'applicazione interferisce con le prestazioni. Pertanto, 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 figure raccolte durante questi test devono essere ignorate.
L'ottimizzazione del sistema per una velocità effettiva sostenibile ottimale richiede una conoscenza approfondita dell'applicazione distribuita, dei punti di forza e delle debolezze del sistema e dei modelli di utilizzo dello scenario specifico. Il solo modo per individuare i colli di bottiglia e prevedere con certezza la velocità effettiva sostenibile ottimale è attraverso test completi su una topologia che corrisponda strettamente a quella che sarà utilizzata in produzione. Quando si eseguono test di carico e stress rispetto a un determinato caso d'uso, isolando singoli artefatti (posizioni di ricezione, porte di invio, orchestrazioni) in istanze host separate e impostando i 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 distribuita. Alcuni colli di bottiglia possono essere risolti aumentando o ridimensionando l'ambiente. Il ridimensionamento è il processo di aggiornamento del computer esistente. Ad esempio, è possibile aggiornare un computer BizTalk Server da un computer a quattro processori a un computer a otto processori, oltre a sostituire le CPU esistenti e aggiungere altre RAM. In questo modo, è possibile accelerare le attività a elevato utilizzo di risorse, ad esempio l'analisi e il mapping dei documenti. Il ridimensionamento è il processo di aggiunta di server alla distribuzione. La decisione di aumentare o uscire dipende dal tipo di colli di bottiglia e dall'applicazione configurata. Un'applicazione deve essere compilata da zero per poter sfruttare il vantaggio di aumentare o uscire. Le indicazioni seguenti illustrano come modificare le topologie di distribuzione hardware in base ai colli di bottiglia rilevati.
Il ridimensionamento significa l'esecuzione di una soluzione BizTalk sull'hardware aggiornato, ad esempio l'aggiunta della MEMORIA e della CPU. È consigliabile esaminare il ridimensionamento quando 1) il ridimensionamento è troppo costoso o 2) il ridimensionamento non aiuterà a risolvere un collo di bottiglia. Ad esempio, è possibile ridurre significativamente il tempo trascorso durante la trasformazione e l'elaborazione di un messaggio di grandi dimensioni se si esegue l'attività in un computer più veloce.
Il ridimensionamento della piattaforma applicazione consiste nell'aggiungere nodi BizTalk al gruppo di BizTalk Server e usarli per eseguire una o più parti della soluzione. È consigliabile esaminare la scalabilità orizzontale quando 1) è necessario isolare l'invio, l'elaborazione, l'elaborazione, gli host di rilevamento o 2) quando le risorse di I/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 di BizTalk Server può aumentare la contesa di blocco nel database MessageBox.
Quindi, è consigliabile aumentare o aumentare il numero di istanze? Il ridimensionamento della piattaforma può ridurre la latenza di una soluzione BizTalk perché rende più veloci le singole attività,ad esempio il mapping dei messaggi. La scalabilità orizzontale può migliorare il massimo sostenibile tramitetput e la scalabilità della soluzione BizTalk perché consente di distribuire il carico di lavoro in più computer.