Scenari di test per misurare l'MST del motore
In questa sezione viene descritto uno scenario di test implementato per misurare l'effetto dell'utilizzo di un sistema BizTalk a tre diversi livelli di carico:
Test di carico sostenibile. Ai fini di questi test, il carico sostenibile viene descritto nell'argomento Quali sono le prestazioni sostenibili?.
Test di carico overdrive. Il carico overdrive viene definito come carico coerente che supera MST.
Test di carico di floodgate. Il carico di floodgate è definito come carico basso con picchi intermittenti di carico che superano MST.
In questo argomento vengono descritti la configurazione hardware di test, gli scenari di test e vengono illustrati i risultati ottenuti da ogni test.
Importante
Le informazioni contenute in questa sezione rappresentano le conoscenze attuali di Microsoft sulle problematiche trattate alla data di pubblicazione. Poiché le condizioni di mercato e tecnologie sono in costante mutamento, Microsoft non garantisce l'accuratezza di tutte le informazioni presentate dopo la data di pubblicazione.
Configurazione del sistema di test
Per questo scenario di test è stato utilizzato l'hardware seguente:
Sei server BizTalk. Ognuno dotato di doppi processori a 3GHz e di 2GB di RAM. Ogni server utilizza dischi locali. Due BizTalk Server sono configurati con un'istanza dell'host ricevente, due sono configurati con un'istanza dell'host di invio e due sono configurati con un'istanza dell'host utilizzata per elaborare le orchestrazioni.
Un SQL Server per il database master MessageBox e i database non MessageBox. Dotato di otto processori a 2GHz e 4 GB di RAM. Questo server è connesso a un sottosistema veloce di dischi SAN tramite fibra ottica. La pubblicazione messaggi è disattivata.
Tre server SQL per i database Messagebox pubblicati in. Dotati di quattro processori a 2GHz e di 4GB di RAM. Ognuno di questi server è connesso a un sottosistema veloce di dischi SAN tramite fibra ottica. I file di log di dati e transazioni per il database MessageBox si trovano in numeri di unità logica (LUN) separati della rete di archiviazione (SAN).
Caricare il computer client del driver. Dotato di doppi processori a 3GHz e di 2GB di RAM. Questo server è stato utilizzato per generare il carico per il test del sistema BizTalk.
Di seguito è illustrata la topologia utilizzata per i test di carico.
Topologia utilizzata per i test di carico
Scenario di test
Lo scenario di test è molto semplice. Lo strumento di generazione del carico, LoadGen 2007, è stato installato nel server per il caricamento del driver ed è stato utilizzato per inviare copie di un file alle condivisioni monitorate dall'adapter per file. Lo strumento di generazione del carico distribuisce uniformemente le copie dell'istanza del file di input tra le condivisioni file.
Nota
Scaricare LoadGen. Per informazioni sull'uso di LoadGen con l'adapter MSMQ, vedere Uso di LoadGen 2007 con MSMQ.
L'adapter per file BizTalk è configurato per controllare le condivisioni di file e pubblicare i messaggi in MessageBox. Un'orchestrazione semplice che contiene solo una forma di ricezione e una forma di trasmissione sottoscrive il messaggio pubblicato. I messaggi che vengono ripubblicati dall'orchestrazione in MessageBox vengono prelevati da una porta di trasmissione di file e inviati a una condivisione comune, definita nella SAN. I file che arrivano nella condivisione della SAN di output vengono immediatamente eliminati per evitare l'accumulo di file in quella condivisione durante l'esecuzione di un test prolungato.
Per lo scenario sono stati definiti quattro host, uno per ogni indirizzo di ricezione, per le orchestrazioni, per la porta di trasmissione e per il rilevamento. Al fine di osservare il comportamento di backlog del motore, il rilevamento viene completamente disattivato durante l'esecuzione del test. Il rilevamento viene attivato per impostazione predefinita solo per le pipeline e per le orchestrazioni. È stato pertanto esplicitamente disattivato in Amministratore BizTalk per l'orchestrazione e per la pipeline utilizzate.
Non è stata creata nessuna istanza dell'host di rilevamento, poiché il rilevamento è stato disattivato per isolare il comportamento del MessageBox principale per questi test.
È stato utilizzato uno schema semplice e i file di istanza utilizzati per il test erano tutti di 10 KB. La pipeline XMLReceive è stata utilizzata per i documenti in ingresso e non è stato utilizzato nessun componente di mapping o componente in uscita al fine di mantenere uno scenario di test semplice e concentrare le osservazioni sul comportamento del MessageBox.
Parametri misurati nel test
In questo test sono stati misurati i parametri seguenti:
Parametri di test principali misurati
I parametri seguenti sono gli indicatori principali utilizzati durante la misurazione dell'MST:
Il backlog MessageBox come misurato dal contatore Dimensioni Spool disponibile con l'oggetto prestazioni BizTalk:MessageBox:General Counters . Il backlog MessageBox è un indicatore chiave della sostenibilità. Il backlog MessageBox non può continuare ovviamente a crescere all'infinito senza incorrere alla fine in problemi. Pertanto, per valutare la sostenibilità viene utilizzata la profondità del backlog del database MessageBox, monitorata nel corso del tempo.
La tabella MessageBox denominata spool contiene un record per ogni messaggio nel sistema (attivo o in attesa di garbage collection). Il monitoraggio del numero di righe di questa tabella e del numero di messaggi ricevuti al secondo pur aumentando il carico di sistema rappresenta un metodo semplice di misurare la velocità effettiva massima sostenibile. Questa misura viene anche definita profondità della tabella spool o profonditàdi spool.
Numero di documenti ricevuti al secondo in base al contatore Documenti ricevuti/Sec disponibili con l'oggetto prestazioni BizTalk:Messaging .
Parametri di test secondari misurati
I parametri seguenti sono gli indicatori secondari che possono essere valutati quando si misura l'MST. Questi parametri possono influire sugli indicatori primari della profondità dello spooler e sul numero di documenti ricevuti al secondo.
Tempo di inattività del disco fisico per i dati messageBox e il disco del file di transazione, misurati dal contatore %Inattiva ora disponibile con l'oggetto prestazioni LogicalDisk .
Utilizzo della CPU (%) per il server MessageBox misurato dal contatore %Processore time disponibile con l'oggetto Prestazioni processore .
I timeout di blocco al secondo nel database MessageBox misurati dal contatore Lock Timeouts/sec disponibili con l'oggetto prestazioni SQLServer:Locks .
Tempo in secondi per l'esecuzione più recente del processo dell'agente SQL che cancella le tabelle del MessageBox associate ai messaggi rimossi. Questa misura viene misurata dal contatore MsgBox Msg Cleanup(Elimina processi) disponibile con l'oggetto prestazioni BizTalk:MessageBox:General Counters .
Tempo in secondi per l'esecuzione più recente del processo dell'agente SQL che cancella le tabelle del MessageBox associate alle parti dei messaggi rimossi. Questa misura viene misurata dal contatore Pulizia parti MsgBox (Elimina processi) disponibile con l'oggetto prestazioni BizTalk:MessageBox:General Counters .
Nell'esecuzione del test per determinare la velocità effettiva massima sostenibile, il carico di input è stato aumentato finché la tabella dello spooler non ha iniziato a crescere illimitatamente.
Nota
Se non si riesce a generare un carico sufficiente da causare la crescita illimitata della tabella dello spooler, significa semplicemente che la parte più lenta del sistema è sul lato di ricezione piuttosto che sul lato di elaborazione/invio.