Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
In questo argomento viene fornita una panoramica dell'applicazione di test; una descrizione della metodologia di test usata ed elenca gli indicatori di prestazioni chiave (KPI) acquisiti durante i test di carico.
Testare l'applicazione
È stata usata un'applicazione richiesta-risposta sincrona per confrontare le prestazioni di BizTalk Server in esecuzione in Hyper-V a BizTalk Server in esecuzione su hardware fisico. Questa applicazione è stata usata per illustrare le prestazioni di una soluzione BizTalk Server ottimizzata per una bassa latenza. La messaggistica a bassa latenza è fondamentale per determinati scenari, ad esempio l'online banking in cui un client invia una richiesta e prevede un messaggio di risposta entro un intervallo molto breve ,ad esempio < 3 secondi.
La figura seguente illustra l'architettura di alto livello usata. Visual Studio Team System (VSTS) 2008 Test Load Agent ha richiamato una classe di test personalizzata, che ha usato il trasporto WCF per generare il carico su BizTalk Server. L'applicazione BizTalk Server in questo scenario è stata esposta tramite un percorso di ricezione richiesta-risposta WCF-BasicHttp. L'agente di carico di test di VSTS 2008 è stato usato come client di test grazie alla grande flessibilità offerta, inclusa la possibilità di configurare il numero di messaggi inviati in totale, il numero di thread simultanei e l'intervallo di sospensione tra le richieste inviate.
Diversi computer di Agente di Carico di Test di VSTS 2008 possono essere gestiti in parallelo per simulare modelli di carico reali. Per questi test, i computer dell'agente di carico di test VSTS 2008 sono stati guidati da un singolo computer VSTS 2008 Test Load Agent Controller che eseguiva anche BizUnit 3.0. Di conseguenza, è stato inviato un carico coerente ai computer BizTalk Server fisici e virtuali. Per altre informazioni sull'uso di VSTS 2008 Test Edition per generare carico simulato per i test, vedere https://go.microsoft.com/fwlink/?LinkID=132311.
Testare l'architettura dell'applicazione
Un WCF-BasicHttp o WCF-Custom Request-Response punto di ricezione riceve una nuova RichiestaCalcolatore da un computer dell'agente di carico di test.
Il componente disassembler XML promuove l'elemento Method all'interno del documento XML CalculatorRequest. L'agente messaggi invia il messaggio in arrivo al database MessageBox (BizTalkMsgBoxDb).
La richiesta in ingresso avvia una nuova istanza di LogicalPortsOrchestration. Questa orchestrazione usa una porta associata diretta per ricevere i messaggi CalculatorRequest con la proprietà promossa dal metodo = "LogicalPortsOrchestration".
LogicalPortsOrchestration usa un ciclo per ottenere le operazioni e, per ogni elemento, richiama il servizio Web WCF del Calculator downstream tramite una porta logica Solicit-Response. Il messaggio di richiesta per il servizio Web WCF Calculator viene creato usando un componente helper e pubblicato in MessageBox.
Il messaggio di richiesta viene consumato da una porta di trasmissione WCF-BasicHttp.
La porta di trasmissione WCF-BasicHttp richiama uno dei metodi (Add, Subtract, Multiply, Divide) esposti dal servizio Web WCF Calculator.
Il servizio Web WCF Calculator restituisce un messaggio di risposta.
Il messaggio di risposta viene pubblicato in MessageBox.
Il messaggio di risposta viene restituito al chiamante LogicalPortsOrchestration. L'orchestrazione ripete questo modello per ogni operazione all'interno del documento XML CalculatorRequest in ingresso.
LogicalPortsOrchestration pubblica il messaggio CalculatorResponse in MessageBox.
Il messaggio di risposta viene recuperato dal Request-Response WCF-BasicHttp Punto di ricezione.
Il messaggio di risposta viene restituito al computer dell'agente di test di carico.
Di seguito è illustrata una schermata dell'orchestrazione usata durante il test di carico:
Annotazioni
Ai fini dell'illustrazione, l'orchestrazione illustrata di seguito è una versione semplificata dell'orchestrazione effettivamente usata durante i test di carico. L'orchestrazione usata durante i test di carico includeva più ambiti, logica di gestione degli errori e tipi di porta aggiuntivi.
Testare l'orchestrazione dell'applicazione
Metodologia di test
I test delle prestazioni comportano molte attività, che se eseguite manualmente sono ripetitive, monotone e soggette a errori. Per migliorare l'efficienza dei test e garantire coerenza tra le esecuzioni dei test, è stata usata Visual Studio 2013 Team System (VSTS) Test Edition con BizUnit 3.0 per automatizzare le attività necessarie durante il processo di test. I computer dell'agente di carico di test VSTS 2008 sono stati utilizzati come client di test per generare il carico di messaggi nel sistema, e gli stessi tipi di messaggio sono stati impiegati in ogni esecuzione del test per migliorare la coerenza. Seguendo questo processo viene fornito un set coerente di dati per ogni esecuzione di test. Per altre informazioni su BizUnit 3.0, vedere https://go.microsoft.com/fwlink/?LinkID=85168. Per altre informazioni su Visual Studio 2013 Team System Test Edition, vedere https://go.microsoft.com/fwlink/?LinkID=141387.
I passaggi seguenti sono stati automatizzati:
Arrestare gli host BizTalk.
Pulire le directory di test.
Riavviare IIS.
Pulire il database Messagebox di BizTalk Server.
Riavviare SQL Server.
Cancellare i registri eventi.
Creare una cartella dei risultati del test per ogni esecuzione per archiviare le metriche delle prestazioni e i file di log associati.
Avvia gli host BizTalk.
Caricare contatori di Performance Monitor.
Scaldare l'ambiente BizTalk con un carico ridotto.
Inviare tramite un rappresentante.
Scrivere i log delle prestazioni in una cartella dei risultati.
Raccogliere i log dell'applicazione e scrivere in un file .csv nella cartella dei risultati.
Eseguire lo strumento Performance Analysis of Logs (PAL), lo strumento Relog e lo strumento Log Parser sui log delle prestazioni raccolti per produrre statistiche, grafici e report. Per altre informazioni su PAL, Relog e Log Parser, vedere Appendice D: Strumenti per la misurazione delle prestazioni.
Annotazioni
Il tracciamento è stato disabilitato e il processo di SQL Server Agent di BizTalk Server è stato disattivato durante il test.
Per garantire che i risultati di questo lab siano stati in grado di fornire un confronto delle prestazioni di BizTalk Server in un ambiente fisico e Hyper-V, le metriche delle prestazioni e i log sono stati raccolti in una posizione centralizzata per ogni esecuzione di test.
Il client di test è stato usato per creare una directory dei risultati univoca per ogni esecuzione di test. Questa directory contiene tutti i log delle prestazioni, i registri eventi e i dati associati necessari per il test. Questo approccio ha fornito informazioni necessarie quando è necessaria l'analisi retrospettiva delle esecuzioni di test precedenti. Al termine di ogni test, i dati non elaborati sono stati compilati in un set di risultati coerenti e indicatori di prestazioni chiave (KPI). La raccolta di set di risultati coerenti per le macchine fisiche e virtualizzate ha fornito i punti di confronto necessari tra le diverse esecuzioni di test e diversi ambienti. I dati raccolti includono:
Ambiente– Per registrare l'ambiente in cui è stato eseguito il test, BizTalk Server su hardware fisico o BizTalk Server in Hyper-V.
Numero di esecuzione test : Per identificare in modo univoco ogni esecuzione di test
Test Case : Per registrare l'architettura della soluzione BizTalk Server usata durante i test. (Ad esempio, orchestrazione con porte logiche e orchestrazione tramite invii inline)
Dattero– Per registrare la data e l'ora di esecuzione del test
Ora di inizio : Come segnalato dal primo agente di test di carico VSTS avviato
Tempo fermato: Come segnalato dall'ultimo agente di test di carico VSTS completato
Durata del test in minuti: Per registrare la durata del test.
Messaggi inviati in totale : Per registrare il numero totale di messaggi inviati dai computer dell'agente di carico ai computer BizTalk Server durante il test.
Messaggi inviati al secondo : Per registrare i messaggi inviati al secondo dai computer dell'agente di carico ai computer BizTalk Server durante il test.
Latenza media del client: Per registrare la quantità media di tempo tra il momento in cui i client dell'agente di carico di test hanno avviato una richiesta a e ricevuto una risposta dai computer BizTalk Server durante il test di carico.
Request-Response Durata media (ms) - Come segnalato dal contatore BizTalk:Messaging Latency\Request-Response Latency (sec) del Monitor delle prestazioni per BizTalkServerIsolatedHost
Annotazioni
Dove erano in esecuzione più host BizTalk virtualizzati, è stata utilizzata la media di questi contatori calcolata dai log.
Orchestrazioni completate al secondo : Come segnalato dal contatore XLANG/s Orchestrations(BizTalkServerApplication)\Orchestrations completed/sec Performance Monitor. Questo contatore fornisce una buona misura della velocità effettiva della soluzione BizTalk Server.
% di Messaggi Elaborati < 3 secondi – per registrare il numero totale di messaggi elaborati entro 3 secondi durante il test.
Il test di carico di VSTS 2008 è stato usato per generare un carico coerente in tutti i test. Durante i test sono state modificate le impostazioni di esecuzione dei test e il modello di carico seguenti per regolare il profilo di carico di ogni test:
Impostazioni di esecuzione del test
L'impostazione di esecuzione test seguente è stata modificata a seconda del test eseguito:
Durata esecuzione: Specifica per quanto tempo viene eseguito il test.
Impostazioni esecuzione test
Impostazioni modello di test
Le impostazioni del modello di test seguenti sono state modificate a seconda del test eseguito:
Modello– Specifica la modalità di regolazione del carico utente simulato durante un test di carico. I modelli di carico sono costanti, graduali o basati sull'obiettivo. Tutti i test di carico eseguiti erano o costanti o a gradini.
Annotazioni
Tutti i test eseguiti ai fini di questa guida hanno usato un modello di carico costante o un modello di carico graduale. I modelli di carico costante e i modelli a gradini offrono le funzionalità seguenti:
-
Modello di carico costante : Il modello di carico è lo stesso per la durata del test, il numero di utenti simulati inizia a un livello predefinito e non cambia.
- Modello di caricamento a gradini: Il modello di carico aumenta durante l'esecuzione del test; il numero di utenti simulati inizia da un livello predefinito e viene incrementato di un valore predefinito a intervalli predefiniti per tutta la durata del test.
-
Modello di carico costante : Il modello di carico è lo stesso per la durata del test, il numero di utenti simulati inizia a un livello predefinito e non cambia.
Numero di utenti costanti (modello di carico costante) - Numero di utenti virtuali che generano il carico sull'indirizzo dell'endpoint specificato nel file app.config del progetto test di carico di Visual Studio. Questo valore viene specificato nelle impostazioni del modello di carico usate per il test di carico.
Conteggio utenti iniziale (modello di carico a gradini) - Numero di utenti virtuali che generano carico contro l'indirizzo endpoint specificato all'inizio di un test del modello di carico a gradini. Questo valore viene specificato nelle impostazioni del modello di carico usate per il test di carico.
Numero massimo di utenti (modello di carico passaggio) - Numero di utenti virtuali che generano carico sull'indirizzo dell'endpoint specificato alla fine di un test del modello di carico passaggio. Questo valore viene specificato nelle impostazioni del modello di carico usate per il test di carico.
Durata fase (Schema di carico di fase) - Numero di secondi in cui gli utenti virtuali generano carico sull'indirizzo endpoint specificato per una fase di test di carico.
Step User Count (Step Load Pattern) - Numero di utenti virtuali da aumentare a ogni passaggio quando si utilizza un modello di carico a passaggi.
Impostazioni schema di test
Per altre informazioni sull'uso dei test di carico in Visual Studio 2013, vedere l'argomento Uso dei test di carico nella documentazione di Visual Studio 2013 Team System all'indirizzo https://go.microsoft.com/fwlink/?LinkId=141486.
Indicatori di prestazioni chiave misurati durante i test
I contatori di Performance Monitor seguenti sono stati acquisiti come indicatori di prestazioni chiave (KPI) per tutte le esecuzioni di test:
Annotazioni
Per altre informazioni sulla valutazione delle prestazioni con i contatori di Performance Monitor, vedere Elenco di controllo: Misurazione delle prestazioni in Hyper-V.
BizTalk Server KPI
Documenti elaborati a secondo – Come misurato dal contatore BizTalk:Messaging/Documenti elaborati/sec.
Latenza– Come misurato e restituito dal controller del test di carico VSTS 2008.
SQL Server KPI
Utilizzo del processore di SQL Server : Come misurato dal contatore SQL\Processor(Total)\%Processor Time . Questo contatore misura l'utilizzo della CPU dell'elaborazione di SQL Server nel computer SQL Server.
Prestazioni di elaborazione dei comandi Transact SQL: Come misurato dal contatore \SQL Server:SQL Statistics\Batch Requests/sec . Questo contatore misura il numero di batch di comandi Transact-SQL ricevuti al secondo. Questo contatore viene usato per misurare la velocità effettiva nel computer SQL Server.
Indicatore KPI di rete
Velocità effettiva di rete di BizTalk Server: Come misurato dal contatore del monitor delle prestazioni \Network Interface(*)\Bytes Total/sec nei computer BizTalk Server.
Velocità effettiva di rete di SQL Server – Come misurato dall'interfaccia di rete SQL\Bytes totali/sec (media) restituito dal VSTS 2008 Load Test Controller.
Indicatore chiave di prestazione della memoria
Memoria disponibile: Come misurato dal contatore \Memory\Available Mbytes per i vari scenari.
Specifiche dell'infrastruttura fisica
Per ognuno dei server installati sono state modificate le impostazioni seguenti.
Per tutti i server:
Il file di paging è stato impostato su 1,5 volte la quantità di memoria fisica allocata. Il file di paging è stato impostato su una dimensione fissa assicurando che le dimensioni iniziali e i valori massimi siano identici in MB.
L'opzione "Regola per ottenere prestazioni ottimali" è stata selezionata nella schermata Proprietà di sistema avanzate.
È stato verificato che il sistema fosse stato modificato per ottenere prestazioni ottimali dei servizi in background nella sezione Opzioni prestazioni delle proprietà di sistema.
Windows Server 2008 SP2 è stato installato come sistema operativo guest in ognuna delle macchine virtuali.
Windows Update è stato eseguito correttamente in tutti i server per installare gli aggiornamenti della sicurezza più recenti.
Per SQL Server:
SQL Server è stato installato in base alla guida all'installazione disponibile in https://go.microsoft.com/fwlink/?LinkId=141021.
SQL Server usava i LUN SAN configurati in base alla tabella seguente. I file di database e di log sono stati separati tra i LUN come indicato di seguito per ridurre le possibili contese di I/O del disco:
Il volume Data_Sys è stato usato per archiviare tutti i file di database ,inclusi i database di sistema e BizTalk, ad eccezione dei database MessageBox e TempDb.
Il volume Log_Sys è stato usato per archiviare tutti i file di log ,inclusi i database di sistema e BizTalk Server, ad eccezione dei database MessageBox e TempDb.
Il volume Data_TempDb è stato usato per archiviare il file di database TempDb.
Il volume Logs_TempDb è stato usato per archiviare il file di log tempdb.
Il file di database MessageBox è stato archiviato nel volume Data_BtsMsgBox e il file di log è stato archiviato nel volume Log_BtsMsgBox.
Oltre a questo, è stato fornito un LUN separato per il file di log MSDTC. Nei sistemi BizTalk con prestazioni elevate, è stato dimostrato che l'attività del file di log MSDTC causa un collo di bottiglia di I/O se viene lasciato sulla stessa unità fisica del sistema operativo.
Nome del volume file Dimensione Unità Logica GB Dimensione della partizione dell'host in GB Dimensione del cluster Data_Sys File di dati MASTER e MSDB 10 10 64 KB Registri_Sistema File di log MASTER e MSDB 10 10 64 KB Data_TempDb File di dati TempDB 50 50 64 KB Logs_TempDb File di log TempDB 50 50 64 KB Data_BtsMsgBox File di dati BizTalkMsgBoxDb 300 100 64 KB Logs_BtsMsgBox File di log BizTalkMsgBoxDb 100 100 64 KB Data_BAMPrimaryImport File di dati BAMPrimaryImport 10 10 64 KB Logs_BAMPrimaryImport File di log BAMPrimaryImport 10 10 64 KB Data_BizTalkDatabases Altri file di dati del database BizTalk 20 20 64 KB Logs_BizTalkDatabases Altri file di log del database BizTalk 20 20 64 KB Non disponibile File di log MSDTC 5 5 Non disponibile BizTalk Server è stato installato in base alle guide all'installazione disponibili in https://go.microsoft.com/fwlink/?LinkId=128383.
Lo strumento BizTalk Server Best Practices Analyzer (BPA) è stato usato per eseguire la convalida della piattaforma dopo la configurazione del sistema. BizTalk Server(https://www.microsoft.com/download/details.aspx?id=43382).
Specifiche della virtualizzazione
È stato usato un singolo disco rigido virtuale fisso da 50 GB per ospitare il sistema operativo per ogni macchina virtuale Hyper-V.
I dischi rigidi virtuali fissi sono stati usati anziché dischi rigidi virtuali di dimensioni dinamiche perché allocano immediatamente lo spazio di archiviazione massimo per il disco rigido virtuale al file nell'unità in cui è ospitato. In questo modo si riduce la frammentazione del file VHD che si verifica nell'unità fisica in cui è ospitata, migliorando le prestazioni di I/O del disco.
Per configurare le macchine virtuali, è stata eseguita un'installazione di Windows Server 2008 SP2 a 64 bit in un singolo disco rigido virtuale. Dopo aver installato tutti gli aggiornamenti appropriati, la macchina virtuale di base è stata immagineta usando l'utilità sysprep installata con Windows Server 2008 SP2, nella directory %WINDIR%\system32\sysprep.
Questo disco rigido virtuale di base è stato quindi copiato e usato come base per tutte le macchine virtuali Hyper-V distribuite nell'ambiente. Sysprep è stato eseguito nell'immagine del disco rigido virtuale di base per reimpostare gli identificatori di sicurezza del sistema prima che tutti i file binari di SQL Server o BizTalk Server siano stati distribuiti nel sistema.
Annotazioni
L'esecuzione di Sysprep dopo l'installazione e la configurazione di BizTalk Server nel server possono essere eseguite tramite l'uso di un file di risposte Sysprep e script forniti con BizTalk Server. Questi script di esempio sono progettati per l'uso con BizTalk Server installato solo in versioni a 32 bit e a 64 bit di Windows Server 2008 SP2. Per altre informazioni, vedere la documentazione online di BizTalk Server.
Il riferimento all'installazione non presidiata di Windows è disponibile all'indirizzo https://go.microsoft.com/fwlink/?LinkId=142364.
Vedere anche
Appendice C: Supporto di BizTalk Server e SQL Server Hyper-V